這個問題聊好多年了，雙方觀點旗幟鮮明，各有各的道理，搞場辯論賽一定很精彩。最近由于 antd 的一個 bug 版本被重新談起，然而一直沒有最優(yōu)解。

假如不鎖版本，可能睡一晚產(chǎn)品發(fā)布就掛了，怪誰，自己人的開源項目還可以找找，react 的鍋總不能飛美國去 Meta 公司找 Dan 吧。假如鎖了版本，1 不能跟進(jìn)安全修復(fù)類 bug，2 時間久了升不動也不愿升，筑起技術(shù)債，給后人留屎山。

除了穩(wěn)定性，這里還有人性的問題，就是誰該對此負(fù)責(zé)。因為三方問題背個故障，誰都會覺得冤枉。相反如果有人說別鎖了，我對故障負(fù)責(zé)，那大部分人也就都不會有意見了，愛鎖不鎖。

聊這個話題，還有兩個點需要提前對齊知識儲備的。1、依賴分 node 和 browser，兩者的解法不同，后者需要考慮 tree-shaking、補丁、產(chǎn)物尺寸等 2、依賴分直接依賴和間接依賴，鎖直接依賴只能解部分問題。

問題的根源是 semver。理想的 semver 是 break.feat.bugfix，現(xiàn)實的 semver 是 break.break.break。發(fā) break 的 bugfix 版本是社區(qū)的常規(guī)操作。但是在責(zé)怪庫作者之前，有些場景要除外，比如使用了私有 API、通過 HACK 的方式關(guān)閉某些功能，依賴組件庫內(nèi)部的 DOM 結(jié)構(gòu)和 CSS 類名，更新后掛了，這就只能怪自己了。

是問題就有解，社區(qū)已有不少。臨時的比如 cnpm 提供的 bug-versions，npm 提供的 resolutions，侵入式改代碼的 patch-package 等；長期的比如 npm、yarn 和 pnpm 具備的 lock 能力，tnpm/cnpm 目前暫不支持，但可以用 yarn mode。

內(nèi)部解還有 DEVOPTS 平臺的迭代鎖，作為鎖與不鎖之間的端水大師，在整體不鎖的策略下，確保迭代內(nèi)是穩(wěn)定的。能解部分問題，但鎖支持者應(yīng)該是不會滿意的，因為跨了迭代就不穩(wěn)定了，而建迭代又是高頻操作。

那有沒有兩全的辦法？既要穩(wěn)定，又要更新，還有有人負(fù)責(zé)。有！一個思路是「中間商鎖依賴，定期更新，并對此負(fù)責(zé)」。框架是開發(fā)者的倒數(shù)第二道防線，自然而然就應(yīng)該是這個中間商。

前面說依賴分 node 和 browser。node 部分已經(jīng)這么做了，umi 鎖依賴，定期更新，出問題了 umi 負(fù)責(zé)。大家用 umi 3 或者 bigfish 3 應(yīng)該很少再有遇到因三方 node 庫比如 babel、webpack 更新導(dǎo)致的問題。比如之前的 coa 掛馬事件，就完全傷不到我們。

背后主要是 umi 層對依賴做了徹底鎖，包含間接依賴，通過預(yù)打包依賴的方式，就算再過 10 年，也不會出現(xiàn)因 node 依賴更新導(dǎo)致 umi 掛的情況。此外還有些細(xì)節(jié)，比如 babel runtime 和 polyfill 等 browser 依賴的鎖定等。

能套用到 browser 依賴嗎？有點困難。1、徹底鎖的問題，browser 要考慮尺寸，預(yù)打包會讓 tree-shaking 失效 2、回歸的成本問題，比如 antd 庫的回歸，除了人肉回歸大量項目，沒想到萬全的方法 3、不像 node 庫大部分問題在流程中就能發(fā)現(xiàn)，browser 庫直接影響線上，所以風(fēng)險更高。

問題 1 是工程問題，大概率是有解的，現(xiàn)在沒有解再過幾年來看看可能就有了，我想到的是 importmaps 鎖，借助 esmi 服務(wù)，可解尺寸問題；問題 2 需要人，群里得知 LOWCODE 平臺維護(hù)的 xxx-antd 每次迭代 N 人日保障，雖不能完全確保沒問題，但相比盲升應(yīng)該是更是靠譜的；群里還有聊到灰度的方案，解法是加延遲，讓一個群體或不重要的業(yè)務(wù)先踩坑，避免對重要業(yè)務(wù)的影響。

所以 importmaps 鎖 + 有人擔(dān)保的類 xxx-antd 中間依賴 + 灰度可能是 browser 依賴的完美解。至于 procode 為啥直接用 xxx-antd 不夠完美？因為間接依賴沒鎖。