Go constant.Val 与 ExactString 各适合哪种序列化需求

在语法树工具、类型检查器或常量折叠逻辑里，go/constant 的 Value 经常要被写入缓存、JSON 或生成的源码。constant.Val 和 Value.ExactString 都能“把值拿出来”，但它们的输出契约完全不同：前者面向后续计算，后者面向精确文本。把两者混用，最容易出现字符串多了一层引号、浮点数失去类型，或者 Unknown 被静默写成空值。

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

需要稳定、可比较、能表达常量语义的文本时选 ExactString；需要继续做数值运算或保留 Go 动态类型时选 Val，但必须对它返回的动态类型做显式分支。JSON 协议不要直接把 Val 的 any 当作最终协议。

先把序列化目标分清楚

可以先用下面的判断表处理大多数选择：

症状：Val 拿到的是 interface{}，不是统一的数字

Val 的返回类型是 any。官方实现按常量 Kind 返回不同的动态值：布尔值是 bool，字符串是 string，整数可能是 int64 或 *big.Int，浮点可能是 *big.Float 或 *big.Rat。当值是 Unknown 或复数时，返回值是 nil。

这意味着下面这种写法虽然短，却把协议设计交给了默认类型：

package main

import (
	"encoding/json"
	"go/constant"
	"go/token"
)

func looseJSON(v constant.Value) ([]byte, error) {
	// Val 返回 any；不同 Kind 可能得到不同的动态类型。
	// 直接编码会让调用方无法区分大整数、分数、Unknown 等边界。
	return json.Marshal(constant.Val(v))
}

func makeConstant() constant.Value {
	// 用分数形式创建常量，便于观察 Val 的动态值与精确文本差异。
	return constant.MakeFromLiteral("1.25", token.FLOAT, 0)
}

问题不一定表现为报错：小整数可能看起来正常，大整数或分数则会进入另一种表示；复数和未知值还可能变成 null。所以 Val 更适合作为“内部机器值入口”，而不是不加包装的 JSON schema。

触发条件：ExactString 是精确文本，不是原始字面量

Value 接口的 String 方法允许对数字做近似展示、对长字符串做缩短；ExactString 则返回精确的、带引号的人类可读形式。对于字符串，官方文档特别提示要用 StringVal 获取不带引号的内容。

因此，字符串常量适合这样区分：

func stringForStorage(v constant.Value) string {
	// Kind String 时，ExactString 保留引号，适合区分字符串与标识符。
	if v.Kind() == constant.String {
		return v.ExactString()
	}
	// 非字符串走精确文本出口，避免误用 String 的近似展示。
	return v.ExactString()
}

func stringForBusiness(v constant.Value) string {
	// 业务字段要原始字符串内容，而不是带 Go 引号的文本。
	if v.Kind() == constant.String {
		return constant.StringVal(v)
	}
	return v.ExactString()
}

数字也有类似边界。分数会保留分子和分母关系，浮点值的精确文本可能呈现为二进制指数形式；这表示的是当前 Value 的精确数值，不是用户最初输入的十进制写法。若需求是“可逆地还原源文件字符”，还应在解析阶段单独保存 token 的原文。

根因：两条 API 的输出契约不同

从接口设计看，Val 解决的是“底层值是什么”，ExactString 解决的是“如何用精确文本表达这个值”。它们不是同一结果的两个格式化函数：

• Val 需要类型断言，优点是可以继续计算，代价是调用方必须处理动态类型。
• ExactString 统一返回 string，优点是适合键和日志，代价是文本已经经过常量语义规范化。
• String 只适合短展示，不应承担精确序列化职责。

也正因为如此，ExactString 对字符串保留引号，对复数组合实部和虚部，对未知值返回 unknown；这些结果适合诊断和稳定标识，但不应该被误解成所有场景都能直接反序列化的 JSON 值。

修复：按序列化目标封装出口

更稳妥的做法是先定义自己的序列化对象，再在边界处选择 API。下面的示例把常量的 Kind、精确文本和可计算值分开保存；代码只展示封装策略，不依赖本地运行结果。

package main

import (
	"encoding/json"
	"fmt"
	"go/constant"
)

type ConstantRecord struct {
	// Kind 用于让协议接收方知道文本对应的常量类别。
	Kind string `json:"kind"`
	// Exact 保留可比较的精确文本，适合缓存键或审计信息。
	Exact string `json:"exact"`
	// Value 只放已明确转换过的机器值，避免把 any 直接暴露出去。
	Value any `json:"value,omitempty"`
}

func encodeConstant(v constant.Value) ([]byte, error) {
	record := ConstantRecord{
		Kind:  v.Kind().String(),
		Exact: v.ExactString(),
	}

	// 只有可安全表达为业务字段的 Kind 才填 Value。
	switch v.Kind() {
	case constant.Bool, constant.String:
		record.Value = constant.Val(v)
	case constant.Int, constant.Float:
		// 大整数和高精度小数保留为文本，避免协议边界丢精度。
		record.Value = v.ExactString()
	case constant.Unknown, constant.Complex:
		// 这两类交给 Exact 字段，禁止默认分支悄悄变成 null。
		record.Value = nil
	default:
		return nil, fmt.Errorf("不支持的常量 Kind: %s", v.Kind())
	}
	return json.Marshal(record)
}

如果下游确实需要数值计算，可以在 Val 之后做更细的类型断言。例如大整数断言为 *big.Int，分数断言为 *big.Rat，并在转换为固定宽度整数或浮点数时保留“是否精确”的判断。不要因为某次返回的是 int64，就把所有整数都写死成这个类型。

防复发：给 Unknown、Complex 和源码原文留出口

最后可以把下面三条规则写进常量处理层：

1. 缓存键和去重标识使用 ExactString，不要使用可能近似或缩短的 String。
2. 业务计算使用 Val，随后按 Kind 和实际动态类型断言；高精度值不要未经判断转成 float64。
3. 对外协议同时保存 Kind 与 Exact；Unknown、Complex 和原始源码拼写需要单独的字段或明确的错误策略。

这样处理后，Val 和 ExactString 就不再是“哪个更好”的比较，而是两个职责清晰的出口：一个服务程序内部的机器值，一个服务稳定、精确的文本表达。

常见问题

ExactString 能恢复用户写入的原始数字格式吗？

不能把它当作源码 token 原文恢复器。它保证当前常量值的精确表达，原始十进制拼写、下划线和部分字面量写法应在解析阶段另行保存。

为什么 Val 返回 nil？

官方实现对 Unknown、Complex 以及其它未列出的 Kind 返回 nil。调用方应先看 Kind，再决定是使用 ExactString、拆分复数，还是返回协议错误。

字符串为什么不能直接用 ExactString 当业务值？

ExactString 会保留 Go 风格的引号。需要不带引号的业务内容时使用 constant.StringVal；需要区分类型的稳定文本时才保留 ExactString。

参考文档：https://pkg.go.dev/go/constant、https://go.dev/src/go/constant/value.go、https://go.dev/ref/spec#Constants