oxlint不能直接替代eslint自动修复链路，需让oxlint负责检查、eslint或prettier负责格式与修复；关键配置包括显式指定oxc.linterpath、禁用eslint.enable、设置oxc.run为onsave，并注意.vue文件需显式include及parsesfc支持。
Oxlint 在 VSCode 里不能直接替代 ESLint 的自动修复链路，但能极快完成静态检查——关键不是“换掉 ESLint”，而是“让 Oxlint 负责检查，ESLint 或 Prettier 继续管格式和修复”。
VSCode 安装 Oxlint 插件后不报错？检查 oxlint 是否在 PATH 中
VSCode 的 Oxlint 扩展（官方名为 Oxc）本身不带二进制，只调用系统已安装的 oxlint 命令。常见现象是插件启用后无任何提示、文件打开也不标红，根本原因是 VSCode 启动时没找到 oxlint 可执行文件。
- 在终端运行
which oxlint（macOS/Linux）或where oxlint（Windows），确认路径存在 - 如果用
curl或brew install oxlint安装，可能装在/usr/local/bin或~/.cargo/bin，但 VSCode 图形界面启动时往往不加载 shell 的$PATH - 解决办法：在 VSCode 的
settings.json中显式指定路径："oxc.linterPath": "/usr/local/bin/oxlint" - Mac 用户若用 Homebrew 安装，注意 M1/M2 芯片下路径可能是
/opt/homebrew/bin/oxlint
oxlint 和 eslint 规则共存时，怎么避免重复报错？
Oxlint 默认开启 480+ 条规则，其中大量与 ESLint 重叠（如 no-unused-vars、no-undef），但诊断位置、错误码、修复建议不一致。VSCode 同时启用两者会导致同一行弹两个提示，且 eslint.autoFixOnSave 和 oxc.autoFixOnSave 互不兼容。
- 推荐策略：关掉 ESLint 的检查（保留其自动修复），只用 Oxlint 检查 —— 在
settings.json中设："eslint.enable": false，同时确保"oxc.enable": true - 若需保留 ESLint 的某些自定义规则（比如团队私有插件），可用 Oxlint 的
overrides配置禁用对应规则，例如："rules": { "no-unused-vars": "off" }写入.oxlintrc.json - 不要开启
oxc.autoFixOnSave：Oxlint 当前（v1.0）仅支持部分规则的自动修复（如引号、分号），且不保证与 Prettier 兼容；修复任务仍应交给prettier+eslint --fix
Vue / TypeScript 文件被跳过？确认 oxlint 支持的语言和解析器
Oxlint 原生支持 JavaScript、TypeScript、JSX、TSX，但对 Vue 单文件（.vue）默认不处理 —— 它不会解析 <template></template> 或 <script setup></script> 块，只检查提取出的 script 内容。如果你在 .vue 文件里没看到 Oxlint 提示，大概率是它根本没读这个文件。
- 检查当前工作区根目录是否有
.oxlintrc.json，并确认"include"字段包含"**/*.vue"（Oxlint v1.0 已支持，但需显式声明） - Vue 项目建议额外加
"parserOptions": { "parseSFC": true }，否则<script setup></script>中的响应式语法（如defineProps）可能误报no-undef - TypeScript 用户注意：Oxlint 不做类型检查，所以
any类型、泛型约束错误等不会报；它只做语法层和逻辑层分析，类型相关问题仍需tsc --noEmit或typescript-eslint - 如果用 Volar，可配合
volar.server.runtime设为"bundled"，避免语言服务器冲突
为什么保存后没触发检查？看 VSCode 的 oxc.run 配置项
Oxlint 插件默认只在“打开文件”和“手动触发”（Cmd/Ctrl+Shift+P → “Oxc: Run Lint”）时检查，不像 ESLint 那样默认监听保存事件。这是设计选择，不是 bug。
- 启用保存时检查：在
settings.json加入"oxc.run": "onSave" - 想兼顾性能和响应速度，可设为
"onType"，但注意这会高频调用oxlint，对超大文件（>500 行）可能造成轻微卡顿 - 若项目含大量
node_modules或构建产物，务必配"exclude": ["**/node_modules/**", "**/dist/**"]，否则onType下编辑器会明显变慢 - 增量检查（
--watch）目前仅命令行支持，VSCode 插件尚未集成该模式
真正容易被忽略的是：Oxlint 的规则分类（correctness / suspicious / pedantic）直接影响 VSCode 的诊断级别（Error / Warning / Info）。比如 pedantic 类规则默认是 info，不会在 Problems 面板高亮显示，必须手动改配置才能让它变成红色 Error。这点和 ESLint 的 error/warn 语义不完全对等，得一个个核对。
