生产环境调试模块化 JavaScript 的核心是分层补全信息链：构建阶段保留安全部署的 external source map 并注入模块 ID；运行时主动标注错误上下文；浏览器启用 source map 与 log points；服务端上报带模块线索的错误日志。
生产环境调试模块化 JavaScript 代码的关键，是让源码可读、执行路径可追踪、错误上下文可还原。不能依赖开发时的热更新或完整 source map，但也不能放弃调试能力。
保留高质量 Source Map 并安全部署
构建时务必生成 full, external source map（如 Webpack 的 devtool: 'source-map' 或 Vite 的 build.sourcemap: 'true'），并确保它们随 JS 文件一同部署到 CDN 或静态资源目录。注意：
– 不要将 source map 上传到公开可爬取的根路径（如 /app.js.map），建议加前缀（/sourcemaps/app.js.map）或通过 HTTP 头 X-SourceMap 指定位置；
– 在 Nginx / CDN 配置中显式允许 .map 文件的 MIME 类型（application/json）和跨域访问（若需）；
– 禁用 source map 的 inline 方式（如 data:application/json;base64,...），它会显著增大包体积且无法被浏览器缓存。
在运行时主动补全模块上下文
压缩后的代码丢失了模块名和变量名，导致堆栈难以定位。可在构建后注入轻量级调试元信息：
– 使用插件（如 Webpack 的 webpack-bundle-analyzer 或自定义 plugin）为每个 chunk 注入 __DEBUG_MODULE_ID__ = "src/utils/request.ts" 这类注释；
– 在关键错误捕获处（如全局 window.onerror、Promise.catch）尝试从调用栈中匹配已知模块 ID，并拼接原始路径；
– 对于动态导入（import()），在 catch 中打印请求的模块路径，而非仅显示 ChunkLoadError。
启用浏览器原生调试辅助功能
现代浏览器已支持部分生产友好调试能力：
– Chrome DevTools 的 “Blackbox scripts” 功能可折叠第三方库（如 node_modules），聚焦业务模块；
– 在 Sources 面板中右键启用 “Enable JavaScript source maps”（默认开启），并确认 network 面板中 .map 文件返回 200；
– 使用 debugger; 语句仍有效——只要未被构建工具移除（检查 UglifyJS/Terser 是否配置了 drop_debugger: false）；
– 利用 Console > “Log points”（右键行号添加），替代侵入式 console.log，避免重新发布。
立即学习“Java免费学习笔记（深入）”；
服务端配合：错误日志带模块线索
前端上报的错误应包含足够模块上下文：
– 在 Sentry / 自建监控 SDK 中，主动附加当前路由、触发模块的 bundle 名、动态 import 的 chunk name；
– 若使用 ESM 动态导入，可在 import().then 中捕获后补充 error.module = 'feature/pay' 再上报；
– 对于 SSR 应用，服务端渲染时可注入 window.__CURRENT_CHUNKS__ = ['main', 'header']，供前端错误收集参考。
模块化代码的生产调试不靠还原开发体验，而靠分层补全信息链：构建阶段留痕、运行时主动标注、浏览器善用工具、服务端协同增强。做到这四点，90% 的线上逻辑问题能快速收敛到具体模块与行号。
