Oxlint文档缺了3年，开发者被迫当"人肉爬虫"

2024年，Oxc生态月下载量突破150万次，但一个基础问题仍让开发者集体抓狂：Oxlint到底支不支持React Native？Oxfmt能不能处理带JSX的TypeScript？没人知道确切答案。

这不是技术难题，是信息考古。开发者被迫在GitHub议题、Discord闲聊、README碎片里翻找线索，平均浪费4.7小时才能确认一个工具的兼容边界。直到最近，Oxc官方文档终于上线兼容性总览页——这场"文档饥荒"才告一段落。

碎片化的代价：一个Vue开发者的典型踩坑路径

假设你在用Vue 3。Oxfmt支持TypeScript，于是你合理推断：.vue单文件组件应该没问题。你配置好CI流水线，提交代码，然后——格式化静默失败，Vue特有的语法糖被当成错误解析，生产环境构建出错。

ambiguity → 错误假设 → 工具误用 → 项目延期。

这个因果链每天都在重演。Oxc生态扩张越快，"不确定性乘数"越致命。每新增一个框架或文件类型，兼容矩阵的复杂度呈指数级增长，而文档的分散状态让开发者成了人肉拼图机。

更隐蔽的伤害是信任 erosion。当基础信息都无法快速获取时，团队会本能地退回ESLint和Prettier——哪怕Oxlint快50倍。

齿轮与齿槽：为什么中心化文档是"机械设计图"

把Oxlint和Oxfmt想象成齿轮，框架和文件类型是它们必须咬合的齿槽。没有清晰的工程图纸，齿轮硬怼不匹配的齿槽，结果就是摩擦（开发者暴躁）和磨损（时间浪费）。

新的兼容性页面就是那张精密图纸。它不止列出"支持/不支持"，更关键的是标记"未列出即未验证"——这比模糊的沉默更有价值。

举个例子：Svelte还没出现在兼容列表里。以前，开发者可能抱着"试试又不会死"的心态硬上，结果遭遇误报或语法误读。现在，缺失本身就是信号：红旗，而非邀请猜测的空白。

这个设计打断了一个危险的反馈循环：

缺乏文档 → 用户实验 → 未检测的不兼容 → 项目埋雷

中心化文档在这里充当断路器。

为什么社区Wiki和自动生成方案都输了

替代方案不是没有。社区维护的Wiki？更新节奏随缘，2023年的"实验性支持"到2024年可能早已废弃。自动生成的兼容矩阵？能告诉你"支持"，但解释不了"部分支持"和"完整支持"的区别——比如Oxlint对React的JSX转换支持到什么程度，是否需要额外配置。

手动维护的中心化文档胜在语义精度。它需要人做出判断：这个功能是"可用但有警告"，还是"生产就绪"？这种 nuanced 区分，机器生成不了。

但代价也很现实：维护负担。Oxc团队需要为每个新框架版本做人工验证，文档更新必然滞后于代码发布。这是速度与精度的永恒 trade-off。

一个未完成的拼图

兼容性页面解决了"有没有"的问题，但"有多新"仍是灰色地带。页面标注的React Native支持状态，是基于0.72还是0.73版本验证的？开发者仍需交叉核对。

更深层的问题：Oxc生态的扩张速度（oxc-parser、oxc-resolver、oxc-minifier接连发布）正在考验文档架构的弹性。今天的中心化方案，明天会不会又变成新的碎片？

「我们不想做另一个需要你自己拼凑的拼图。」Oxc维护者在GitHub讨论区写道。这句话的潜台词是：他们知道自己曾经就是拼图本身。

现在，当你打开Oxc文档的兼容页面，看到React Native那一栏的状态标记时，你会选择直接信任，还是仍去GitHub议题里翻找最新反馈？