source map 不是越全越好，排查和发布环境要分开选型

webpack 配 source map 时，很多人最开始只有一个判断标准：能不能在浏览器里看到原始源码。可项目一大以后，你会发现 source map 其实牵连了很多事，构建速度、调试精度、错误定位、产物暴露范围，全都和它有关。选型如果只看“调试爽不爽”，很容易在发布阶段踩坑。

开发环境更在意反馈速度

本地开发最重要的是改完代码以后能快速重建、快速定位问题。如果每次保存都为了追求最完整的映射而牺牲大量构建时间，调试体验反而会越来越差。对开发环境来说，足够定位模块和行号，通常已经比极致精确更有价值。

所以我一般会先从“这份 source map 会不会明显拖慢本地反馈”来判断，而不是默认选最完整的那一种。调试是为了加快开发，不是为了把每一次重建都变重。

生产环境更在意暴露边界和错误回溯方式

到了生产环境，问题就变了。你可能依然需要把压缩后的错误定位回源码，但又不一定希望完整 source map 跟着静态资源一起公开下载。尤其是内部系统、商业项目，源码暴露范围往往比调试便利更敏感。

这时候更重要的是想清楚：source map 给谁用，放在哪里，被谁拿得到。是只给错误监控平台用，还是允许线上浏览器直接读取；是随产物一起发布，还是单独保管。这个决策本身，比单纯背几个配置名字更关键。

排查问题时，source map 只是链路中的一环

有些团队把 source map 当成万能钥匙，觉得配好了就能解决所有定位问题。实际上如果 chunk 命名混乱、版本号没记录、构建产物和部署版本对不上，再好的映射也帮不上太多。source map 只有在构建产物可追踪、发布版本有记录的前提下，才会真正发挥价值。

所以我更愿意把它看成调试链路的一部分，而不是孤立配置项。版本标识、构建时间、错误上报、产物归档，这些都配合好了，source map 才能稳定服务排查。

把开发和发布分开看，选择反而更清楚

source map 之所以容易选乱，往往是把本地需求和线上需求混在一起想。开发要的是反馈快、定位顺；生产要的是可回溯、可控、不过度暴露。只要把这两个场景分开看，很多配置取舍就会自然很多。

webpack 本来就不是“一套配置走天下”的工具。source map 也是一样，按环境做判断，比追求一个万能答案更靠谱。