Go 1.27 嵌套匿名指针 UnmarshalJSON 触发 nil panic

原来在 Go 1.26 能读取的 JSON，换成 1.27 后在自定义 UnmarshalJSON 里触发 nil pointer panic。若外层字段又匿名嵌入了一个实现该方法的指针，先看接收者是否根本没有分配。

会触发这条路径的结构类似下面这样：

type ChildData struct {
    Value int
}

type Child struct {
    ChildData
}

func (c *Child) UnmarshalJSON(data []byte) error {
    return json.Unmarshal(data, &c.ChildData)
}

type Parent struct {
    MyChild struct {
        *Child
    }
}

代码需要导入 encoding/json。方法读取 c.ChildData 时会解引用接收者；如果 c 是 nil，panic 发生在业务方法里，甚至还没进入内层 JSON 解码。不同方法体也可能返回错误，不能认定任意自定义实现都必然崩溃。

关键在方法提升：匿名嵌入 *Child 的外层类型，也会获得它的 UnmarshalJSON 方法。Go 1.27 默认使用新 JSON 实现支撑旧 API，在这类嵌套兼容路径中，可能直接调用被提升的方法，而没有先分配那个 nil 指针。

明确初始化这一个嵌入对象

针对输入约定为对象的这一字段，可以在原解码入口先初始化它：

var target Parent
target.MyChild.Child = &Child{}

err := json.Unmarshal([]byte(`{"MyChild":{"Value":3}}`), &target)
if err != nil {
    return err
}

片段位于返回 error 的函数中。它保留嵌入指针结构，让方法接收者有实际对象；应合并到原来真正的解码入口，不能只在一个未被调用的构造函数里分配。

如果字段允许 JSON null、缺失字段与空对象有不同业务含义，预分配会影响“是否存在”的表达，需要按原契约设计显式外层解码。不要把所有 nil 指针批量初始化，再把语义变化当成兼容修复。

长期也可以使用命名字段或显式 DTO，避免外层靠方法提升意外实现解码接口。但命名字段会影响 JSON 结构与访问方式，必须一并审查，不能把匿名嵌入符号删掉后假定载荷形状不变。

构建开关可以比较，不能长期遮住模型问题

对仍只使用旧 encoding/json API 的 Go 1.27 工程，可在受控构建中使用 GOEXPERIMENT=nojsonv2 比较旧实现行为。它是编译时选择，需要重新构建程序；给正在运行的服务加环境变量不会更换已经编入的标准库。

该选择会影响工程其他 JSON 路径，并且不适合依赖新 encoding/json/v2 API 的代码，不能不加判断地设为全局环境。

截至 2026 年 10 月 21 日，针对旧语义下匿名类型方法调用的修正已有代码评审线索，但不能由此断言某个正式维护版本已经包含。采用新工具链时核对实际修复与构建产物，仍保留字段缺失、对象、null、错误类型及自定义解码错误的回归样例。

验收既要看没有 panic，也要检查 Value 真正得到预期值、未知字段和 null 的处理仍符合接口约定。用 recover 吞掉 panic 后继续使用半解码对象，会把明显失败变成难以发现的错误数据。