查詢官網
字串形式loadchildren
已棄用(請參閱參考資料deprecatedloadchildren
)。loadchildrencallback
應改用函式形式()。
使用loadchildrencallback應改用函式形式()
loadchildren: () => import('./lazy-route/lazy.module').then(mod => mod.lazymodule),
加入後報錯
僅當 "--module" 標誌為 "commonjs" 或 "esnext" 時,才支援動態匯入。ts(1323)
修改 tsconfig.json
"module": "esnext"
還是報錯
npm檢視版本 6.4.1 貌似不行,需要公升級的8
公升級過程中操作不得當,完全崩潰,重灌系統, 重灌環境,修改ok
修改測試後發現main.js還是有2m左右,看官網的demo也是2m左右
通過增加編譯引數:--prod –aot
編譯後發現,竟然報了一堆錯誤。不過不要驚慌,那是優化編譯時對ts語法檢查比較嚴謹,我們**中很多地方寫的不夠嚴謹,只能硬著頭皮一行行修改了,此外別無它法。
修改npm指令碼
發現編譯指令碼 自帶--prod 增加--aot 之後,再編譯,發現還是2m左右
想到乙個方法,使用oss物件儲存
在npm指令碼後面加上 --deploy-url
直接接入oss**,
伺服器上的wwwroot只放assets資料夾和logo檔案和index.html,其它檔案放在oss上
執行起來 main.js只有400k,具體怎麼回事沒試,但是速度已經到了1s內了
本人iis11,發現 壓縮預設開啟
記一次SQL優化
問題發生在關聯主表a 4w資料量 和副表b 4w資料量 關聯欄位都是openid 當時用的是 left join 直接跑sql,卡死 伺服器也是差 優化1 改left join 為join,兩者區別就是left join查詢時已主表為依據,該是幾條就幾條 就算副表沒有關聯的資料 join如果副表沒有...
記一次kube apiserver啟動失敗排錯
master的kube apiserver啟動失敗 systemctl status kube apiserver kube apiserver.service kubernetes api server loaded loaded usr lib systemd system kube apise...
記一次oracle 優化過程
可能很多大牛都知道這個方法,但我是頭回遇到,因為專案原因,要寫很多查詢sql,對速度有要求,所以很注重sql語句的優化。像使用left join 速度會快一些等等一些算是比較常見的方法吧。近兩天做自測時發現了乙個問題,同樣一條語句,加了乙個條件竟然速度慢了那麼多,本身是乙個求彙總的sql語句,查全部...