尾递归优化与代码压缩不冲突但常因目标不同而冲突，terser等工具默认会破坏尾递归结构；需禁用内联、表达式折叠并加noinline标记，或更务实——先人工转为while循环再压缩。
尾递归优化和代码压缩本身不冲突，但它们在实际工程中常因目标不同而“打架”——压缩工具（如 Terser）默认会破坏尾递归结构，导致本可被手动优化的递归逻辑反而更难挽救。
压缩会悄悄改掉尾递归形式
Terser 等工具在 minify 过程中可能做这些事：
- 把参数重命名（n → a、acc → b），不影响逻辑但掩盖了语义；
- 内联小函数或展开表达式，让原本位于末尾的
return fn(...)变成return x * fn(...)，直接破坏尾调用位置； - 启用
compress: { passes: 2 }多轮压缩时，更可能把尾递归“优化”成非尾形式，失去手动蹦床或循环转换的前提。
兼容的关键：控制压缩行为
想保留尾递归可被识别/转换的空间，得主动约束压缩器：
- 禁用函数内联：
compress: { inline: false }； - 关闭表达式折叠：
compress: { evaluate: false, reduce_vars: false }； - 对关键递归函数加注释标记（Terser 支持
/*@__NOINLINE__*/），阻止其被变形； - 若用 Webpack，可在
TerserPlugin配置中单独为含尾递归的模块关闭 aggressive 压缩。
更务实的做法：先转循环，再压缩
与其依赖压缩器“手下留情”，不如在压缩前就把尾递归人工转成 while 循环：
- 结构清晰、浏览器无兼容性负担；
- 压缩后变量名缩短、逻辑扁平，体积反而更小；
- 避免运行时栈溢出风险，也绕开了 TCO 未被支持的尴尬。
注意：不要指望原生 TCO 被压缩器“救回来”
ES6 规范定义的尾调用优化（TCO）在 Chrome/Firefox/Safari 中均未启用（V8 早在 2017 年就明确放弃）。Terser 不会、也不能“模拟”引擎级 TCO。它能做的只是不破坏你写的尾递归形态——前提是你没让它乱动。
