传指针比传值更快的核心条件是：结构体≥32字节且高频调用，或必须修改原值；小结构体（≤8字节）传值更快，因避免解引用与逃逸开销。
Go 中绝大多数场景下，盲目用指针不会提升执行效率，反而可能因逃逸分析导致堆分配、GC 压力上升；真正能提效的，是精准控制值拷贝与内存复用的边界。
什么时候传指针比传值更快？
核心看结构体大小和是否被修改。Go 对小对象（通常 ≤ 机器字长，如 64 位下 ≤ 8 字节）传值成本极低，比如 int、string（只含指针+长度+容量）、time.Time（24 字节，但 runtime 有优化）——这些传值比传指针还快或持平。
真正该用指针的是：大结构体（≥ 32 字节）、频繁调用且不修改内容的只读场景（避免重复拷贝）、或必须修改原值的逻辑。
-
type User struct { ID int64; Name [64]byte; Email [128]byte }—— 大小约 200 字节，每次传值就是一次 memcpy - 函数签名用
func process(u *User)可省拷贝，但需确认u不会在 goroutine 中长期持有（否则触发逃逸） - 如果函数只读且结构体可被编译器证明“生命周期短”，加
//go:noinline+go tool compile -gcflags="-m"观察是否仍逃逸
为什么给 slice/map/channel 传指针通常是错的？
slice、map、channel 本身已是引用类型（底层含指针字段），传值开销固定（一般 24 字节以内），再套一层 *[]T 不仅没收益，还会干扰逃逸分析、强制堆分配。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
func updateSlice(s *[]int) { *s = append(*s, 1) }—— 调用方必须取地址，且s本身已逃逸 - 正确写法：
func updateSlice(s []int) []int { return append(s, 1) }—— 返回新 slice，调用方自行赋值，无额外指针间接层 - 例外：若函数需同时修改底层数组内容 和 slice header（如重切、扩容后覆盖原变量），才考虑指针，但应先评估是否设计合理
struct 字段用指针还是值？关键看语义与零值行为
字段用指针（如 *time.Time）主要解决“可空性”问题，不是为了性能。它带来三重代价：额外解引用、内存碎片、GC 扫描负担。
- 如果字段必有值（如
User.CreatedAt time.Time），直接用值类型 —— 零值time.Time{}是合法且明确的 - 如果字段可为空（如 “最后登录时间” 可能未发生），优先用
sql.NullTime或自定义可空类型，而非*time.Time—— 减少 nil panic 风险，也避免 GC 追踪单个时间对象 - 嵌套结构体字段若为指针（如
Profile *UserProfile），要警惕深度拷贝时的浅拷贝陷阱：复制 struct 后两个实例共享同一*UserProfile，修改会互相影响
逃逸分析才是真正的性能开关
是否上堆，不取决于你写了 &x，而取决于编译器能否证明变量生命周期不超过当前函数。一个局部 struct 即使全用值类型，只要被返回或传入闭包，就大概率逃逸。
- 检查方式：
go build -gcflags="-m -l" main.go—— 关注 “moved to heap” 和 “leaking param” 提示 - 常见逃逸诱因：返回局部变量地址、传入
interface{}、调用fmt.Sprintf、在闭包中捕获变量 - 想压栈？删掉所有可能导致逃逸的操作，或用
//go:stackalloc（1.22+ 实验性）配合小缓冲区，但别为微秒级差异牺牲可维护性
最常被忽略的一点：CPU 缓存行对齐比指针节省几个字节更重要。一个未对齐的 struct 可能跨两个 cache line，导致 false sharing 或额外内存访问 —— 这比传值/传指针的差异大得多。用 unsafe.Offsetof 检查布局，必要时手动填充。
