ast本身不支持批量重命名变量，真正实现语义级重命名需依赖go/types+ast.inspect或直接调用gopls的rename rpc；手动遍历ast极易出错且不安全。
ast 本身不提供“批量重命名变量”的能力——它只是 Go 源码的语法树表示，没有作用域分析、引用追踪或代码生成逻辑。真正在做语义级重命名的是 golang.org/x/tools/go/ast/inspector + golang.org/x/tools/go/types 这套类型检查+引用解析组合，或者直接复用 gopls 的底层能力。
如果你手写 ast 遍历想改变量名，大概率只会做错三件事：改了不该改的标识符（比如字符串里的同名文本）、漏掉闭包内引用、破坏作用域嵌套关系。别从零造轮子。
go/types + ast.Inspect 是唯一靠谱的起点
要安全地重命名一个局部变量，必须知道：
- 它在哪个函数作用域内定义
- 哪些
Ident节点是它的引用（不是所有同名Ident都算） - 是否被导出、是否跨文件、是否在
go语句里被捕获
go/types 提供了 types.Info.Uses 和 types.Info.Defs 映射，能把每个 *ast.Ident 绑定到对应对象（types.Object）。这才是重命名的依据。
- 先用
loader.Load加载包（支持多文件），拿到*types.Package和完整types.Info - 遍历
info.Defs找到目标变量对应的types.Var - 再查
info.Uses获取所有引用该变量的*ast.Ident节点 - 对这些节点的
Name字段赋新值，最后用format.Node或gofmt写回文件
注意：这不处理注释、字符串字面量里的同名文本——那是 Search for text occurrences 的范畴，不属于语义重命名。
直接调 gopls 的 rename 方法最省事
gopls 的 textDocument/rename RPC 已经封装好全部逻辑：作用域判断、跨文件引用收集、冲突检测、预览生成。你不需要解析 ast，只需发个 JSON-RPC 请求。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 启动
gopls（确保在$GOPATH/bin或$HOME/go/bin可执行） - 构造请求体，包含文件路径、行号、列号（光标位置）、新名字
- 用
net/rpc/jsonrpc或简单 HTTP POST 发送 - 解析响应里的
changes字段，按uri → [TextEdit]应用修改
好处是：自动处理 for 循环内短变量声明、闭包捕获、receiver 方法参数、甚至 interface 实现方法签名里的形参名（只要它们是同一对象）。
坏处是：依赖外部进程；无法嵌入纯库；Windows 上路径 URI 要转 file:///C:/path 格式。
手动 ast 遍历改名只适用于极简场景
比如：你确定变量只在一个函数内定义+使用，且没被闭包捕获，也不叫 err、ok 这类常见名，那可以跳过类型系统，直接：
- 用
ast.Inspect找到<em>ast.AssignStmt</em>或ast.DeclStmt中的*ast.Ident - 记录其
NamePos，再遍历同函数内所有*ast.Ident，比对obj是否为同一地址（需先做简单作用域模拟） - 改
Name，然后用printer.Fprint输出
但这种代码脆弱得离谱：加一行 go func() { _ = x }() 就失效；换一个 Go 版本可能因 ast 结构微调而漏改。
真正麻烦的从来不是“怎么改”，而是“哪些能改、哪些不能动、改完会不会让别人看不懂”。gopls 早把这些边界画清楚了，没必要自己再踩一遍。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
