写过 Oxc 的都以为解析失败只是 panic，今天这件事被一个命名彻底翻了

写过 Oxc 的都以为解析失败只是 panic，今天这件事被一个命名彻底翻了

Oxc v0.149.0 改了字段名：ParserReturn 的 panicked 改成了 fatal_error。听起来像修了一个小 bug，但实际上这是一个语义修正，直接影响所有用 Oxc 做 JS 代码分析的工具。

到底发生了什么

在 Oxc 里，ParserReturn 是个结构体，里面有个布尔字段记录解析器遇到了什么级别的错误。这个字段原来叫 panicked，听起来像是「Oxc 崩溃了」。但 Oxc 本身是 Rust 写的，极少真正触发 Rust panic（那种会导致整个进程 abort 的严重错误）。

实际上，这个字段记录的是：解析器遇到了无法恢复的语法错误。比如源码里有个位置文件直接截断，或者某个 token 序列完全不符合 JS 语法规范，解析器能检测到错误但没法继续生成完整的 AST。这种情况确实是一种 fatal error（致命错误），但它不是 Rust panic——它是解析器主动报告的「这份代码我读不下去了」。

把字段名从 panicked 改成 fatal_error，说的是同一件事，但意思准确多了：

// 之前
let ret = parser.parse();
if ret.panicked {
    // 听起来像是编译器自己炸了
}

// 现在
let ret = parser.parse();
if ret.fatal_error {
    // 准确：解析器遇到了无法恢复的错误
}

为什么这个区别重要

对于用 Oxc 写工具的人来说，这个区别直接影响错误处理逻辑：

panicked 的误读：如果你看到 panicked == true，直觉会认为「出 bug 了，需要修 Oxc 本身」或者「我的代码触发了 Rust 的 panic」。但大多数情况下，这只是你的输入源码有语法错误，不是 Oxc 本身的问题。

fatal_error 的正确理解：这个字段为 true，说明解析器在你的输入上达到了某种限制——文件太大、语法太复杂、或者代码本身就有严重错误。这是可以预期、可以处理的错误类型，你的工具应该优雅地降级，而不是假设 Oxc 本身坏了。

这次 v0.149.0 还同时把 MAX_LEN 减小到了 u32::MAX - 256，同样是安全加固：防止某些超大文件导致整数溢出。配合 fatal_error 字段一起看，Oxc 在逐步把「解析器边界」和「Rust 运行时错误」分开，让工具作者能更准确地判断错误来源。

怎么判断自己有没有受影响

如果你直接用了 Oxc 的 Rust API，检查一下有没有访问 ParserReturn.panicked：

// 需要迁移的代码
let ret = parser.parse();
if ret.panicked { ... }

// 改成
if ret.fatal_error { ... }

如果你用的是 oxlint 或 oxfmt 等 npm 包，这个改动是内部实现，不影响 CLI 用法。但如果你是下游 crate 维护者（比如某工具内部调用了 oxc_parser），那需要重新编译依赖并跑测试。

Oxc 的心智模型一直在进化：从一开始追求「比 Babel 快 10 倍」，到现在开始雕琢 API 语义和错误处理边界。一个字段名的修改看起来微小，但它背后是 Oxc 团队对「什么是 parser 能处理的错误」的更清晰定义——这件事对做静态分析、lint 工具、代码转换的人来说，比跑分数字更有价值。

建议所有 Oxc API 的下游用户升级到 v0.149.0，顺便把错误处理逻辑里的 panicked 全部过一遍，看看有没有被误当成 Rust panic 处理的逻辑。