Go 链接时报 R_USEIFACE：检查 TypeFor 与 Comparable 的组合

go build 或 go test 在链接阶段报 R_USEIFACE ... references type:.eqfunc... which is not a type or itab，而程序只是查询结构体能否比较。若调用是 reflect.TypeFor[T]().Comparable()，且结构体需要生成等值比较辅助函数，应检查这条编译器路径。

明确出现过问题的工具链包括 Go 1.27.1、1.26.8 和 1.26.3。它在 macOS ARM64 与面向 Linux AMD64 的构建中都可触发，不是只靠换操作系统就能避开的错误。

先看类型形状和失败阶段

两个接口字段就足以构成下面的触发形状：

type Info struct {
    A any
    B any
}

var comparable = reflect.TypeFor[Info]().Comparable()

片段需要在已有导入 reflect 的 Go 包中使用。它查询类型信息，尚未比较任何实际字段值；此时出现的是工具链链接失败，不能解释成某个接口字段在运行时装了切片。

受影响路径中，TypeFor 与 Comparable 内联后，接口使用标记可能指向 type:.eqfunc... 辅助符号。链接器要求目标是类型或接口表，因而中止。单接口字段或只查询类型名未必触发，所以删减复现时要保留真正有关的类型结构。

优先局部改写反射入口

对于这里的具体结构体，可以改为：

var comparable = reflect.TypeOf(Info{}).Comparable()

若代码本身是泛型，或者不想构造 T 的零值，可使用指针类型再取元素类型：

func isComparable[T any]() bool {
    return reflect.TypeFor[*T]().Elem().Comparable()
}

这里查询的仍是 T，不是指针的可比较性。不要漏掉 Elem()；所有指针类型可比较，直接查询 *T 会把语义改掉。TypeOf 用于接口类型时还要注意动态类型与 nil，不能把针对 Info{} 的替换机械套给所有泛型。

临时禁用内联也能帮助区分这条路径，但会影响优化，适合有边界的诊断和过渡，不应作为长期全局构建设置。Go 1.27.3 的对应实现仍按 type: 前缀生成接口使用标记。选用维护工具链时，应确认目标正式版本确实能通过原来的最小构建，不只看版本号比旧版大。

验收先从原 go build 或 go test 入口确认链接完成，再检查返回的类型可比较性与原意一致。即使 Comparable() 为 true，含接口字段的值仍可能在实际比较时因动态值不可比较而 panic；这项语言边界没有因绕过链接故障而改变。