go中所有函数参数均为值传递，slice/map等类型因底层含指针而可修改内容，但操作对象不同导致行为差异；需用 t的三种情形：修改原数据、结构体过大、方法集仅定义于 t；小结构体值传更优，指针可能引发逃逸。
func参数永远是值传递，别被slice/map骗了
Go里没有“传引用”这回事，func参数全是值传递——包括[]int、map[string]int、chan int甚至*T。所谓“能改内容”，只是因为这些类型底层是含指针的结构体（比如slice是{ptr *T, len, cap}），拷贝后ptr仍指向同一块内存。
常见错误现象：append(s, x)后原切片没变；m["k"] = v却生效了。原因不是“类型不同”，而是操作对象不同：前者改的是s这个副本的ptr字段（扩容时指向新数组），后者改的是ptr所指的哈希表数据。
-
s[0] = 999→ ✅ 影响原slice，因修改底层数组 -
s = append(s, 1)→ ❌ 不影响调用方，除非你接收返回值：s = f(s) -
m["x"] = 1→ ✅ 生效，因只动哈希表，不动m结构体本身 -
m = make(map[string]int)→ ❌ 只重置副本，原m不变
什么时候必须用*T而不是T？
不是“想改就加星号”，而是两个硬性信号触发才该用指针：
- 需要修改调用方变量所指向的数据（如更新结构体字段、重置状态）→ 必须用
*T，否则改的是副本 - 结构体太大（
unsafe.Sizeof(T{}) > 64字节），避免栈上拷贝开销 → 用*T更高效，但得实测，别猜 - 类型实现了某个接口，且方法集只对
*T定义（如sync.Mutex.Lock()要求*sync.Mutex）→ 参数也得是*T，否则编译失败
注意：nil指针解引用会panic: runtime error: invalid memory address or nil pointer dereference，用前必须检查。
小结构体传值更安全，别盲目加*
像type Point struct{ X, Y int }这种≤16字节的小结构体，值传递反而更快：编译器可能优化进寄存器，无逃逸、无GC压力。传*Point反而多一次解引用、多8字节指针开销。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
真正危险的是误判“大”：一个含[]byte或嵌套map的结构体，unsafe.Sizeof只算header大小（24/32字节），但底层数据仍共享——这时传值不等于“轻量”，只是不拷贝底层数组而已。
- 传
struct{ Data [10000]int }→ 每次拷贝80KB，必须用*T - 传
struct{ Items []string }→ 只拷贝24字节header，但Items[0] = "x"仍影响原切片 - 传
struct{ mu sync.Mutex }→ 编译直接报错：cannot assign to struct containing sync.Mutex，只能传*T
指针传参可能引发逃逸，性能未必更好
你以为*T一定省内存？不一定。如果指针被返回、存入全局map、传给goroutine或闭包捕获，编译器会判定T逃逸到堆——这反而增加GC压力和内存碎片。
验证方式：go build -gcflags="-m -l"，看输出是否含escapes to heap。常见陷阱：
-
func newT() *T { t := T{}; return &t }→t必然逃逸 -
var cache = make(map[string]*T)→ 存进去的*T让T逃逸 - 闭包里引用局部
*T变量 → 同样逃逸
性能敏感场景下，优先值传参+实测；指针是语义信号，不是性能银弹。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
