rollup 的 sourcemap 本身不能直接调试 tree shaking 裁剪错误，但能将压缩后代码精准映射回源码以定位被误删代码；需结合构建日志、treeshake 配置及副作用声明验证，并通过 devtools 断点确认是否被移除，再用 @__pure__ 注释、sideeffects 配置等手段修复。
Rollup 的 sourcemap 本身不能直接“调试 Tree Shaking 裁剪错误”，但它能帮你把压缩/裁剪后的代码精准映射回原始源码，从而定位哪些代码被意外移除了。关键在于结合 sourcemap、Rollup 构建日志、treeshake.manualPure 和 treeshake.unknownGlobalSideEffects 等配置，再辅以调试手段验证副作用声明是否合理。
启用高质量 sourcemap 并确保可追溯
在 rollup.config.js 中开启完整 sourcemap：
- 设
output.sourcemap: true（生成.map文件）或'inline'（内联 base64） - 加
output.sourcemapExcludeSources: false（默认为false，确保源码内容写入 map） - 推荐用
output.sourcemapPathTransform修正路径，尤其在 monorepo 或输出到子目录时，避免浏览器找不到源文件
识别“裁剪错误”的典型表现
不是所有运行时错误都源于 Tree Shaking，但以下情况高度可疑：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 某模块的导出函数/类在最终 bundle 中完全消失（控制台报
xxx is not a function），但源码中明确导出且被引用 - 全局变量（如
window.xxx）赋值语句被删，导致后续脚本访问失败 - 带副作用的导入（如
import 'xxx/init'）没触发任何逻辑，且该模块无export
用 sourcemap 定位被删代码的具体位置
打开浏览器 DevTools → Sources 面板 → 找到你的源码（通常在 webpack:// 或 rollup:// 下，或通过 sourceRoot 指向本地路径）：
- 在疑似出问题的源码行打断点（比如导出语句、副作用调用处）
- 刷新页面，看断点是否命中；若未命中，说明该行已被 Tree Shaking 移除
- 右键断点 → “Reveal in Explorer” 可看到对应 bundle 中哪一行被映射 —— 如果那行在 bundle 里根本不存在，就确认被删了
针对性修复：告诉 Rollup “别动这里”
Tree Shaking 基于静态分析，对副作用不明确的代码会保守删除。常见修复方式：
-
标记纯函数：在导出函数前加 JSDoc
/** @__PURE__ */，或用/*#__PURE__*/注释包裹调用，如/*#__PURE__*/foo() -
声明模块副作用：在
package.json中设"sideEffects": ["*.css", "*.scss"]，或对整个包设"sideEffects": true（慎用） -
强制保留导入：用
import 'xxx'+/*#__PURE__*/注释无效时，改用import xxx from 'xxx'; xxx;（制造引用） -
禁用局部 Tree Shaking：在
rollup.config.js中用treeshake: { moduleSideEffects: (id) => id.includes('problematic-lib') ? 'no-treeshake' : false }
不复杂但容易忽略：sourcemap 是桥梁，真正解决问题靠的是理解 Rollup 如何判定“无用代码”，并主动用注释、配置和导出约定引导它的判断。
