Go types.Union 怎样逐项导出联合约束

我在做泛型约束的静态分析时，最初只调用 Union.String()，得到的确实像 ~int | ~string，但后续还要判断每一项是不是带 ~、对应的基础类型是什么，字符串就不够用了。go/types.Union 已经提供了按索引读取和迭代读取两条路径：旧版本用 Len + Term，较新的 Go 版本可以直接用 Terms。

逐项导出联合约束的核心是先拿到 *types.Union，再读取每个 *types.Term 的 Type() 和 Tilde()。Union 本身只描述联合项集合，不要把它的字符串结果当成结构化数据。

先分清 Union、Term 和类型集合

Go 规范把 t1 | t2 解释为两个类型集合的并集；而 go/types 把这段联合约束表示成一个 Union，其中每一个成员是一个 Term。例如 ~int | ~string 有两个 term，第一项的类型是 int 且 Tilde() 为 true，第二项的类型是 string 且同样带有波形符语义。

这一区分很重要：Union.String() 适合日志和展示，Term.Type() 才适合后续比较、分类或生成索引。联合项的顺序来自构造时传入的切片，读取时不应自行按名称排序，否则会丢掉原始位置。

用 Len 和 Term 按索引导出每一项

Len() 返回联合项数量，Term(i) 返回第 i 项。这个组合适合需要保留索引、和其他语法节点对齐，或者项目仍要兼容没有 Terms() 的 Go 版本时使用。读取前先检查索引范围，不能直接把外部输入当成下标。

package main

import (
    "fmt"
    "go/types"
)

func dumpUnionByIndex(union *types.Union) {
    // Len 表示联合约束中有多少个 Term，索引从 0 开始。
    for i := 0; i 

这里的输出字段是结构化的：index 可用于保持源顺序，type 可交给类型比较逻辑，tilde 则能区分 int 和 ~int。如果只关心展示，可以继续调用 union.String()，但不要用它反向解析类型。

用 Terms 直接迭代联合项

当前官方文档中的 Union.Terms() 返回 iter.Seq[*types.Term]，适合只需要顺序遍历、不需要手动维护索引的代码。它在 Go 1.24 加入，使用前要把项目的最低 Go 版本和构建环境对齐；如果库需要覆盖更老版本，继续保留上面的 Len + Term 写法。

func dumpUnion(union *types.Union) {
    // Terms 按 Union 内部顺序提供每一个联合项。
    for term := range union.Terms() {
        // 将类型和值域标记拆开，便于生成 JSON 或规则索引。
        fmt.Printf("type=%s tilde=%t\n", term.Type(), term.Tilde())
    }
}

导出时最容易踩的几个边界

第一，NewUnion 不能接收空联合项；官方文档明确说明空 union 在语法上不可出现。第二，Term(i) 是按下标访问，越界会让问题延后到运行时，边界来自不可信数据时应先比较 i 。第三，Tilde() 只是告诉你语法上的底层类型集合标记，不等价于“把所有满足约束的命名类型列出来”，因为类型集合可能覆盖当前程序之外的类型。

最后，若分析目标是生成规则或序列化结果，建议保存 index、Type().String() 和 Tilde() 三个字段；若目标是诊断日志，直接保存 union.String() 会更短。这样既保留机器可用的信息，也避免再次解析展示字符串。

小结与相关问题

按索引导出时使用 Len 和 Term，需要简洁遍历时使用 Terms；无论哪种写法，真正应该落盘的是每个 Term 的类型和 Tilde 标记，而不是只保存联合表达式文本。

• Union.Term(i) 返回的是什么？ 返回第 i 个 *types.Term，再通过 Type() 和 Tilde() 读取其组成。
• 什么时候不适合使用 Terms？ 项目需要兼容 Go 1.23 或更早版本时，应使用 Len + Term，或在兼容层封装遍历。
• 为什么不直接解析 Union.String？ 字符串适合展示，解析它会把类型语义重新变成脆弱的文本规则。