应手动实现拷贝逻辑当结构体字段稳定、性能敏感或需跳过sync.Mutex等特殊字段；第三方库依赖反射或代码生成，无法处理未导出字段、func、chan等类型，且time.Time、nil map等易出错；结构体字面量赋值适用于基本类型组合；定义Clone()方法最可控，支持编译期检查与业务定制；禁用json序列化作深拷贝，因其丢字段、精度丢失且性能差。
什么时候该自己写拷贝逻辑，而不是用库
当你结构体字段稳定、性能敏感、或需要跳过某些字段（比如 sync.Mutex）、特殊处理时间或指针语义时，手动实现才是唯一可靠路径。第三方库如 ulule/deepcopier 或 copier 本质是反射或代码生成，无法替代你对业务字段的理解。
常见误判：以为“用了 deepcopier 就万事大吉”，结果发现 time.Time 被序列化成字符串、nil map 变成空 map、chan 字段直接 panic —— 这些不是库的 bug，而是 Go 类型系统的硬限制。
- 必须导出字段（首字母大写）才能被任何反射/生成类库访问
- 未导出字段、
func、chan、unsafe.Pointer永远无法深拷贝，强行处理会 crash - 如果结构体里嵌套了自定义类型但没实现
DeepCopy()方法，反射方案会静默失败或浅拷贝
用结构体字面量做轻量级“原型复制”
当你的结构体只含基本类型（int、string、time.Time）、数组、或不含引用字段的嵌套 struct 时，直接赋值或字面量初始化就是最 Go 的方式，零开销、无依赖、语义清晰。
示例：
立即学习“go语言免费学习笔记（深入）”；
type Config struct {
Timeout int
Retries int
Labels []string // 注意：这是引用类型，需单独处理
}
base := Config{Timeout: 30, Retries: 3}
copy := Config{
Timeout: base.Timeout,
Retries: base.Retries,
Labels: append([]string(nil), base.Labels...), // 手动深拷贝 slice
}
-
Labels字段必须显式append([]string(nil), base.Labels...)或make+copy，否则共享底层数组 - 字段名不一致？直接写进去，不用 tag，也不依赖反射
- 想忽略某个字段？不写它就行，比配置 ignore tag 更直观
如何让结构体自带 Clone() 方法
为结构体定义一个 Clone() 方法，是最可控、最易测试、也最容易和业务逻辑对齐的方式。它不依赖外部库，编译期检查，且可自由决定哪些字段要深拷贝、哪些复用、哪些重置。
示例：
立即学习“go语言免费学习笔记（深入）”；
func (c Config) Clone() Config {
clone := c // 先值拷贝
if c.Labels != nil {
clone.Labels = make([]string, len(c.Labels))
copy(clone.Labels, c.Labels)
}
if c.Meta != nil {
clone.Meta = &Meta{ // 指针字段解引用后复制
Version: c.Meta.Version,
ID: c.Meta.ID,
}
}
return clone
}
- 方法接收者用值类型（
func (c Config) Clone()）更安全：避免意外修改原对象 - 切片、map、指针字段必须逐个判断是否为
nil，再决定新建还是复制 - 如果字段是接口类型（
interface{}），且底层是 struct，可尝试类型断言后调用其Clone()；否则只能浅拷贝或返回 error
避免把 json.Marshal/Unmarshal 当深拷贝用
它常被当作“免配置深拷贝”兜底方案，但副作用明显：丢未导出字段、time.Time 变字符串、nil slice/map 变空实例、浮点精度丢失、不支持 chan 和 func —— 这些问题在线上环境可能潜伏数月才暴露。
- 仅适合 DTO、配置结构体等纯数据对象，且字段全部导出
- 性能差：一次 Marshal+Unmarshal 比手动复制慢 10 倍以上，高频调用会拖垮接口 p99
- 如果结构体里嵌套了
http.Client或自定义io.Reader，json会直接 panic
真正轻量的模块，不是功能最多，而是边界最清、行为最可预测。你写的每一行拷贝逻辑，都应该能回答清楚：“这个字段为什么必须深拷？改它会不会影响别人？”
