Go constant.MakeFromLiteral 怎样按 token 种类解析常量

我在给 Go 源码分析器补“常量值”这一层时，最容易写错的不是 constant.MakeFromLiteral 的调用，而是把字面量文本和错误的 token.Token 配在一起。这个函数并不会替你猜类型："42" 传成 token.INT 才会按整数解析，"42" 传成 token.FLOAT 就是另一条语义路径。

这次我把它整理成一条稳定的工作流：扫描阶段保留原始文本和 token，转换阶段只接收五种合法字面量 token，失败时检查 Value.Kind() 是否为 constant.Unknown。这样既能覆盖整数、浮点数、虚数、字符和字符串，也不会把非法输入悄悄当成零值。

• 输入：原始字面量字符串、对应的 token.Token、固定为 0 的精度参数。
• 分支：token.INT、token.FLOAT、token.IMAG、token.CHAR、token.STRING。
• 失败判断：字面量语法非法时返回 Unknown，不要用 String() 是否为空来猜。

我第一次踩坑：literal 和 token 不是一回事

lit 是源码里看到的那段文字，tok 是词法分析器对这段文字给出的类别。它们必须来自同一个扫描结果，不能先拿字符串再凭经验补 token。官方 go/token 将 INT、FLOAT、IMAG、CHAR、STRING 定义为基础字面量 token；constant.MakeFromLiteral 也只接受这五类。

我现在会把这两个字段放在同一个结构里传递，避免后面的阶段重新推断：

package main

import (
    "fmt"
    "go/constant"
    "go/token"
)

type literalInput struct {
    text string       // 保留源码中的原始字面量，包括引号或虚数后缀
    kind token.Token  // 必须与 text 来自同一次词法扫描
}

func valueOf(in literalInput) constant.Value {
    // zero 必须传 0；当前 API 不用它指定额外精度
    return constant.MakeFromLiteral(in.text, in.kind, 0)
}

func main() {
    in := literalInput{text: "0x2a", kind: token.INT}
    value := valueOf(in)
    fmt.Println(value.Kind(), value.ExactString())
}

这里没有把 0x2a 先转成 Go 的 int。保留原文很重要，因为 MakeFromLiteral 负责按 Go 字面量语法解释前缀、后缀和引号；提前转成机器整数反而会丢掉源码信息。

按五类 token 接入转换阶段

实际接入时，我不再写一串“看起来像数字”的判断，而是让扫描结果直接驱动转换。token.INT 覆盖十进制、八进制、十六进制等整数写法；token.FLOAT 交给浮点字面量解析；token.IMAG 保留虚数后缀；CHAR 和 STRING 则保持 Go 的引号与转义规则。

func parseLiteral(text string, kind token.Token) (constant.Value, error) {
    // 只允许 MakeFromLiteral 文档规定的五类字面量
    switch kind {
    case token.INT, token.FLOAT, token.IMAG, token.CHAR, token.STRING:
        value := constant.MakeFromLiteral(text, kind, 0)
        // Unknown 表示语法或数值无法表示，不能当成合法零值
        if value.Kind() == constant.Unknown {
            return value, fmt.Errorf("invalid %s literal %q", kind, text)
        }
        return value, nil
    default:
        return constant.MakeUnknown(), fmt.Errorf("token %s is not a literal", kind)
    }
}

这个分支有一个实际收益：标识符、关键字和运算符不会误进常量转换。对于字符串和字符，我也不会调用 Int64Val 之类的数值提取函数，而是根据 Kind 选择 StringVal 或精确字符串表示。

把扫描结果原样交给 MakeFromLiteral

如果字面量来自源文件，推荐让 go/scanner 产出 token 和原始文本。示例只展示接线方式，重点是 token.Position、token 类别和文本在同一处被记录，后续阶段不需要重新切片猜测。

func collectLiterals(src string) []literalInput {
    // File 记录源码范围，scanner 负责同时给出 token 和原始文本
    file := token.NewFileSet().AddFile("input.go", -1, len(src))
    var s scanner.Scanner
    s.Init(&file, []byte(src), nil, scanner.ScanComments)

    var result []literalInput
    for {
        _, kind, text := s.Scan()
        // EOF 结束扫描；其余 token 只收集 MakeFromLiteral 支持的类别
        if kind == token.EOF {
            break
        }
        if kind.IsLiteral() && kind != token.IDENT {
            result = append(result, literalInput{text: text, kind: kind})
        }
    }
    return result
}

工程代码中要补上 go/scanner 导入，并按需要处理注释；这里刻意没有把扫描输出说成“已运行结果”，它只是把数据边界放在正确的位置。若上游已经有 AST 或类型检查结果，也应优先复用已有 token 和原文。

性能上的取舍：一次解析，后面复用 Value

我最初在多个规则里重复调用 MakeFromLiteral，在大文件分析时会让同一个字面量反复走解析分支。后来把 literalInput 转成 constant.Value 放在节点级缓存里：规则需要判断大小、类型或拼接时复用 Value，只有源码文本变化才重新建立。

这里的“性能优化”不是把精确常量换成 float64。go/constant 表示的是无类型 Go 常量，过早转成机器类型可能丢失精度。更稳妥的顺序是先保留 constant.Value，在真正需要生成运行时参数时，再调用对应的 Int64Val、Float64Val 或 StringVal 并处理返回的可表示性。

常见误区和我的收尾清单

第一，不要把第三个参数写成自定义精度；当前签名要求它为零。第二，不要只看 Value.String() 判断成功，应该检查 Kind()，字符串还要区分展示形式和实际内容。第三，不要在非法 token 上硬调函数，先做白名单分支。第四，源码分析器要保留位置和原文，这样出现 Unknown 时还能把错误指回具体字面量。

对我来说，最可靠的收尾方式是：扫描时记录 (text, token)，转换时只进五类白名单，结果层检查 Unknown，业务层再决定是否转成机器类型。这样 constant.MakeFromLiteral 就是清晰的转换边界，而不是一个需要猜参数的黑盒。

常见问题

为什么不能只传字符串让 MakeFromLiteral 自动判断？

因为函数签名要求显式的 token.Token。同一段文本在不同 token 下代表不同语义，正确做法是复用词法扫描阶段产出的类别。

第三个参数为什么固定传 0？

当前 API 的参数名是 zero，文档要求最终参数为零。不要把它当成浮点精度开关。

解析失败后为什么不直接返回 nil？

constant.Value 使用 Unknown 表示错误或未知值。调用方应先检查 Kind()，再决定记录诊断、跳过规则或返回错误。