当使用terser压缩代码时，仅从html或外部非模块上下文调用的javascript函数可能会被意外移除，即使设置了`dead_code: false`和`module: true`。这是因为terser的死代码消除机制，尤其在模块模式下，可能无法检测到这些外部引用。解决此问题的有效方法是将相关函数显式地挂载到`window`对象上，从而使其全局可见并阻止terser将其视为可移除的死代码。
在现代前端开发中，代码压缩是优化网页性能的关键步骤之一。Terser作为一款强大的JavaScript压缩工具，能够有效减小文件体积，提升加载速度。然而，其激进的死代码消除（Dead Code Elimination）机制有时会带来意想不到的问题，特别是当JavaScript函数仅被HTML文件或非模块化脚本调用时。本文将深入探讨这一问题，并提供可靠的解决方案。
Terser的死代码消除机制与模块化影响
Terser在压缩代码时会执行“树摇”（Tree Shaking）和死代码消除，旨在移除那些在程序执行过程中永远不会被调用的代码。这一机制基于静态分析，它会遍历代码的依赖图，识别并保留“活跃”代码。
当Terser配置中设置了module: true时，它会将JavaScript文件视为ES模块。ES模块具有自己的作用域，模块内部声明的变量和函数默认仅在模块内部可见，除非通过export关键字显式导出。如果一个函数没有在模块内部被任何其他“活跃”代码引用，也没有被导出，Terser会认为它是一个死代码，即使它在模块外部（例如HTML文件中的onclick属性或另一个非模块脚本）被调用。
例如，考虑以下Terser配置：
立即学习“Java免费学习笔记（深入）”；
{
compress: {
drop_console: true,
drop_debugger: false,
dead_code: false, // 尝试保留死代码
},
mangle: {
reserved: ["getUserStats"], // 保留函数名不被混淆
},
module: true, // 视为ES模块
toplevel: true,
keep_fnames: false
}即使将dead_code设置为false，Terser仍然可能移除一个仅在HTML中调用的函数。这是因为dead_code: false主要阻止的是那些在JS内部“不可达”但可能仍有副作用的代码被移除。然而，如果一个函数在模块的内部作用域中根本没有被任何代码引用，Terser在module: true的上下文中会认为它没有内部依赖，从而将其移除。Terser并不会解析HTML文件来识别潜在的外部调用。
问题根源分析：作用域与引用检测
核心问题在于Terser的分析范围和作用域理解。当一个JavaScript文件被视为ES模块时，其内部的所有顶级声明都属于模块作用域。如果一个函数（如myFunc）在模块内部定义，但没有任何内部代码路径对其进行调用或引用，Terser会认为它是一个孤立的、无用的代码段。
// myScript.js
function myFunc() {
console.log("This function should be called from HTML.");
}
// 如果在myScript.js内部没有其他地方调用myFunc，
// 且myFunc没有被导出，Terser可能会将其移除。此时，HTML文件中的以下调用：
对Terser来说是“不可见”的。Terser不会去分析HTML文件来建立JavaScript代码的外部依赖关系。因此，它会基于JavaScript文件本身的内部引用分析来决定是否保留代码。
解决方案：显式暴露到全局作用域
解决此问题的最直接和有效的方法是显式地将需要被HTML或其他外部非模块脚本调用的函数挂载到全局window对象上。这样做可以明确告诉Terser，这个函数是一个全局可访问的属性，因此不能被移除。
// myScript.js
function myFunc() {
console.log("This function is now globally accessible.");
}
// 显式将其暴露到全局作用域
window.myFunc = myFunc;
// 或者，如果函数是匿名函数或立即执行函数表达式 (IIFE) 的一部分：
// window.getUserStats = function() {
// // ... 函数逻辑 ...
// };通过window.myFunc = myFunc;这一行代码，myFunc函数被赋值给了全局window对象的一个属性。Terser在分析时会识别到这个全局赋值操作，从而将其视为一个“活跃”的、有外部引用的代码，进而保留它。
注意事项与最佳实践
全局作用域污染： 频繁或不加限制地将函数暴露到window对象可能导致全局作用域污染，增加命名冲突的风险，并使代码难以维护。应尽量限制这种做法，仅对确实需要被外部（如HTML）直接调用的少量函数使用。
-
模块化最佳实践： 对于现代前端项目，更推荐使用模块化的方式管理代码。如果HTML需要与JavaScript交互，可以考虑使用事件监听器、Web Components或前端框架提供的组件通信机制，而不是直接在HTML中调用全局JavaScript函数。 例如，将HTML中的onclick属性替换为在JavaScript中绑定事件：
// JavaScript file function myFunc() { console.log("This function is called via event listener."); } document.addEventListener('DOMContentLoaded', () => { const myButton = document.getElementById('myButton'); if (myButton) { myButton.addEventListener('click', myFunc); } }); -
mangle.reserved与keep_fnames：
- mangle.reserved: ["functionName"] 选项可以防止特定函数名被混淆（即改变名称），但这不能阻止函数本身被移除（如果Terser认为它是死代码）。
- keep_fnames: true 选项可以保留函数原始名称，主要用于调试和堆栈跟踪，同样不阻止死代码消除。它们的作用与死代码消除是正交的。
Toplevel选项： toplevel: true 选项会将所有顶级变量和函数视为在全局作用域中声明，这在某些情况下可能有助于防止移除，但它通常与module: true结合使用时，仍然会优先考虑模块的局部作用域规则。
总结
Terser在压缩JavaScript代码时，其死代码消除机制非常强大。当函数仅被HTML或其他非模块化脚本调用，且JavaScript文件被视为ES模块时，Terser可能无法识别这些外部引用，从而移除这些函数。通过将函数显式地挂载到window对象上，可以有效地解决这一问题，确保函数在压缩后仍然可用。同时，开发者应权衡全局作用域污染的风险，并优先考虑采用现代模块化和事件驱动的交互方式，以构建更健壮、可维护的前端应用。
