Go types.Term.Tilde 怎样保留约束中的近似类型标记

我第一次用 go/types 分析泛型约束时，最容易误判的地方不是 Union，而是其中的 Term：Term.Type() 返回的是 int，但源代码里的 ~int 还多了一层“允许底层类型为 int 的命名类型”的语义。这个语义不在返回的 Type 对象里，而是由 Term.Tilde() 单独保存。

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

要保留约束中的近似类型标记，读取时始终把 term.Tilde() 和 term.Type() 作为一对字段处理；复制时用 types.NewTerm(term.Tilde(), term.Type()) 重建 term。只保存 Type()，或者只保存 String()，都不适合作为结构化数据的唯一来源。

我先把 ~int 看成了一个普通类型

Go 约束中的 int 与 ~int 看起来只差一个波浪号，但类型集合完全不同。int 代表精确的 int；~int 代表底层类型为 int 的类型集合，因此像 type UserID int 这样的命名类型也可以落在其中。

在 go/types 中，联合约束由 Union 表示，Union 的每一项由 Term 表示。Term 的结构化含义可以理解为两个字段：

从泛型 interface 里拿到 Union

如果输入来自源码，通常先通过 types.Package.Scope 找到约束的类型名，再从 *types.Named 取出底层的 *types.Interface。约束中的类型元素会出现在 interface 的嵌入类型里，联合项对应的对象就是 *types.Union。

下面的示例只做类型结构读取，不把图示当成编译运行截图。它声明了一个包含 ~int 和 ~string 的约束，并逐项打印 term 的三个观察结果：

package main

import (
    "fmt"
    "go/ast"
    "go/parser"
    "go/token"
    "go/types"
)

func main() {
    const source = `package sample

type Scalar interface {
    ~int | ~string
}`

    fset := token.NewFileSet()
    file, err := parser.ParseFile(fset, "constraint.go", source, 0)
    if err != nil {
        panic(err) // 解析失败时先停止，避免继续读取不完整的 AST。
    }

    checked, err := new(types.Config).Check("sample", fset, []*ast.File{file}, nil)
    if err != nil {
        panic(err) // 类型检查失败时，约束对象可能还没有完整建立。
    }

    obj := checked.Scope().Lookup("Scalar")
    named := obj.Type().(*types.Named)
    iface := named.Underlying().(*types.Interface)
    iface.Complete() // 让嵌入的约束信息处于可读取状态。

    for i := 0; i 

这里最重要的不是打印格式，而是字段职责：对 ~int，String() 可能显示为 ~int，Type() 是 int，只有 Tilde() 明确返回 true。如果工具要输出 JSON、构建索引或做约束比较，应直接保存布尔值和类型信息。

读取时为什么要把两个字段绑在一起

我后来把 term 转成自己的中间结构时，采用了“展示值 + 结构值”分离的做法。展示层可以用 String() 让日志更直观，结构层则保留 Tilde 和 Type。这样即使类型名称发生格式化变化，也不会因为字符串切割失败而把 ~int 错当成 int。

一个简单的中间结构可以这样定义：

type TermRecord struct {
    Text  string      // 给日志或界面看的原始格式。
    Tilde bool        // 保留是否带 ~ 的结构化标记。
    Type  types.Type  // 保留 ~ 后面的基础类型对象。
}

func recordOf(term *types.Term) TermRecord {
    return TermRecord{
        Text:  term.String(),
        Tilde: term.Tilde(),
        Type:  term.Type(),
    }
}

不要从 Text 再用字符串前缀推断 Tilde。那样做会把格式化逻辑和数据语义耦合起来，而且遇到别的类型表示方式时很难维护。

复制 Union 时用 NewTerm 还原近似标记

Term 的公开 API 提供读取方法，但没有修改 Tilde 的 setter。需要复制或改造一个 union 时，正确做法是读取旧 term 的两个字段，再通过 types.NewTerm 创建新对象。NewTerm(false, typ) 表示精确类型项，NewTerm(true, typ) 表示近似类型项。

func cloneUnion(src *types.Union) *types.Union {
    terms := make([]*types.Term, 0, src.Len())
    for i := 0; i 

这个复制函数不改变类型对象本身，只重建 term 容器。如果后续还要把它嵌回 interface 或生成自己的类型图，建议继续保留原来的 term 顺序。Union.Term(i) 是按索引读取的，顺序对调虽然不一定改变集合语义，却会影响诊断信息、稳定序列化和差异比较。

三个容易踩到的边界

不要把 Type 当成完整的源码项

term.Type() 对 ~int 返回 int，它不会替你附带“允许同底层类型”的信息。只有在你明确不关心近似匹配时，才可以只使用这个类型对象。

不要把 String 当成稳定序列化格式

String() 适合错误信息、日志和调试输出，不适合在下次加载时反向解析。需要持久化时，至少记录 tilde 和类型的可识别信息，并在自己的格式中定义版本。

不要把任意嵌入项都强转成 Union

interface 还可以包含方法或其他类型元素。遍历 EmbeddedType 时先做类型断言检查，只有确认是 *types.Union 才访问 Len 和 Term。另外，Go 规范限制了 union term 的合法形式，类型参数不能直接作为普通 term，重建数据时也不要绕过类型检查规则。

我的落地判断：展示和结构各走一条路

如果只是给开发者看约束，直接输出 term.String() 足够直观；如果要做泛型代码索引、约束可视化、静态分析或差异比较，就应该把 Tilde()、Type() 和必要的展示文本分开保存。这样“int”与“~int”不会在后续处理里意外合并。

这也是我现在处理 go/types.Term 的固定习惯：读的时候成对读，复制的时候成对传，展示的时候才调用 String()。这个小规则能避免近似类型标记在中间层悄悄丢失。

相关问题

• Go types.Union 怎样遍历约束中的每个类型项？使用 Len() 和 Term(i) 按索引遍历；如果目标 Go 版本支持文档中的迭代器，也可以使用 Terms()。
• Term.Type() 能返回带波浪号的类型吗？不能。波浪号语义由 Tilde() 独立表达，Type() 返回的是基础类型对象。
• NewTerm 的第一个参数传 false 代表什么？代表精确类型项，例如 int，而不是近似类型项 ~int。
• 为什么不建议解析 Term.String()？因为字符串是展示结果，不是为稳定序列化设计的结构化协议；直接读取公开字段方法更可靠。