typeof x === "undefined" 可被压缩工具重写为 typeof x > "u"，虽语义等价但性能更差、调试失真；ie8模式下terser会加防护性重写，ts类型守卫中的typeof可能被误压，需协同配置避免风险。
typeof 在代码压缩工具中不只是“原样保留”的安全操作，它可能被深度转换、重写，甚至引入兼容性或性能隐患。关键在于：压缩器不只删空格，还会做语义等价替换——而 typeof 的常见写法，恰好是它们重点“优化”的对象。
压缩器会把 typeof x === "undefined" 改成 typeof x > "u"
esbuild 从 2022 年起将这种判断压缩为 typeof x > "u"，原理是利用字典序：只有 "undefined" > "u"，其余所有 typeof 返回值（"object"、"string" 等）都
但早期版本的 V8、JSC、SpiderMonkey 并未对此做专门优化，导致 typeof x > "u" 实际比 typeof x === "undefined" 慢——因为引擎无法跳过字符串比较，必须真实构造 "undefined" 字符串再比大小。直到 2025–2026 年，主流引擎才陆续补上优化（V8 2025 年底完成
这意味着：
- 若项目需支持较老版本浏览器（如 Chrome 110 之前、Safari 16.4 之前），该压缩可能带来可测量的性能回退；
- 某些安全敏感或高频执行路径（如渲染循环、事件处理器）应主动禁用此类压缩；
- Terser 用户可通过
compress.passes = 1或自定义compress.ecma限制激进转换。
压缩可能破坏类型检查逻辑的可读性与调试性
压缩后 typeof 判断常被内联、折叠或与其他条件合并，例如：
if (typeof x === "undefined") { ... } → 压缩为 if (void 0 === x) { ... } 或更进一步 if (!x && typeof x > "u") { ... }
这类转换虽语义等价，但会：
- 让 source map 映射失真，debugger 中断点错位；
- 掩盖原始意图，增加线上报错堆栈分析难度；
- 在使用 TypeScript + strictNullChecks 的项目中，与编译期类型流产生认知偏差。
IE8 兼容模式下，typeof 可能触发额外转译
Terser 开启 ie8: true 时，会主动规避 JScript 引擎对 typeof 的若干怪异行为，例如：
- 重写
typeof obj.method为obj && typeof obj.method，防止obj为 null/undefined 时抛异常； - 对含保留字的属性名（如
obj.default）加引号，并包裹 typeof 检查，避免 IE8 报语法错误； - 但不会处理变量名本身是保留字的情况（如
let undefined = 1），这需 Babel 配合插件。
因此，若项目仍需支持 IE8，不能仅依赖 Terser 的 ie8: true，必须确保 Babel 已正确注入 @babel/plugin-transform-reserved-words 等配套插件。
TS 编译与 JS 压缩的协同风险
TypeScript 编译阶段会移除所有类型信息，但可能留下 typeof 表达式用于运行时类型守卫（如 function isString(x: any): x is string { return typeof x === "string"; }）。此时：
- 若 Terser 将其压缩为
typeof x ，守卫函数逻辑不变，但语义模糊； - 若压缩器又进一步将整个守卫内联进调用处（如
if (isString(val))→if (typeof val ），则 TypeScript 的类型缩小（narrowing）在源码层面不可见，影响团队协作和新成员理解； - 建议对关键守卫函数添加
/*#__NOINLINE__*/注释，阻止压缩器内联。
