Go 1.27 编译嵌套结构体时耗尽内存

应用还没有运行，go build 已变得极慢，或 CI 中的编译进程被 OOM 终止。若问题在升级 Go 1.27 后出现，代码中又有多层按值嵌套的可比较结构体，应检查编译器生成等值比较代码的路径。

这一分支尤其涉及叶子含字符串等类型、各层反复嵌套子结构体的形状。源码很短，不代表生成的比较函数也很小。普通平坦结构体、纯内存比较类型和应用运行时内存泄漏，需要分别判断，不能只看到 OOM 就套用此结论。

查实际编译器和出错阶段

在原构建目录或 CI 环境记录实际工具链：

go version
go env GOVERSION GOOS GOARCH GOTOOLCHAIN

比较的是构建过程实际选择的版本，不只是机器上某个 Go 可执行文件。模块中的工具链要求和自动选择可能改变执行版本。

保留构建日志，区分编译进程耗尽内存与构建后应用启动失败。再检查相关类型是否可比较，子字段是否按值嵌套，以及是否反复包含相同子类型。即使没有创建该类型的变量，包级类型声明也可能触发类型描述和等值函数生成，删除一处调用不一定排除这一分支。

已关闭的问题，不等于 1.27 补丁版已修复

Go 1.27 的相关实现会展开嵌套结构体字段的比较签名与代码。重复的子结构没有按原本的共享方式保留时，生成内容可能远大于源码，编译耗时和内存占用也随之增加。

已核对的 Go 1.27.2 源码仍保留这一展开路径。对应缩减大型类型等值与哈希函数的修复进入了 1.28 主线；不能因为问题状态已经关闭，就认定升级到任意 1.27.x 都能解决。具体补丁版是否回移，需要核对那一版的正式源码或发布说明。

清理构建缓存、增加 GOMAXPROCS，可能改变一次构建的表现，但不会把生成代码的机制改回去。也不能用他人机器上的内存数字，估算自己项目必然需要多少资源。

先选择不改变业务语义的处理办法

如果触发来自测试夹具，可以降低不必要的嵌套深度，保留该测试真正要覆盖的边界。变更应说明减少了什么覆盖，不能为了通过构建把需要的行为一起删除。

业务类型则需更谨慎。把按值字段全部换成指针会改变等值比较、map 键、所有权和序列化行为；加入切片或 map 使类型不可比较，也可能改变原来允许的用法。这些都不是可以机械替换的编译修复。

若项目语言版本和依赖要求允许，可用仍受支持的 1.26 维护工具链作兼容性比较，选择经项目验证的构建版本。不要为了降低编译内存，强行绕过 go.mod、工具链最低要求或依赖所需特性。

确需缩小复现时，在隔离目录设置时间和内存预算，使用有界的类型结构。没有必要直接构造极深的倍增嵌套，重新把本机或共享 CI 压到 OOM。

通过构建后，还要检查类型行为

恢复标准是原包能在实际资源预算内完成构建，并且 CI 使用了预期工具链。修改过类型或夹具后，还要检查等值比较、map 键和序列化测试，不只看编译退出状态。

保留失败记录、源代码差异和原构建配置。需要回退时一起恢复类型或测试夹具，以及经过审定的工具链设置，避免留下本地使用一版、CI 又自动选择另一版的环境。