Go 1.27 泛型调用崩溃

升级 Go 1.27.0 后，泛型函数接收一个嵌入接口的结构体指针，调用接口方法时出现 SIGSEGV，或报 unreachable method called. linker bug?。接口字段明明已经初始化，普通直接调用也正常时，应检查这一版编译器处理接口包装方法的回归。

这项问题已包含在 Go 1.27.2 的修复中。它针对特定的嵌入接口、指针类型参数与方法调用路径，不是所有 Go 空指针或泛型崩溃的共同原因。

有效方法可能被链接器当成未使用

以下是触发形状的简化示例，不需要 unsafe 或 cgo：

package main

import "fmt"

type Conn interface{ Hello() }
type PoolConn struct{ Conn }
type CustomConn struct{}

func (CustomConn) Hello() { fmt.Println("Hello") }
func call[T Conn](c T) { c.Hello() }

func main() {
    call[*PoolConn](&PoolConn{Conn: CustomConn{}})
}

结构体的接口字段有实际对象，问题不能用“接口没有赋值”解释。受影响编译器为嵌入接口的方法包装生成尾调用，却没有把下面的接口调用标记为已使用。链接器清理未使用代码时，可能删掉实际需要调用的方法。

不同架构的报错可以不同：macOS ARM64 上可能跳到无效地址，Linux AMD64 上可能明确进入不可达方法的报错。判断应结合工具链、类型结构和调用路径，不只比较信号名称。

检查构建出来的程序，而不只是本机 Go

记录 CI 或发布步骤实际选择的 Go 版本、目标系统与架构。机器已经安装新版 Go，不表示正在运行的程序也由新版编译；修复编译器生成代码的问题，需要重新构建对应应用。

确认接口字段并非 nil，再保留原来的泛型调用与普通直接调用差异。需要缩小复现时使用隔离的小程序，不要在生产请求里反复触发进程崩溃。

go vet 没有告警，或指针检查没有发现问题，都不能证明这条编译器与链接器路径正确。这里没有要求应用使用不安全指针，也不应先把正常业务对象改成另一种内存布局。

用包含修复的工具链重新构建

采用与项目兼容、包含修复的 Go 1.27.2 或后续维护版本，再通过原构建与部署流程生成应用。保留原 GOOS、GOARCH、构建标签、cgo 设置和依赖约定，确认 CI 没有通过工具链自动选择重新回到旧版。

1.27.2 在尾调用的接口分支中补上了方法使用标记，避免链接器丢弃所需调用。验收应从原来的泛型指针入口确认实际方法被执行，程序没有再因该路径崩溃，同时保留普通调用的行为。

不要在初始化时先调用一次值类型版本，试图“预热”后面的指针实例。这样的调用可能偶然改变代码保留结果，但没有修正缺失的使用标记。

把全部指针参数换成值也可能改变对象身份、复制行为或锁的使用，不能作为机械替换方案。确需临时改写调用方式时，先核对业务语义，再独立验收。

保留原构建配置、失败记录和可恢复的应用产物。升级后若仍崩溃，继续检查实际发布版本、nil 值、不安全操作与新的堆栈，不能把每个 SIGSEGV 都归到已经修复的接口尾调用缺陷。