Go maps.Clone 怎样保留错误信息

我在整理一组批量处理结果时遇到过一个容易误判的场景：原 map 里放着每个任务对应的 error，复制后希望继续查看错误文本和错误链，却担心 maps.Clone 会把错误信息丢掉。实际情况是，maps.Clone 会复制 map 的键和值；如果值是 error，克隆后的 map 仍然保留这些错误值。但它是浅拷贝，不会自动复制错误对象内部的指针、切片或其他可变状态。

结论：对于 map[string]error，直接使用 maps.Clone 就能保留每个键对应的错误值、Error() 文本以及可继续调用的错误链入口。只有当错误值指向了需要独立修改的自定义对象时，才需要逐项重建，而不是把 Clone 当成深拷贝。

官方地址：https://pkg.go.dev/maps

先看清 maps.Clone 复制的是什么

Go 官方文档把 maps.Clone 定义为对 map 的浅克隆：新 map 会重新建立键值关系，键和值通过普通赋值写入。对于 map[string]error，这里的“值”是一个接口值，所以接口中保存的错误对象引用会被复制到新 map 中。

package main

import (
    "errors"
    "fmt"
    "maps"
)

func main() {
    original := map[string]error{
        "cache": fmt.Errorf("读取缓存失败: %w", errors.New("连接超时")),
    }

    // Clone 复制键和值；这里的 error 接口值会继续保留错误文本和链入口。
    copied := maps.Clone(original)

    fmt.Println(copied["cache"])
    fmt.Println(errors.Is(copied["cache"], original["cache"]))
}

这里需要把两个层次分开：copied 是一个新的 map，向它新增或删除键不会改变 original；但 copied["cache"] 中的错误对象并没有因为 Clone 而被重新构造。错误信息没有丢失，错误对象的身份也没有被“深复制”。

为什么 Error 文本和错误链仍然可用

error 是接口，常见的包装错误会把底层错误放进一个错误链。复制 map 时，接口值本身被赋给新 map 的对应键，因此调用 Error() 仍然得到相同的可读文本，使用 errors.Is 或 errors.As 也仍然可以沿着原来的错误关系查找。

不过不要把“错误链入口保留”理解成“每一层错误都创建了副本”。例如自定义错误结构体里如果有指针字段，两个 map 里的 error 可能最终指向同一份可变数据。

package main

import (
    "errors"
    "fmt"
    "maps"
)

type DetailError struct {
    Code  string
    Notes *[]string
}

func (e *DetailError) Error() string {
    // 错误文本只展示稳定字段，Notes 用于说明浅拷贝边界。
    return e.Code
}

func main() {
    notes := []string{"first"}
    original := map[string]error{
        "job": &DetailError{Code: "E_JOB", Notes: ¬es},
    }
    copied := maps.Clone(original)

    // errors.As 仍能从克隆后的接口中取出同一类自定义错误。
    var detail *DetailError
    fmt.Println(errors.As(copied["job"], &detail), detail.Error())
}

如果只读错误信息，这种共享通常没有问题；如果后续代码会修改 Notes 指向的切片，就必须明确所有权，否则修改可能被另一份结果看到。

nil map 和自定义 map 类型也能直接处理

排查批量结果时，我更愿意把 nil 输入单独写进测试表，因为“没有结果”与“有一个空 map”经常承载不同的业务含义。maps.Clone 对 nil map 可以保持 nil 语义；空但非 nil 的 map 则仍是一个可写的独立 map。

package main

import (
    "fmt"
    "maps"
)

type ErrorByTask map[string]error

func main() {
    var absent ErrorByTask
    empty := ErrorByTask{}

    // 命名 map 类型会保留类型；nil 输入不应被误改成“已创建的空 map”。
    clonedAbsent := maps.Clone(absent)
    clonedEmpty := maps.Clone(empty)

    fmt.Println(clonedAbsent == nil, clonedEmpty == nil)
}

这段判断的重点不是输出真假，而是接口约定：调用方如果用 nil 表示“本次没有生成结果”，就不要在 Clone 后无条件把 nil 转成空 map；如果只关心可写性，则可以在业务边界主动归一化。

什么时候必须逐项重建错误值

如果错误对象只是不可变文本或包装链，直接 Clone 通常足够。如果错误结构里带有会被修改的指针、切片、map 或缓存字段，并且克隆结果必须拥有独立生命周期，就要逐项转换。

package main

import (
    "fmt"
    "maps"
)

type TaskError struct {
    Code  string
    Hints []string
}

func (e *TaskError) Error() string {
    // 返回稳定的错误码；Hints 的独立复制由 cloneErrors 负责。
    return e.Code
}

func cloneErrors(src map[string]*TaskError) map[string]*TaskError {
    dst := make(map[string]*TaskError, len(src))
    for key, value := range src {
        if value == nil {
            // 保留 nil 值，避免把“没有错误对象”伪造成空结构体。
            dst[key] = nil
            continue
        }
        // 结构体和切片都重新分配，克隆结果才拥有独立的可变字段。
        cloned := *value
        cloned.Hints = append([]string(nil), value.Hints...)
        dst[key] = &cloned
    }
    return dst
}

func main() {
    src := map[string]*TaskError{"job": {Code: "E_JOB", Hints: []string{"retry"}}}
    shallow := maps.Clone(src)
    deep := cloneErrors(src)
    fmt.Println(shallow["job"] == src["job"], deep["job"] == src["job"])
}

这里没有对 error 接口本身做神奇处理，而是先确定具体错误结构，再按字段所有权重建。若错误来自第三方库，通常不要擅自复制其内部结构；保留原错误并在外层增加上下文，往往更安全。

按这张清单选择 Clone 还是重建

总结

maps.Clone 能保留 map[string]error 中的错误值、错误文本和错误链入口，因为它复制了 map 的键和值；它不能保证自定义错误对象内部的可变字段获得独立副本。先判断业务需要的是“新的 map 容器”，还是“完全独立的错误状态”，再决定直接 Clone 或逐项重建，代码会更稳定。

相关问题还包括：maps.Clone 为什么不等于深拷贝？map[string]error 怎样保留 nil 错误？如果错误需要重试，是否应该把重试状态放进 map？这些问题都应回到值的所有权和生命周期，而不是只看函数名。