该用指针时：需修改原值、避免大结构体拷贝（>128字节）、实现接口、与C交互或需地址唯一性；不该用时：纯计算输入、只读配置初始化、返回新值不改原数据；特别注意sync.Mutex不可取地址后传。
什么时候该用指针，什么时候不该用
Go 中指针不是为了“性能优化”而存在的默认选项。值类型（int、string、struct 小于机器字长时）传参开销极小，盲目加 * 反而增加 nil panic 风险和内存逃逸概率。
- 用指针：需要修改原值、避免大结构体拷贝（如 > 128 字节的
struct）、实现接口（如io.Reader要求方法集在指针上）、与 C 交互或需地址唯一性 - 不用指针：纯计算函数输入（如
func max(a, b int) int）、配置结构体只读初始化、返回新值不改原数据（如func WithTimeout(cfg Config) Config） - 特别注意：
sync.Mutex不能取地址再传——mu := &sync.Mutex{}是错的；必须保证其地址不变，所以定义时就该是字段或全局变量
struct 字段该用值还是指针
字段是否加 * 取决于语义而非大小。如果字段代表“可选”或“可为空”，才用指针；否则优先用值类型，让零值有意义且安全。
type User struct {
ID int // 值类型：ID 永远有默认 0，不会 nil
Name string // 值类型：空字符串 "" 合法且明确
Role *string // 指针类型：仅当 Role 可能“未设置”（区别于 ""）才需要
}
-
*string能表达三种状态：nil（未设）、""（设为空）、"admin"（设为值），但代价是每次访问都要判空 - 若业务中 "" 和 “未设”无差别，就用
string；若必须区分，再用指针，但应在文档或字段名中体现意图（如RoleOpt *string） - 嵌套 struct 字段尽量用值：除非该字段本身很大，或你明确要共享/复用同一实例
函数参数和返回值的指针陷阱
Go 函数参数是传值，但传的是指针的副本——这常被误解为“传引用”。真正危险的是把局部变量地址返回，或对切片底层数组做意外修改。
- 错误示范：
func NewConfig() *Config { c := Config{Version: "1.0"} return &c // c 是栈上局部变量，返回其地址导致悬垂指针（实际 Go 编译器会自动逃逸，但语义已混乱） } - 正确做法：直接返回值，让调用方决定是否取地址：
func NewConfig() Config { return Config{Version: "1.0"} } // 使用时： cfg := NewConfig() process(&cfg) // 显式控制生命周期 - 切片参数别轻易改
cap或重分配底层数组：传[]byte进函数后做append，可能让调用方看到意外扩容——如需隔离，显式copy一份
interface{} 和泛型场景下指针更易出错
用 interface{} 接收值后，再取地址会丢失原始类型信息；泛型约束中混用指针和值类型会导致类型推导失败或运行时 panic。
立即学习“go语言免费学习笔记（深入）”；
- 避免：
var x int = 42 val := interface{}(x) ptr := &val // ptr 类型是 *interface{}，不是 *int，无法直接转回 - 泛型函数若约束为
type T any，传*int和int是不同类型，T不会自动解引用 - 若需统一处理指针和值，明确拆成两个函数，或用反射（但通常说明设计有问题）
最常被忽略的一点：Go 的 GC 不回收“逻辑上已失效但仍有指针指向”的内存。过度使用指针延长对象生命周期，反而造成内存堆积——尤其在缓存、池化、事件回调中，记得及时置 nil 或用 sync.Pool 管理。
