根本原因是lodash使用commonjs格式+默认导出对象，构建工具无法静态分析属性访问；应改用lodash-es并具名导入，如import { debounce } from 'lodash-es'，确保es模块语法和sideeffects声明。
引入整个 lodash 库（如 import _ from 'lodash'）会导致 Tree Shaking 失败，根本原因在于：它使用的是 CommonJS 格式 + 默认导出对象，而 Tree Shaking 依赖静态、明确的 ES 模块导入关系。
为什么全量引入会失效
CommonJS 的 module.exports = { debounce, throttle, cloneDeep } 是一个运行时才确定结构的对象，构建工具无法在不执行代码的前提下判断你实际用了哪些属性。即使你只写 _.debounce()，工具也无法确认 debounce 是不是动态拼出来的字符串（比如 _[key]()），只能保守保留整个对象——包括所有未调用的方法和内部辅助函数。
此外，官方 lodash 包的 package.json 中没有声明 "sideEffects": false，Webpack 默认认为它可能有副作用（如 polyfill、全局修改），进一步阻止摇树。
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
怎么用按需导入替代
核心是切换到 ESM 友好版本，并确保导入路径和语法都支持静态分析：
- 改用
lodash-es：它是lodash的原生 ES 模块版本，每个函数单独导出，且package.json明确标注"sideEffects": false - 使用具名导入：
import { debounce, throttle } from 'lodash-es'—— 构建工具能直接追踪到这两个标识符，其余函数不会进入依赖图 - 避免解构赋值式引用：
const { debounce } = require('lodash')虽在 Webpack 5+ 中有一定识别能力，但不保证稳定；应坚持 ESM 语法 - 对极少数必须用 CommonJS 的场景，可配合
import()动态加载，实现代码分割而非全量打包
额外优化建议
如果项目已重度依赖 lodash，又不想大规模改代码，可借助 Babel 插件自动转换：
- 配置
babel-plugin-lodash，它会把import _ from 'lodash'自动重写为import debounce from 'lodash/debounce'等具体路径 - 或使用
lodash-webpack-plugin配合自定义功能精简（如禁用惰性求值、curry 等） - 更彻底的做法是逐步替换为原生 JS 方法，例如用
Array.from(new Set(arr))替代_.uniq，零体积、零维护成本
本质上，Tree Shaking 不是你“用了什么”，而是你“怎么引”。只要导入语句能静态指向唯一函数名，摇树就能精准生效。
