生产环境本不该有 SCSS Source Map，这是构建工具默认安全策略：development 下启用，production 下禁用；原因在于 css-loader、mini-css-extract-plugin 等插件在 production 中主动关闭 sourceMap，且 Taro 等框架二次拦截，强行开启会增大体积、泄露路径、浏览器可能不加载。
生产环境本就不该有 SCSS Source Map —— 这不是 bug，是构建工具（如 Webpack、Vite、Taro）的默认安全策略：Source Map 默认只在 development 模式下生成并嵌入或输出，production 下被主动禁用。
为什么 build 后找不到 .map 文件或 sourceMappingURL 注释
现代构建工具对 CSS/SCSS 的 Source Map 处理高度依赖 css-loader、sass-loader 和最终的 mini-css-extract-plugin（Webpack）或 rollup-plugin-css-only（Vite）等插件组合。关键点在于：
-
css-loader的sourceMap选项必须为true，且仅当mode !== 'production'时才生效（除非显式覆盖） -
mini-css-extract-plugin默认在 production 下关闭sourceMap，即使 loader 开了也无效 - Taro/Vue CLI 等封装层还会在
vue.config.js或config/index.ts中二次拦截，例如 Taro 的h5.sourcemap配置项只控制 JS，不控制 CSS - SCSS 编译本身（
sass-loader）若未传sourceMap: true，后续环节根本收不到原始行号信息
强行在生产环境开启 CSS Source Map 的风险与代价
即使你绕过限制配出 .css.map，也会立刻触发三个现实问题：
- 打包体积明显增大：一个中型项目 CSS Source Map 往往比 CSS 本体还大 2–3 倍
- 暴露源文件路径结构：
sources字段会明文写出src/styles/vars.scss、node_modules/xxx/_mixins.scss，泄露项目组织方式 - 浏览器 DevTools 仍可能不加载：Chrome 对非同源或非
http(s)协议下的.map文件有严格校验，Nginx 若未配location ~ \.map$ { add_header Access-Control-Allow-Origin *; }，控制台会静默失败
真要调试生产 CSS，更务实的替代方案
与其硬开 Source Map，不如用这些已验证有效的现场手段：
立即学习“前端免费学习笔记（深入）”；
- 本地复现：用
npm run build -- --mode staging构建一个“类生产”环境（关闭压缩但保留sourceMap: true），把 dist 部署到内网 Nginx 查看 - 浏览器强制启用：打开 DevTools → Settings → Preferences → Sources → ✅ “Enable CSS source maps”，再刷新；注意仅对当前 tab 生效，且需 CSS 文件响应头含
SourceMap: /xxx.css.map - 反向定位：在 Elements 面板点击样式名（如
.header__title），右侧 Styles 面板顶部会显示来源文件和行号（前提是构建时开启了devtool: 'source-map'且 CSS loader 透出信息） - 临时加注释：在 SCSS 里写
// @debug: login-page-header，编译后 CSS 会保留该行（需sass-loader配sourceComments: true）
真正容易被忽略的是：CSS Source Map 的可用性，极度依赖 loader 插件链上每一步的 sourceMap 开关都为 true，且不能被上层框架（如 Taro 的 h5.webpackChain）静默覆盖。它不像 JS 那样有统一的 devtool 兜底，而是分散在至少三层配置里——这也是线上查不到映射时最常卡住的位置。
