言

測試A：那啥！摳圖仔，線上樣式怎么點著點著就出問題了。

前端：啥？線上css樣式錯亂了？你是不是有緩存啊！清下緩存試試。

測試A（內(nèi)心戲：這摳圖仔一有問題就賴緩存）：清緩存后，還有啊！你看看吧！

前端：見鬼了，我本地沒復現(xiàn)啊。

問題背景

在某次迭代中，在做產(chǎn)品體驗的時候發(fā)現(xiàn)從申請記錄頁面跳轉我的訂單，在切回來，發(fā)現(xiàn)申請記錄頁樣式錯亂了。本地調(diào)試發(fā)現(xiàn)沒有該問題。

問題定位

1. 發(fā)現(xiàn)該問題測試環(huán)境會出現(xiàn)，本地環(huán)境未復現(xiàn)
2. 打開調(diào)試面板，定位到樣式出現(xiàn)問題元素。發(fā)現(xiàn)antd的樣式（.ant-card）覆蓋了項目中寫的樣式（.recordCard___yE53v）。如圖：

為什么會出現(xiàn)這種場景？為什么該問題測試環(huán)境會出現(xiàn)，本地環(huán)境未復現(xiàn)？

調(diào)試發(fā)現(xiàn) .ant-card可以從多個chunk文件引入，切換到network面板發(fā)現(xiàn)，2966....chunk.css文件是在我們跳轉到我的訂單頁面才引入的。也就是我的訂單頁面按需加載組件打包出來的樣式文件。

到這其實就定位到問題所在了，相同組件在不同頁面按需加載的時候css文件被重復打包了。

開發(fā)環(huán)境不會，是因為我們導入組件是直接導入的node_modules的es模塊的文件，如圖：

為什么會出現(xiàn)在不同頁面按需加載的時候css文件被重復打包了呢？

dynamicImport: {
loading: '@/Loading',
},

umi開啟dynamicImport時，會啟動按route分包，實現(xiàn)頁面級別的按需加載，這種分包模式明顯在處理antd的樣式模塊復用上出現(xiàn)了一些問題。

所以推薦項目開啟該模式時，antd應該使用下面的方案二進行處理antd的樣式，防止出現(xiàn)偶現(xiàn)的線上問題。

之前代碼中會出現(xiàn)很多莫名其妙的!important去提高樣式的權重，當然也有在頁面級引入antd.css的，可能也是因為遇到了antd樣式覆蓋的問題。

輸出方案

方案一：提高recordCard___yE53v的權重，不推薦。

• 優(yōu)點：
• 改動對其他業(yè)務無任何影響。
• 缺點：
• 治標不治本，其他類似場景問題需要重復處理，代碼入侵嚴重，心智成本比較高。

方案二：修改umi打包配置，對引入多次的antd組件樣式不重復打包，需要根據(jù)實際項目情況選擇。

• 缺點：
• 因為是在整個工程方面改動，影響面比較大，需要放在測試環(huán)境驗證一段時間
• 打包出來的verdors（3.8M），antdesigns（1.5M）js文件體積會比較大(實際壓縮后不會這么大)，一定程度上影響首屏加載速度。
• 優(yōu)點：
• 采用分包，優(yōu)化大文件資源，減少重復不必要代碼。

// ...
optimization: {
splitChunks: {
chunks: 'all',
minSize: 30000,
minChunks: 2,
automaticNameDelimiter: '.',
cacheGroups: {
antd: {
name: 'antdesigns',
test: /[\/]node_modules[\/](antd|antd-mobile|@ant-design)[\/]/,
priority: 20,
},
vendors: {
name: 'vendors',
test({ resource }: any) {
return /[\/]node_modules[\/]/.test(resource);
},
priority: 10,
},
},
},
},
// ...

優(yōu)化后如圖所示，申請記錄頁面跳轉到我的訂單頁面再跳回來，.ant-card并沒有多產(chǎn)生一個css文件引入。整個dist文件包體積從116.5M到108.4M，降低了8.1M。

方案三：直接引入antd的less文件，不推薦

