传递指针前须确认是否真需修改原数据或避免大结构体拷贝；小结构体（如仅含两个string字段的user）传值更安全清晰，含sync.mutex、[]byte、map或超4–5字段才考虑指针。
传递指针前先确认结构体是否真的需要指针
很多情况下，传指针不是为了性能，而是为了修改原数据或避免大结构体拷贝。但小结构体（比如 User 只含两个 string 字段）传值更安全、更清晰，编译器也会做逃逸分析优化。如果结构体含 sync.Mutex、[]byte、map 或超过 4–5 个字段，才值得考虑指针。
常见错误现象：func process(u User) 里改 u.Name 不生效——这不是 bug，是 Go 值传递的正常行为。别因为“没改成功”就盲目改成 *User，先看意图：你是否真要修改调用方持有的原始实例？
- 函数名含
Update、Set、Configure→ 必须传指针 - 结构体字段含
slice或map→ 传值仍会共享底层数据，需特别注意append是否扩容 - 想彻底隔离副本？手动深拷贝：对
slice用make+copy，对map遍历赋值
channel 类型声明必须显式写成 chan *T
Go 不允许隐式转换，chan T 和 chan *T 是完全不同的类型。想传指针，就得在定义 channel 时明确写出星号。
示例中若误写成 ch := make(chan User, 1) 却试图发送 &u，编译直接报错：cannot use &u (type *User) as type User in send。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确写法：
ch := make(chan *User, 1) - 缓冲区大小与是否传指针无关，只影响阻塞行为；但传指针时建议设缓冲（如 1–10），避免 goroutine 持有指针过久导致悬空
- 接收方拿到
*User后，务必检查是否为nil，尤其当发送方可能发空指针时
多 goroutine 并发读写同一指针指向的数据必须加锁
channel 传递指针本身不提供同步保障。只要多个 goroutine 拿到同一个 *User 并同时读写其字段，就会触发竞态——go run -race 可能不立刻报，但风险真实存在。
典型错误：一个 goroutine 往 user.Addresses append，另一个 goroutine 清空 user.Addresses = nil，中间无互斥，结果 panic 或数据丢失。
- 最简方案：用
sync.Mutex或sync.RWMutex包裹所有对指针所指数据的访问 - 更 Go 风格的做法：把所有状态操作收束到单个 goroutine，用
select处理多个 channel 事件（如updateChan、resetChan） - 若只是原子字段（如
int64计数器），可用atomic替代锁；但struct整体不支持原子操作
避免栈变量地址通过 channel 逃逸到 goroutine
局部变量（如 u := User{...}）分配在栈上，生命周期随函数返回结束。若在此函数内取 &u 并发给其他 goroutine，该指针很快变成悬空指针。
Go 编译器会尝试逃逸分析并自动将变量挪到堆上，但不可依赖——尤其在复杂控制流或闭包中，逃逸判断可能出错。
- 稳妥做法：显式在堆上创建，如
u := &User{...}或new(User) - 慎用
map[string]*T或[]*T存储指针：这些容器本身不延长所指对象生命周期，对象被回收后指针即失效 - 若需长期持有指针，考虑封装成带生命周期管理的结构体，或改用
sync.Pool复用对象
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
