ESLint --fix 后 let 重复声明参数，检查 no-var 与 one-var

原文件能解析，运行 eslint --fix 后却出现 Parsing error: Identifier 'a' has already been declared。如果同时启用了 no-var 和 one-var，查看修复结果里是否把与函数参数同名的 var 合进了另一条 let。

ESLint 10.12.0 的具体输入是：

function f(a) { var b = 1; var a; }

var a 可以与参数名重合，改成同一作用域的 let a 则不合法。受影响的组合修复可能生成：

function f(a) { let b = 1, a; }

这不是参数突然重复传入，也不是需要更新 parser 才能支持的语法。自动修复已经把合法输入改成了无效声明，应先保留 diff 并还原这部分错误修改。

两个安全判断没有看到同一份结果

no-var 单独检查第一条声明时，只看到 b，认为可以换成 let。one-var 同轮把分号改成逗号，并删除第二个 var。这两组编辑范围没有冲突，可以一起落下；结果中新增的参数名 a 却没有经过 no-var 对完整声明的判断。

正式 ESLint 10.13.0 已修正这条组合路径。它让 no-var 的修复保留整条声明范围，使其他相关编辑等到下一轮，再根据变化后的声明判断能否改写。升级时确认工作区和编辑器实际解析到包含修正的 ESLint，保留插件与 Node 支持条件，不只升级扩展外壳。

暂时分开修复，不批量改参数名

短期不能更新时，可暂停这两条规则的同时自动写入，对相关 diff 人工处理。对于上面的无用重复声明，确认它没有初始化表达式、注释约定或其他需要保留的用途后，可以去掉重复的 var a，再处理 b。若业务代码有赋值，应先确认赋值对象和时机，不能把它直接改成另一个同名 let。

也可以在受控副本中分阶段运行规则：先只让 no-var 修复，再核对并处理剩余重复声明，最后运行项目完整 lint。阶段配置应保留原 parser 和语言选项；不能为了避开两规则组合而把整个 ESLint 检查关闭。

已有流水线可以先用 --fix-dry-run --format json 观察拟产生的 output，避免直接写回文件。它仍可能返回无效代码或失败状态，输出 JSON 并不代表修复安全。保存前后内容，并用项目原来的解析、类型检查与测试检查实际行为。

恢复后要分别覆盖普通的两个局部声明、参数名重复声明和有初始化的同名声明。原本不安全的转换应继续留下诊断，不能要求升级后所有 var 都自动变成 let。若错误代码已提交，回退工具版本不会自动恢复这些改动，仍需修正对应 diff。