go中不可变对象需靠封装实现：不暴露可变引用、不提供修改方法；返回切片/map等必须复制；接口应只含getter；更新应返回新实例而非修改原值。
Go 里没有“不可变对象”这个语言特性，只能靠约定和封装模拟
Go 语言本身不提供 final、const struct 或只读字段语法，所谓“不可变”，本质是**不让外部拿到可修改的引用 + 不暴露可变方法**。常见错误是只把字段设为小写（未导出），却返回了切片或 map 的原始引用——这会让调用方直接改掉内部状态。
- 永远不要在结构体方法中返回
[][]byte、[]string、map[string]int等可变容器的原始引用；该复制就复制 - 构造函数（如
NewConfig()）应做深拷贝或只接受只读输入（如io.Reader、string） - 如果结构体含指针字段（比如
*bytes.Buffer），即使字段未导出，也需在访问器中返回副本（buf.Bytes()而非buf）
并发安全 ≠ 不可变，但不可变是最省心的并发安全手段
很多人以为加个 sync.RWMutex 就算“线程安全”，其实只是掩盖了数据可变带来的复杂性。而真正不可变的对象（比如每次更新都返回新实例），天然无锁、无竞态，go run -race 也扫不出问题。
- 对高频读、低频写的场景（如配置、路由表），用不可变模式比读写锁更轻量：避免了锁开销和死锁风险
- 注意：不可变不等于零分配——每次
WithTimeout(30 * time.Second)都 new 一个新 struct，要评估 GC 压力；必要时可配合对象池（sync.Pool）复用底层字段 - 别在不可变结构体里藏可变字段，比如字段是
time.Timer指针：Timer 可被Stop()或Reset()，破坏不可变契约
用结构体嵌入 + 接口隔离控制可变边界
纯靠私有字段不够，得用接口把“只读视图”和“可变实现”分开。典型做法是定义一个只读接口，再让具体类型实现它，但不暴露构造可变实例的途径。
type ConfigReader interface {
Timeout() time.Duration
Host() string
}
type config struct { // 小写，不导出
timeout time.Duration
host string
}
func (c *config) Timeout() time.Duration { return c.timeout }
func (c *config) Host() string { return c.host }
// 外部只能拿到 ConfigReader，无法转型回 *config，也无法修改字段
func NewConfig(h string, t time.Duration) ConfigReader {
return &config{host: h, timeout: t}
}- 接口方法不能返回可变容器原始引用，
Labels() map[string]string是错的，应改为Labels() []string或LabelKeys() []string+LabelValue(key string) string - 避免在接口中暴露
SetXXX()方法——那已不是不可变模式，而是带锁的可变对象 - 如果必须支持更新，提供 builder 模式：返回新实例，而非修改旧实例（
c.WithHost("x").WithTimeout(5)）
测试不可变性比想象中容易，但常被跳过
光看代码逻辑不保险。最直接的验证方式：在测试里取两次 getter 返回值，用 reflect.DeepEqual 比较，再尝试修改其中一份，看是否影响另一份。
立即学习“go语言免费学习笔记（深入）”；
- 对切片字段，测试要显式修改元素：
s := c.Data(); s[0] = 999; if c.Data()[0] == 999 { t.Fatal("mutated!") } - 使用
go vet -tags=unsafe可捕获部分不安全的反射操作，但不能替代运行时验证 - 竞态测试别只跑
go test -race，加个循环 goroutine 并发调用 getter 1000 次，确认没 panic 或返回不一致结果
真正的难点不在怎么写不可变结构体，而在于整个调用链是否守住那一道“不暴露可变引用”的线——中间任何一个函数把 map 或 []byte 直接传出去，整条链就破功了。
