形参名与局部变量名重名会触发变量遮蔽，导致逻辑错乱或nil panic；Go中形参本质是局部变量，用:=易误遮蔽，应启用go vet -shadow检查或改用=赋值、规范命名。
形参名和局部变量名重名，会触发变量遮蔽——局部变量覆盖形参，但形参本身仍被初始化、参与函数调用流程；关键风险是逻辑错乱或 nil panic，尤其在 := 误用时。
形参本身就是函数作用域内的局部变量
Go 中函数形参（如 func foo(x int) 中的 x）在函数体内就是普通局部变量，作用域从函数开始到结束。因此，若在函数体内部再次声明同名变量（比如用 :=），就会遮蔽形参。
常见错误现象：
-
nil指针 panic：形参是*sql.DB类型，但内部又写db, err := sql.Open(...)，导致包级db未被赋值，后续调用db.Query()崩溃 - 逻辑失效：想修改形参指向的值，却因遮蔽后操作的是新变量，原形参未被触碰
使用场景举例：
立即学习“go语言免费学习笔记（深入）”；
var db *sql.DB // 全局
func InitDB(d *sql.DB) {
db, err := sql.Open("mysql", "...") // ❌ 遮蔽了形参 d，也遮蔽了全局 db
if err != nil {
log.Fatal(err)
}
// 此处 db 是新局部变量，函数退出即销毁
}
正确做法是用 = 赋值，而非 :=：
- 如果目标是赋值给形参：
d = someDB（需注意 Go 形参是传值，这样只改副本，通常无意义） - 如果目标是赋值给全局变量：
db = someDB（显式写变量名，不带:=） - 更推荐：直接返回
*sql.DB，由调用方决定是否赋给全局变量
为什么 := 是遮蔽高发区？
:= 是声明 + 赋值的复合操作。只要左侧出现**之前未声明过的变量名**，就新建变量；若该名已在当前作用域（包括形参）中存在，则 Go 会检查右侧是否有**其他新变量**需要声明 —— 只要还有至少一个新变量，整个语句就转为“部分遮蔽”：已有变量被忽略，新变量被声明。
典型陷阱：
-
db, err := sql.Open(...)在形参含db的函数里 →db被遮蔽，err被声明 -
err := doSomething()在已有形参err error的函数里 →err被遮蔽，且类型可能不兼容（如err形参是error，而右侧返回int就编译失败）
参数差异影响：
- 形参类型与右侧表达式类型不一致时，遮蔽后会报类型错误；而用
=则直接报“cannot assign toxxx”更早暴露问题 - 遮蔽后的变量生命周期仅限当前块（如
if内），出块即不可用；而形参全程可用
怎么快速发现和避免这类遮蔽？
静态检查比肉眼可靠得多。Go 官方工具链和主流 IDE 都能识别，但默认不开启警告。
实操建议：
- 启用
go vet -shadow：它会标记所有潜在遮蔽点（注意：Go 1.23+ 已将-shadow移入go vet默认检查） - IDE 设置：VS Code 的
gopls插件开启"gopls": {"analyses": {"shadow": true}} - CI 中加入：
go vet ./...，失败即阻断构建 - 命名习惯：形参避免用
db、err、ctx这类高频局部变量名；可改为srcDB、inputErr等带前缀形式
性能/兼容性无直接影响，但遮蔽导致的逻辑错误往往在运行时才暴露，且堆栈难追溯 —— 尤其在中间件、初始化函数中，容易变成“偶发 panic”。
最易被忽略的一点：遮蔽不是语法错误，编译器完全允许，也不会报 warning（除非显式启用检查）。你写的代码能跑通，不代表它做对了事。
