传指针进channel能减少复制开销，但须满足结构体可拷贝、生命周期可控、并发访问有保护三前提；含sync.mutex等不可拷贝字段的结构体必须用t，超64字节优先t，小结构体（
传指针进 channel 能显著减少复制开销，但不是“只要大就传指针”——必须同时满足结构体可拷贝、生命周期可控、并发访问有保护这三个前提，否则容易引发 panic 或竞态。
含 sync.Mutex 的结构体必须用 *T，否则运行时报 cannot copy sync.Mutex
Go 禁止拷贝任何包含 sync.Mutex、sync.RWMutex、sync.Once 等不可拷贝字段的结构体。值传递会触发编译期或运行期 panic。
- 错误写法：
ch := make(chan Config, 1)，其中type Config struct { mu sync.Mutex Data map[string]string }→ 运行时 panic - 正确写法：
ch := make(chan *Config, 1)，发送前取地址：ch - 注意：传指针后，所有 goroutine 共享同一把锁，需确保锁的使用逻辑正确（比如在读写前加
mu.Lock()）
unsafe.Sizeof(T{}) > 64 是传指针的硬门槛，小结构体传值更安全
实测表明，当结构体底层内存占用超过 64 字节时，传值带来的堆分配和 GC 压力开始明显上升；而小于 16 字节（如几个 int + string）时，传值与传指针性能差异基本可忽略。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 判断方式：
fmt.Printf("size: %d", unsafe.Sizeof(MyStruct{})) - 典型场景：一个带 1KB JSON 字段的
type Event struct { ID string; Payload []byte; Timestamp time.Time }，unsafe.Sizeof往往超 1024 → 必须用*Event - 反例：一个只有两个
int64的type Range struct { Start, End int64 }，大小为 16 → 传值更清晰，无共享风险
接收方修改数据会影响原始对象，这不是 channel 特性，是 Go 指针语义
channel 只负责类型匹配和调度，不干预指针指向的内容。一旦多个 goroutine 通过 chan *T 拿到同一个指针，就天然构成共享内存模型，必须自行同步。
- 常见错误现象：
fatal error: concurrent map writes或随机字段值被覆盖，往往是因为多个 worker 同时写received.Data["key"] = val - 安全做法：要么在接收后立即深拷贝（慎用，可能抵消传指针收益），要么用
sync.Mutex包裹读写区，要么改用命令式封装（如定义type UpdateCmd struct { Key string; Val interface{} }+ 单一 owner goroutine 处理） - 特别注意栈变量逃逸：不要把局部变量地址发进 channel，例如
func handle() { u := User{}; ch → <code>u可能被回收，接收方拿到悬空指针
谁负责内存生命周期？Go 不管，你得管
这是最常被忽略的坑。channel 不管理指针指向的对象是否还活着，也不跟踪引用计数。如果发送方在接收方还没处理完时就让对象脱离作用域（比如函数返回、切片收缩、map 删除），接收方拿到的就是野指针。
- 安全模式：数据由长期存活的 goroutine 持有（如配置中心、缓存管理器），只通过 channel 发送其指针
- 危险模式：从
for range items中直接取&item发送 → 所有指针都指向同一个被反复覆盖的栈变量 - 缓解手段：对高频复用结构体，用
sync.Pool管理*T实例，归还时机明确（如 worker 处理完立刻pool.Put(p)）
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
