javascript作用域本身不直接参与死代码消除，真正起作用的是基于es模块静态导入导出图与作用域感知的ast分析；es模块的静态性使工具可精确构建依赖图，未导出且无副作用的变量才可能被dce。
在模块化打包工具（如 Webpack、Rollup、Vite）中，JavaScript 作用域本身不直接参与死代码消除（Dead Code Elimination, DCE），但它是静态分析变量引用关系的基础。真正起作用的是工具基于 ES 模块语法的静态导入导出图与作用域感知的 AST 分析，而非运行时的作用域链。
ES 模块的显式导出/导入定义了引用边界
ES 模块是静态的：import 和 export 必须是顶层语句，不能动态拼接。这使得打包工具可在不执行代码的前提下，精确构建模块间的依赖图和符号引用关系。
-
每个模块是一个独立的作用域单元：模块内声明的
const/let/function默认是模块级私有，除非被export显式暴露 -
只有被
export的标识符才可能被其他模块引用：未导出的变量即使被本模块使用，只要无外部引用且无副作用，就可能被 DCE -
默认导出与具名导出都可被静态识别：例如
export default function foo() {}和export const bar = 42;都会在 AST 中标记为“可导出绑定”
打包工具如何结合作用域做引用追踪
以 Rollup 为例（它对 DCE 最激进），其流程是：
- 将每个模块解析为 AST，记录所有声明（
VariableDeclaration、FunctionDeclaration等）及其作用域层级（模块作用域、函数作用域等） - 遍历
import语句，建立“导入绑定 → 导出源模块 + 导出名”的映射 - 扫描所有
Identifier节点，向上查找其声明位置：若声明在当前模块且未被export，再判断是否被本模块内其他语句“读取”或“调用”；若从未被读取（且无副作用），则标记为可移除 - 对
export的标识符，反向追踪哪些导入者实际使用了它——如果没有任何导入者访问该导出名，该导出及其对应声明也可能被剔除（Tree-shaking 的核心）
什么情况下变量不会被消除？关键看“是否可能被访问”
即使变量未被显式使用，以下情况会阻止 DCE：
-
被
export且无法证明外部未引用：例如export const CONFIG = {...}，即使当前项目没用到，打包器默认保留（除非启用sideEffects: false或明确声明） -
存在潜在副作用：调用函数、赋值给全局、
new构造、console.log等，工具会保守保留整条执行路径 -
动态访问破坏静态分析：如
import * as mod from './x'; mod[someDynamicName]();，工具无法确定具体调用了哪个导出，于是保留全部 -
非 ES 模块格式（如 CommonJS）：
require()是动态的，Webpack 需额外启发式分析，DCE 效果弱于 Rollup/Vite
开发者能做的优化实践
让打包工具更容易识别死代码：
- 优先用 ES 模块语法（
import/export），避免混用require和module.exports - 拆分细粒度的具名导出（
export function foo()），而非仅用默认导出 + 解构，便于按需引入 - 对纯数据配置或工具函数，标注
/*#__PURE__*/注释，提示工具该调用无副作用（如/*#__PURE__*/ Math.max(1, 2)） - 在
package.json中设置"sideEffects": false（或数组列出有副作用的文件），允许工具安全地摇掉未引用的模块
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