1. 樣式文件體積過大： 直接引入antd的less文件會導致整個antd樣式庫被打包到項目中，包括未使用的樣式，從而增加了打包后的樣式文件體積，影響頁面加載性能。
2. 影響頁面渲染性能： 大量的樣式文件會增加瀏覽器解析和渲染樣式的時間，影響頁面的加載速度和性能。
3. 不利于 緩存 和更新： 直接引入antd的less文件會使樣式文件無法通過瀏覽器緩存和CDN緩存等機制進行有效管理和更新。

webpack優(yōu)化配置之splitChunks

webpack.docschina.org/plugins/spl…

默認值

• 新的 chunk 可以被共享，或者模塊來自于 node_modules 文件夾
• 新的 chunk 體積大于 20kb（在進行 min+gz 之前的體積）
• 當按需加載 chunks 時，并行請求的最大數(shù)量小于或等于 30
• 當加載初始化頁面時，并發(fā)請求的最大數(shù)量小于或等于 30

警告

選擇了默認配置為了符合 Web 性能最佳實踐，但是項目的最佳策略可能有所不同。如果要更改配置，則應評估所做更改的影響，以確保有真正的收益，所以我們做上述分包策略時，需要根據(jù)實際項目情況來處理。

// 下面這個配置對象代表 SplitChunksPlugin 的默認行為。
module.exports = {//...
optimization: {
splitChunks: {
// 有效值為 all，async 和 initial
chunks: 'async',
// 生成 chunk 的最小體積（以 bytes 為單位）。
minSize: 20000,
// 通過確保拆分后剩余的最小 chunk 體積超過限制來避免大小為零的模塊。
minRemainingSize: 0,
// 拆分前必須共享模塊的最小 chunks 數(shù)。
minChunks: 1,
// 按需加載時的最大并行請求數(shù)。
maxAsyncRequests: 30,
// 入口點的最大并行請求數(shù)。
maxInitialRequests: 30,
// 強制執(zhí)行拆分的體積閾值和其他限制（minRemainingSize，maxAsyncRequests，maxInitialRequests）將被忽略。
enforceSizeThreshold: 50000,
/**
* 緩存組可以繼承和/或覆蓋來自 splitChunks.* 的任何選項。
* 但是 test、priority 和 reuseExistingChunk 只能在緩存組級別上進行配置。
* 將它們設置為 false以禁用任何默認緩存組。
*/
cacheGroups: {
defaultVendors: {
/**
* 控制此緩存組選擇的模塊。省略它會選擇所有模塊。
* 注：使用/是因為要同時適配unix和windows系統(tǒng)
*/
test: /[\/]node_modules[\/]/,
// 優(yōu)先級，默認值0
priority: -10,
// 如果當前 chunk 包含已從主 bundle 中拆分出的模塊，則它將被重用，而不是生成新的模塊。這可能會影響 chunk 的結果文件名。
reuseExistingChunk: true,
},
default: {
minChunks: 2,
priority: -20,
reuseExistingChunk: true,
},
},
},
},
};

webpack知識延展

線上和本地運行結果不一致，一直是一件讓前端開發(fā)者頭痛的問題。造成這種情況的原因之一呢？是因為場景不一樣，webpack提供了兩種模式。

1. Development 模式：
1. 在開發(fā)模式下，Webpack 會生成映射文件（source map），以便于調(diào)試代碼。
2. 生成的代碼不會被壓縮，可讀性更強，包括注釋和格式化。
3. 啟用了熱模塊替換（Hot Module Replacement），可以在不刷新頁面的情況下更新模塊。
4. 通常會有更多的詳細的錯誤日志和警告信息，方便開發(fā)者排查問題。
2. Production 模式：
1. 在生產(chǎn)模式下，Webpack 會對代碼進行壓縮和優(yōu)化，以減小文件大小和提高性能。
2. 不會生成映射文件，以減少額外的文件大小。
3. 移除了開發(fā)時的一些輔助功能，如熱模塊替換，以提高性能。
4. 通常會有更少的詳細錯誤日志和警告信息，以減少額外的開銷。

我們要杜絕發(fā)生線上和本地運行結果不一致的這種情況，需要我們深入了解項目中會用到的webpack，vite，rollup等前端工程化工具的內(nèi)部打包機制。

知識補充

• class="name1 name2"樣式覆蓋不是根據(jù)這里的類名先后來的 而是根據(jù)生成的樣式表中的順序。

作者：城主北寧
鏈接：https://juejin.cn/post/7346884660443988019