Go中无原生immutable关键字，需通过字段私有化、只读接口、禁止导出可变方法模拟不可变性；核心是避免共享可变状态，确保并发读无需锁、写仅限构造阶段。
Go 里没有原生 immutable 关键字，靠约定和结构设计
Go 语言本身不提供 const struct 或 immutable 类型声明，所谓“不可变对象”是靠字段私有化 + 只读接口 + 禁止导出可变方法来模拟的。这不是编译器强制的，而是开发者之间的一种契约——一旦破坏，就可能在并发场景下出问题。
常见错误现象：sync.Map 存了某个 struct 指针，另一个 goroutine 直接改了它的字段；或者函数返回了内部 slice 的引用，调用方一改就污染原始数据。
- 所有字段必须小写（未导出），只通过导出的方法访问
- 构造函数（如
NewUser）返回值应为值类型或深拷贝后的指针，避免暴露内部可变状态 - 任何返回切片、map、channel 的方法，都必须做浅拷贝（
copy）或深拷贝（手动或用json.Marshal/Unmarshal） - 不要在方法中返回
&s.field这类地址，除非你明确知道调用方不会修改它
用 struct 值类型 + 只读接口实现线程安全的“伪不可变”
值类型天然适合不可变语义：每次赋值或传参都是副本。但要注意，如果 struct 里包含 []byte、map[string]int、*sync.Mutex 这类引用类型字段，副本之间仍会共享底层数据。
使用场景：配置对象、DTO、事件消息体这类需要在多个 goroutine 间传递且不允许中途修改的数据。
立即学习“go语言免费学习笔记（深入）”；
示例：
// ✅ 正确：字段私有，只提供只读方法
type Config struct {
timeout int
host string
}
func NewConfig(timeout int, host string) Config {
return Config{timeout: timeout, host: host}
}
func (c Config) Timeout() int { return c.timeout }
func (c Config) Host() string { return c.host }
// ❌ 错误：返回了内部 map 引用
func (c Config) Options() map[string]string { return c.options } // 危险！
并发中真正要防的不是“修改”，而是“竞态访问可变状态”
很多人以为加了 sync.RWMutex 就算“线程安全”，其实只是把“可变”包装得更隐蔽了。真正的不可变设计目标是：让并发读无需锁，且写操作只能发生在构造阶段。
性能影响：值类型拷贝成本低时（[]byte），就得权衡是否用 sync.Pool 复用，或改用只读指针 + 明确文档警告。
- 不要在 struct 里嵌入
sync.Mutex或sync.RWMutex—— 这等于公开承认它是可变的 - 如果必须缓存计算结果（如
func (c Config) Hash() string），用sync.Once初始化一次，而不是每次加锁检查 - 对第三方库返回的 struct（如
http.Request），别假设它不可变；它只是 Go 标准库“约定不改”，不代表并发安全
json.Unmarshal 和 encoding/gob 是最常踩坑的不可变假象来源
当你用 json.Unmarshal 把数据塞进一个 supposedly immutable struct，实际发生的是字段赋值——如果字段是导出的，就等于绕过了所有构造逻辑和校验。
错误现象：Unmarshal 后得到一个看似合法的 Config，但 Timeout() 返回 0，因为 json 字段名没匹配上，字段保持零值；更糟的是，如果用了指针字段，反序列化会直接覆写内存地址。
- 永远为不可变 struct 实现自定义
UnmarshalJSON方法，在里面校验字段合法性 - 避免在不可变 struct 中使用指针字段（如
*string），除非你能保证 nil 检查和默认值填充逻辑完备 - 如果必须从外部解析构建对象，优先用工厂函数（
ParseConfig([]byte)）而非直接json.Unmarshal到 struct
真正难的不是写几个只读方法，而是让整个协作链路（构造 → 传递 → 序列化 → 日志打印）都不意外引入可变性。只要有一处松动，比如日志函数偷偷调了 fmt.Printf("%+v", cfg) 并触发了某个副作用方法，就前功尽弃。
