css source maps默认不生效是因为打包工具对其控制独立于js且常默认关闭，需在各处理环节（如css-loader、postcss-loader）显式启用sourcemap选项并确保路径映射正确。
Source Maps在CSS构建中为什么默认不生效
多数打包工具（如Webpack、Vite）对CSS生成Source Maps的控制是独立于JS的，且默认常为false。这不是遗漏，而是权衡：CSS Source Maps会增大产物体积，且线上环境通常禁用，所以构建脚本里容易被忽略或显式关掉。
- Webpack中需同时设置
devtool（影响JS）和css-loader的sourceMap选项，二者缺一不可 - Vite 4.0+ 默认开启
css.sourceMap，但仅限开发环境；生产构建时build.cssMinify若启用（如esbuild），会自动丢弃Source Maps - PostCSS插件（如
postcss-preset-env）若提前处理了CSS，也得确保它接收并透传map对象，否则中间环节就断了
Webpack里让CSS Source Maps真正可用的三步配置
光写devtool: 'source-map'只能映射JS，CSS要额外“手动激活”。关键是让每个CSS处理环节都携带map，并最终输出到.css.map文件。
- 在
module.rules中为css-loader启用sourceMap: true -
style-loader不用改，但它只在开发时注入style标签，此时浏览器依赖的是内联sourceMappingURL注释，不是单独文件 - 生产环境若真需要（比如内部系统），得配
mini-css-extract-plugin的sourceMap: true，且确保devtool不为false或eval类值
module: {
rules: [{
test: /\.css$/,
use: [
'style-loader',
{ loader: 'css-loader', options: { sourceMap: true } },
{ loader: 'postcss-loader', options: { sourceMap: true } }
]
}]
}
浏览器里看到CSS Source Maps却定位不到原始文件
现象是DevTools样式面板显示“来自index.css:24”，点进去却是空白或跳转失败——这基本是路径映射错位。Source Maps里的sources字段记录的是构建时的绝对路径或相对路径，上线后服务器没提供对应源码，或路径前缀没对齐。
- Webpack中用
devtoolModuleFilenameTemplate统一控制JS/CSS源码路径格式，推荐设为'[resource-path]'避免绝对路径泄漏 - 若用Nginx部署，确保
location /src/能命中源码目录，或把.map文件和.css放同级，靠相对路径解析 - Vite用户注意：
server.host设为true时，Source Maps里的sources可能含localhost，上线后必然404；应改用resolve.alias或构建时重写
要不要在生产环境保留CSS Source Maps
能保留当然方便排查，但代价明确：每个.css多一个同名.map文件，gzip后仍增加10%~30%体积；且暴露源码结构，对部分业务属风险。
立即学习“前端免费学习笔记（深入）”；
- 内部后台、低敏感系统可开，配合Nginx
location ~ \.map$ { deny all; }限制外部访问 - 面向公众的前端项目，更稳妥的做法是：CI阶段生成Source Maps并上传至Sentry或自建Symbol Server，线上CSS保持无map
- 别信“只压缩CSS不删map”的方案——
csso、clean-css等工具默认剥离map，除非显式传sourceMap: true且接住输出流
Source Maps不是开关一按就通的魔法，它是构建链路里一段脆弱的路径映射，任何环节的路径处理、插件顺序、环境判断偏差，都会让“点一下跳到源文件”变成徒劳。最常卡住的地方，永远是sources数组里的那个字符串到底指向哪。
