言

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

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

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

前端：見鬼了，我本地沒復現啊。

問題背景

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

問題定位

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

為什么會出現這種場景？為什么該問題測試環境會出現，本地環境未復現？

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

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

開發環境不會，是因為我們導入組件是直接導入的node_modules的es模塊的文件，如圖：

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

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

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

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

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

輸出方案

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

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

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

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

// ...
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,
},
},
},
},
// ...

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

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

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

webpack優化配置之splitChunks

webpack.docschina.org/plugins/spl…

默認值

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

警告

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

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

webpack知識延展

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

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

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

知識補充

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

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

mg{border:none} 解決IE瀏覽器有邊框問題, 而W3C瀏覽器無邊框問題

選擇器的兼容性問題

1 兒子選擇器>

IE7開始兼容, IE6不兼容。

div>p{
    color:red;
}

div的兒子p。和div的后代p的截然不同。

能夠選擇：

<div>
<p>我是div的兒子</p>
</div>

不能選擇：

<div>
<ul>
<li>
<p>我是div的重孫子</p>
</li>
</ul>
</div>

2 序選擇器

IE8開始兼容；IE6、7都不兼容

選擇第1個li：

<style type="text/css">
ul li:first-child{
    color:red;
}
</style>

選擇最后一個1i：

ul li:last-child{
    color:blue;
}

由于瀏覽器的更新需要過程，所以現在如果公司還要求兼容IE6、7, 那么就要自己寫類名：

<ul>
<li class="first">項目</li>
<li>項目</li>
<li>項目</li>
<li>項目</li>
<li>項目</li>
<li>項目</li>
<li>項目</li>
<li>項目</li>
<li>項目</li>
<li class="last">項目</li>
</ul>

用類選擇器來選擇第一個或者最后一個：

ul li.first{
    color:red;
}
ul li.last{
    color:blue;
}

3 下一個兄弟選擇器

IE7開始兼容, IE6不兼容。

+表示選擇下一個兄弟

<style type="text/css">
h3+p{
color:red;
}
</style>

選擇上的是h3元素后面緊挨著的第一個兄弟。

<h3>我是一個標題</h3>
<p>我是一個段落</p>
<p>我是一個段落</p>
<p>我是一個段落</p>
<h3>我是一個標題</h3>
<p>我是一個段落</p>
<p>我是一個段落</p>
<p>我是一個段落</p>
<h3>我是一個標題</h3>
<p>我是一個段落</p>
<p>我是一個段落</p>
<p>我是一個段落</p>
<h3>我是一個標題</h3>

選擇器：

說IE6層面兼容的： 標簽選擇器、id選擇器、類選擇器、后代、交集選擇器、并集選擇器、通配符。

p
#box
.spec
div p
div.spec
div,p
*

IE7能夠兼容的：兒子選擇器、下一個兄弟選擇器

div>p
h3+p

IE8能夠兼容的：序選擇器

ul li:first-child
ul li:last-child

border-style兼容性問題

比如, border:10px ridge red; 在chrome和firefox、IE中有細微差別：

如果公司里面的設計師, 處女座的, 追求極高的頁面還原度, 那么不能使用css來制作邊框。

就要用到圖片, 就要切圖了。所以, 比較穩定的就幾個：solid、dashed、dotted, 其他的邊框樣式盡量不要用。

何神奇呢？先來簡單介紹一下背景，接下來再說一下這個現象如何神奇。

出問題的是一個即時聊天工具插件，被嵌入到客戶的第三方程序中。

工程師說，我們自己的例子程序是沒問題的，而且也不是所有的客戶端都有問題。

他還提到一點，在客戶的內網中沒有問題，但是通過VPN映射到其他局域網中就有問題。

工程師還做了一個測試，將正在運行中的插件程序地址帶參數拷貝出來，再粘貼到瀏覽器中瀏覽也沒有問題。

工程師還說，第三方程序是運行在自己的瀏覽器中的。

我心想，這么牛！自己開發的瀏覽器？

應該說，這個工程師還是比較負責的，該做的測試都做了，最終沒有辦法，才找到開發。

工程師把遠程環境弄好后，我連接上去看，又把工程師做過的驗證都復現了一遍，現象的確如他所說。

這個時候，我也感覺有點蒙圈，為什么我們Demo可以，瀏覽器也可以，就第三方程序中不行呢？

有兩個可能的原因。

要么第三方程序和我們的程序有沖突。

要么第三方開發的瀏覽器有問題。

首先排查第一個原因。

但是，我怎么調試呢？第三方瀏覽器不能按F12呀！

這個時候，工程師出馬了，說，點右鍵，然后，有個“調試”菜單。

我試了一下，還真的可以，這不就是那個熟悉的F12調試界面嗎？

還是工程師牛，現場各種操作比程序員玩的溜。

這調試界面看起來怎么這么熟悉呢？原來是chrome瀏覽器呀！

為了確認到底是什么瀏覽器，我在控制臺輸入window.navigator，回車，打印出來的的確和chrome瀏覽器一模一樣。

我就說做瀏覽器哪兒那么簡單，不就是chrome包殼嗎？

管他啥瀏覽器，解決問題才是正道。

先看看控制臺有沒有報錯，沒有，只看到第三方打的調試信息一直在跑，應該是在輪詢什么。

然后再看看我們的頁面元素還在不在，是在的。

為什么要看這個呢？

因為的確出現過第三方把我們的HTML元素直接刪了的情況。

接下來再看看頁面參數，看起來也沒有問題，在控制臺location.href連接到我們插件的地址，有問題，再復制到其他瀏覽器打開又是正常的。

整個過程并沒有出現代碼報錯，說明應該不是和第三方程序沖突造成的異常，那么剩下來就只有瀏覽器的原因了。

我看了一下調試工具的application菜單，打開本地存儲看了看，沒有什么，再看了看cookie，有一個我們的cookie。

在控制臺再次調用了一下我們的頁面，cookie好像沒有更新，感覺這個現象不對，應該要更新呀！

刪了吧！

再次在控制臺調用了一下我們的頁面。

結果居然正常了！

馬上回復工程師，說解決了！

工程師連忙問，怎么操作的，我說，進調試界面，application，cookie，然后把和我們對應的cookie刪除就可以了。

工程師回了一句，這都能想到，太神奇了，謝謝君哥。

這個問題就算解決了，我在內部管理系統的任務上將任務狀態設置成“完成”。

剛點了“完成”，建任務的同事就給我發消息問道，是什么原因。

我說，是第三方瀏覽器有問題，不更新cookie。

同事回復說，還有這種事呀，太神奇了！

我說，一切皆有可能！