Go变量作用域由声明位置严格限定，函数内声明的变量仅在该函数体可见；if/for块内声明的变量不可被外层访问；同名变量遮蔽、包级初始化顺序、值/指针接收者差异是常见陷阱。
变量声明位置决定能否在函数内访问
Go 中变量作用域由声明位置严格限定，不是靠大括号“看起来在哪”来判断，而是看它是否在当前代码块的词法嵌套层级中被声明。函数参数、返回值、func 内部用 := 或 var 声明的变量，只在该函数体内可见。
常见错误是误以为 if 或 for 里的变量能被外层访问：
func example() {
if true {
x := 42
}
fmt.Println(x) // 编译错误：undefined: x
}
-
x在if块内声明，作用域仅限该块，哪怕if条件恒为真也不行 - 想跨块访问，必须把声明提到外层块（如函数开头）
- Go 不支持“变量提升”，不存在 JS 那种
var的 hoisting 行为
同名变量遮蔽（shadowing）容易引发逻辑错误
在内层作用域用相同名字重新声明变量，会遮蔽外层同名变量——这不是错误，但极易导致预期外的行为，尤其在嵌套 if 或 for 中。
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
func shadow() {
x := "outer"
if true {
x := "inner" // 新变量，遮蔽外层 x
fmt.Println(x) // "inner"
}
fmt.Println(x) // "outer" —— 外层 x 未被修改
}
- 遮蔽只发生在声明时（
:=或var x string），赋值（x = "new"）不会创建新变量 -
go vet可检测部分遮蔽，但不覆盖所有场景；建议开启staticcheck或revive的shadow检查 - 循环中尤其危险：
for _, v := range items { v := v }是常见冗余遮蔽，通常应删掉内层声明
包级变量与 init 函数的初始化顺序影响访问安全性
包级变量（在函数外用 var 声明）在包初始化阶段按源码顺序初始化，而 init() 函数在所有变量初始化后执行。若在 init() 中访问尚未初始化的包级变量，会得到零值，且无编译错误。
立即学习“go语言免费学习笔记（深入）”；
var a = func() int { return b + 1 }() // b 还没初始化，a = 1（b 是 int 零值）
var b = 100
func init() {
fmt.Println(a) // 输出 1，不是 101
}
- 包级变量初始化表达式中，只能安全引用前面已声明并初始化的变量
- 跨文件时，初始化顺序按
go build解析的文件顺序，不可控；避免在包级初始化中依赖其他包级变量 - 需要依赖关系时，改用
init()函数中显式赋值，或用惰性初始化（sync.Once+ 函数）
方法接收者类型决定能否修改结构体字段
作用域规则延伸到方法接收者：值接收者（func (s S) Method()）操作的是结构体副本，无法修改原始字段；指针接收者（func (s *S) Method()）才能写入。这和变量作用域无关，但常被初学者混淆为“作用域限制了修改权限”。
type Counter struct{ n int }
func (c Counter) Inc() { c.n++ } // 无效：修改的是副本
func (c *Counter) IncPtr() { c.n++ } // 有效：通过指针修改原值
func main() {
var c Counter
c.Inc()
fmt.Println(c.n) // 0
c.IncPtr()
fmt.Println(c.n) // 1
}
- 值接收者方法不能修改字段，不是因为“访问越界”，而是因为根本没拿到原变量的地址
- 如果结构体较大，值接收者还会带来不必要的拷贝开销
- 同一类型的方法集要一致：混用值/指针接收者可能导致接口实现不完整
