必须锁定sass和sass-loader的精确版本（如"sass": "1.77.6"、"sass-loader": "13.3.3"），因补丁级变更会影响css输出；同时需锁postcss、postcss-preset-env、css-minimizer-webpack-plugin等下游工具，确保全链路哈希稳定。
直接锁定 sass（Dart Sass）和 sass-loader 的精确版本，比“锁大版本”更可靠；node-sass 已废弃，继续用它等于主动埋雷。
为什么只写 ^1.2.3 或 ~1.2.3 不够用
因为 sass 编译行为在补丁级也可能变化：比如 sass@1.77.6 修复了一个嵌套中 & 解析错误，而 1.77.5 会把 .card { .header { &__title {} } } 错编为 .header__title 而非预期的 .card__title。这种变更不改 API，但产出 CSS 完全不同。
- CI 构建时依赖缓存或 registry 响应顺序，可能装到不同补丁版
-
package-lock.json若被手动删掉或npm install --no-package-lock，就彻底失控 - 团队成员本地
node_modules版本不一致，DevTools 里看到的样式和预发环境对不上
必须锁定的两个包及其验证方式
只锁 sass 不够——sass-loader 的实现层也会影响输出，比如是否启用 sourceMap、如何处理 @use 路径解析、是否透传 quietDeps 等参数。
- 在
package.json中写死版本："sass": "1.77.6"和"sass-loader": "13.3.3"（注意无^或~） - 执行
npm ls sass sass-loader，确认输出里没有extraneous或多个版本共存 - 检查构建产物中的
main.css文件哈希值是否稳定：改一行 JS 后重新 build，CSS 哈希不变才说明 Sass 层没漂移
锁定后仍出现 CSS 变化？重点查这三处
版本锁了，不代表输出稳如泰山。以下情况会让同一版 sass 编译出不同结果：
-
@use路径未标准化：写@use "../base/vars"和@use "@/styles/base/vars"（后者靠 Webpack alias）在不同构建环境下解析路径可能不同，导致变量未被正确覆盖 - 系统时区或 locale 影响
@debug或自定义函数输出（极少见，但 Dart Sass 在处理meta.inspect()时曾有 locale 相关 bug） - 构建工具配置差异：Vite 默认开启
css.devSourcemap，而生产模式关闭；若你误把devSourcemap: true提交到生产配置，会导致注释位置变化，间接影响压缩后 CSS 行序（某些老版 CSS minifier 会因此改变选择器合并逻辑）
要不要锁 postcss 和 css-minimizer-webpack-plugin
要。它们虽不参与 Sass 编译，但紧贴输出下游：一个 postcss-preset-env 升级可能把 :is() 降级成冗长选择器，css-minimizer-webpack-plugin@5.0.0 曾引入新压缩策略，让 .a{color:red}.b{color:red} 合并为 .a,.b{color:red}，而旧版保留分开——这会改变选择器权重，触发意料外的层叠冲突。
- 锁死
"postcss": "8.4.39"、"postcss-preset-env": "9.3.1"、"css-minimizer-webpack-plugin": "5.0.1" - 运行
npx postcss --version和npx css-minimizer-webpack-plugin --version验证 CLI 工具版本与依赖一致
真正稳住 CSS 输出，靠的不是单点版本锁，而是从 @use 路径、构建配置、压缩链路全链路压测 —— 尤其当团队开始用 @layer 或自定义函数时，任何一环松动都会让哈希飘走。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
