本教程探讨Terser在`module: true`模式下，移除仅在HTML或其他外部环境中调用的JavaScript函数的常见问题。即使设置`dead_code: false`也无法阻止。文章深入分析问题根源，并提供将函数明确挂载到`window`对象的解决方案，确保关键函数在代码压缩后仍可访问。
引言：Terser与高效代码优化
Terser是一个强大的JavaScript解析器、混淆器和压缩器，广泛应用于前端项目的生产构建流程中，旨在减小JavaScript文件体积，提升加载速度。其核心功能之一是死代码消除（Dead Code Elimination, DCE），即识别并移除代码中永远不会被执行的部分，从而进一步优化代码。然而，在某些特定配置和使用场景下，Terser的这种优化行为可能会导致预期之外的结果，例如移除那些看似“未被使用”但实际上被外部环境（如HTML）调用的函数。
问题解析：模块模式下的函数移除机制
当Terser配置为module: true时，它会将输入的JavaScript代码视为ECMAScript模块。在ES模块的语境下，Terser会进行更积极的树摇（tree-shaking）优化。这意味着，任何未被export且在模块内部没有被其他代码直接引用的函数或变量，都会被视为死代码并被移除。
问题的核心在于：
- Terser的优化范围局限性： Terser在处理JavaScript文件时，无法解析HTML文件中的
- module: true的影响： 当设置为module: true时，Terser假设所有的模块依赖都通过import/export机制显式声明。如果一个函数仅在模块内部定义，但没有被export，也没有被模块内部的其他代码使用，Terser就会认为它是一个私有且未使用的函数，即使它可能被HTML或其他全局脚本调用。
- dead_code: false的局限性： 尽管将compress.dead_code设置为false可以阻止Terser移除某些在代码路径上不可达的代码，但它通常无法阻止Terser移除那些在ES模块内部看起来完全“未使用”的函数。因为对于Terser而言，这些函数并非“不可达”，而是“未被引用”，这在模块模式下是不同的优化判断逻辑。
- toplevel: true的增强优化： 如果同时设置了toplevel: true，Terser会对顶级作用域的变量和函数进行更激进的优化，这进一步增加了函数被移除的风险。
例如，以下Terser配置就可能导致上述问题：
{
compress: {
drop_console: true,
drop_debugger: false,
dead_code: false, // 尝试保留死代码，但可能无效
},
mangle: {
reserved: ["getUserStats"], // 仅保留名称不被混淆，不阻止移除
},
module: true, // 关键：视为ES模块
toplevel: true, // 顶级作用域优化
keep_fnames: false
}在这种配置下，即使一个名为myFunction的函数在HTML中通过onclick="myFunction()"调用，如果myFunction在JavaScript模块内部没有被其他JS代码引用，它仍然会被Terser移除。
解决方案：显式挂载到全局对象
要解决这个问题，核心思想是明确地告诉Terser以及运行时环境，某个函数是全局可访问的，不应被移除。最直接有效的方法是将函数显式地挂载到全局对象（在浏览器环境中通常是window对象）上。
示例代码：
假设你有一个需要在HTML中调用的函数myFunc：
// 定义你的函数
function myFunc() {
console.log("This function is called from HTML!");
// 执行其他逻辑...
}
// 关键步骤：将函数挂载到window对象
// 这样Terser就会认为myFunc是一个全局可访问的属性，从而不会将其移除。
window.myFunc = myFunc;
// 或者，如果你直接定义为匿名函数并挂载
// window.anotherGlobalFunc = function() {
// console.log("Another global function defined directly on window.");
// };通过window.myFunc = myFunc;这一行代码，myFunc函数就成为了window对象的一个属性。Terser在分析代码时，会识别出window对象是一个特殊的全局上下文，并且其属性可能在模块外部被访问。因此，它会保留myFunc函数，确保其在压缩后仍然存在并可供HTML或其他全局脚本调用。
注意事项与最佳实践
-
命名空间管理： 直接将大量函数挂载到window对象容易造成全局污染和命名冲突。建议将相关函数组织在一个自定义的全局命名空间下，以保持代码的整洁性。
// 更好的实践：使用命名空间 window.myApp = window.myApp || {}; // 确保myApp对象存在 window.myApp.myFunc = function() { console.log("My App function called."); }; window.myApp.anotherFunc = function() { console.log("Another My App function."); }; // 在HTML中调用时：onclick="myApp.myFunc()" 权衡利弊： 将函数暴露到全局作用域会阻止Terser对其进行更深层次的优化（例如，如果函数只在模块内部使用，Terser可能会将其私有化或进行更激进的重命名）。因此，仅对那些确实需要从外部（HTML、其他非模块化脚本等）调用的函数采用此方法。对于纯粹的模块内部逻辑，应继续利用ES模块的导入导出机制。
mangle.reserved的作用： mangle.reserved配置项用于告诉Terser在混淆（mangling）过程中不要改变特定名称。例如mangle.reserved: ["getUserStats"]会确保getUserStats这个函数名或变量名在压缩后保持不变。然而，它并不能阻止函数本身的移除。对于从HTML调用的函数，通常需要同时确保其不被移除（通过挂载到window）和其名称不被混淆（通过mangle.reserved，如果函数名本身在HTML中被硬编码）。
模块化思维： 尽可能遵循现代JavaScript的模块化开发原则。只有当确实需要与遗留系统、外部非模块化代码或HTML直接交互时，才考虑将函数暴露到全局。对于新的项目，应优先考虑使用事件监听、Web Components或框架提供的组件通信机制来处理UI交互。
总结
Terser在module: true模式下，对未显式导出且未在模块内部引用的函数进行死代码消除是其正常且高效的优化行为。当这些函数需要被HTML或其他外部环境调用时，Terser的这种行为就会导致问题。通过将函数明确地挂载到window对象，我们能够有效地“告知”Terser这些函数是全局可访问的，从而避免它们被误移除。理解Terser的工作原理和配置选项，并结合实际需求采取适当的策略，是确保代码在优化后仍能正常运行的关键。
