不能用正则或字符串替换var，因涉及作用域、变量提升、重复声明、循环绑定等复杂语义；必须通过ast分析逐节点判断声明意图与上下文。
var 声明无法安全批量替换成 let 或 const，直接字符串替换必出错——作用域、提升、重复声明、循环绑定等问题全会暴露。必须走 AST 路径，逐节点判断声明意图和使用上下文。
为什么不能用正则或字符串 replace 替换 var
常见错误现象：var i = 0; for (var i = 0; i 中两个 <code>i 在 ES5 下共享全局作用域，但改成 let i 后，for 循环内是块级新绑定，外部 i 变成 undefined；又比如 if (cond) var x = 1; else var x = 2; 是合法的 var（变量提升后合并），但 let 会报重复声明错误。
核心问题在于：var 的函数作用域 + 变量提升 + 重复声明容忍，和 let/const 的块级作用域 + 暂时性死区 + 严格声明不可重复，语义不等价。静态分析必须还原每个 var 的实际生命周期。
- 所有
var声明需先定位其**最近的函数作用域边界**（FunctionDeclaration/FunctionExpression/ArrowFunctionExpression），不能只看所在块 - 同一作用域内多次声明同名
var，必须合并为单次let或const（若后续有赋值） - 循环中
var声明（如for (var i...)）不能无脑转let，要检查循环体是否闭包捕获该变量；若捕获，必须保留var或改用let+ IIFE 模拟（但自动化一般不处理这种）
用 jscodeshift 写安全转换脚本的关键点
推荐用 jscodeshift，它封装了 @babel/traverse 和 @babel/types，避免手写遍历器掉坑。重点不是“怎么替换”，而是“什么条件下能替换”。
实操建议：
- 只处理
VariableDeclaration.kind === 'var'，且node.declarations全部是简单初始化（Identifier+Literal/ObjectExpression等无副作用表达式），跳过含函数调用、await、new 等的init - 对每个
VariableDeclarator单独判断：若init存在且后续无重新赋值（需简单数据流分析，jscodeshift自带scope.lookup可查写操作），则倾向转const；否则转let - 跳过任何出现在
ForStatement.init、ForInStatement.left、ForOfStatement.left中的var声明——这些是语法位置，不是独立声明节点，强行改会破坏 AST 结构 - 用
j.variableDeclaration('const', decls)构造新节点，不要拼字符串；替换后调用path.replaceWith()，别直接改path.node.kind
示例片段（仅示意判断逻辑）：
export default function transformer(file, api) {
const j = api.jscodeshift;
return j(file.source)
.find(j.VariableDeclaration)
.filter(p => p.node.kind === 'var')
.filter(p => {
// 跳过 for 循环头部
if (j.ForStatement.check(p.parent.node) && p.parent.node.init === p.node) return false;
// 检查是否所有 declarations 都可安全转 const
return p.node.declarations.every(decl =>
decl.init && !j.CallExpression.check(decl.init) && !j.AwaitExpression.check(decl.init)
);
})
.replaceWith(p => {
const kind = p.node.declarations.some(decl => hasReassignment(decl.id.name, p.scope))
? 'let'
: 'const';
return j.variableDeclaration(kind, p.node.declarations);
})
.toSource();
}
容易被忽略的边界：模块顶层与循环内声明
模块顶层的 var（即不在任何函数内）转 let/const 看似安全，但要注意：var 在模块顶层会挂到 exports 或 this（非严格模式），而 let/const 不会——如果代码里有 this.foo = 1 且依赖 var foo 提升后同名，替换后行为就变了。
更隐蔽的是 for 循环中的函数创建：
for (var i = 0; i console.log(i), 100); }
这段代码输出 3, 3, 3；若改为 let i，输出 0, 1, 2。自动化工具无法 100% 推断开发者是否“有意依赖 var 的提升特性”，所以默认应跳过所有循环头部声明，或加配置开关提示人工确认。
- AST 分析无法覆盖动态执行路径，对闭包捕获变量的判断只能基于静态可达性，保守策略是：只要在循环体内定义了函数并引用该变量，就不自动转换
-
try/catch中的var e不能转const e，因为e在 catch 块外不可访问，但var e会提升到函数顶部——这属于作用域污染，但转换后可能意外暴露变量 - TS 项目里
var带类型注解（var x: string）需保留注解，jscodeshift默认不处理 TS 节点，得启用@babel/plugin-transform-typescript并确保t.tsTypeAnnotation()正确附着
var 换成 let，而是确认这次替换不会让某个隐藏的 setTimeout 回调突然开始报 ReferenceError，或者让一个跨文件的 this.xxx 访问悄然失效。自动化只是放大镜，不是决策者。
