Go text/scanner 解析数字时如何保留原始字面量

我在做配置表达式和代码片段分析时，最容易踩到的坑不是“数字能不能转成 int”，而是转完以后已经看不出用户原来写的是 1_000、0x2a 还是 1e3。如果使用 Go 的 text/scanner，正确做法是：每次调用 Scan() 后，立刻读取 TokenText() 保存原始字面量；需要计算时，再把这份原文交给 strconv。

数字的词法原文和数值含义是两份数据。TokenText() 保留前者，strconv 负责后者，二者不要互相替代。

下面的示例只展示词法扫描的处理边界，图中内容也是结构示意，不代表本机运行截图。

先把原始字面量和数值结果分开

text/scanner.Scanner 的 Scan() 返回一个 rune token；对数字启用 Go token 模式后，整数、浮点数和虚数会分别落在 ScanInts、ScanFloats 等能力覆盖的范围内。扫描完成后，TokenText() 返回最近一个 token 在输入中的原始文本。

因此建议把记录设计成两层：Raw 保存用户输入，Value 保存业务真正要计算的值。前者用于错误提示、格式化回写和审计，后者用于比较、排序或后续计算。

Scan 之后马上读取 TokenText

下面这个最小写法把每个数字先记录下来，再决定是否转换。关键点是 TokenText() 读取的是“最近一次扫描结果”，下一次 Scan() 会更新它，所以不要把读取动作拖到循环外。

package main

import (
    "fmt"
    "go/token"
    "strconv"
    "strings"
    "text/scanner"
)

type NumberLexeme struct {
    // Raw 保留输入中的进制、下划线和指数写法。
    Raw string
    // Kind 用于决定后续采用整数、浮点数还是虚数转换。
    Kind token.Token
}

func scanNumbers(src string) ([]NumberLexeme, error) {
    var s scanner.Scanner
    // GoTokens 会打开 Go 数字和标识符等常见 token 扫描能力。
    s.Init(strings.NewReader(src))
    s.Mode = scanner.GoTokens

    var numbers []NumberLexeme
    for {
        tok := s.Scan()
        if tok == scanner.EOF {
            break
        }
        if tok == scanner.Int || tok == scanner.Float || tok == scanner.Imag {
            // 必须在下一次 Scan 前复制原文，否则 TokenText 会被覆盖。
            numbers = append(numbers, NumberLexeme{
                Raw:  s.TokenText(),
                Kind: token.Token(tok),
            })
        }
        if tok == scanner.Ident || tok == scanner.String {
            continue
        }
    }
    if s.ErrorCount != 0 {
        return numbers, fmt.Errorf("scan failed with %d error(s)", s.ErrorCount)
    }
    return numbers, nil
}

func main() {
    // 先保留原文；数值解析放在业务真正需要时进行。
    raw := "limit=1_000 ratio=3.14e+2 mask=0x2a"
    numbers, err := scanNumbers(raw)
    if err != nil {
        panic(err)
    }
    for _, item := range numbers {
        fmt.Println(item.Kind, item.Raw)
        if item.Kind == token.INT {
            // ParseInt 只负责语义转换，不会替代 Raw 的保存职责。
            value, parseErr := strconv.ParseInt(item.Raw, 0, 64)
            if parseErr != nil {
                panic(parseErr)
            }
            fmt.Println("value:", value)
        }
    }
}

这里的 Raw 仍然是输入文本；即使以后把 0x2a 解析成十进制的 42，回写或展示时也能恢复用户原来的表达方式。

不要用格式化后的值反推输入

常见错误是直接把 TokenText() 交给 strconv.ParseFloat，随后只保存浮点结果。这样做会丢掉进制、下划线、指数以及部分精度边界。更稳妥的字段关系如下：

如果输入是配置、查询条件或代码编辑器内容，建议把三者一起传递。错误消息可以指出原文，业务判断使用 Value，格式化输出则根据需求选择保留 Raw 或生成规范格式。

三个边界要提前处理

第一，TokenText() 只对应最近一次 token；如果先扫描下一个字符，再回头读取，得到的就不是数字原文。第二，scanner.EOF 是结束信号，不能把它当成空数字继续转换。第三，扫描器可能在报告错误后仍返回部分 token，不能只看 token 序列，还要检查 ErrorCount 或自定义错误回调。

另外，text/scanner 解决的是词法切分，不会替你决定业务范围。例如配置文件只允许十进制整数时，即使扫描器识别了十六进制形式，也应在保存 Raw 后自行拒绝或给出明确提示。

最后的判断标准

只要读者需要“原样展示、精确回写、定位输入错误或保留审计痕迹”，就应该把 TokenText() 的结果当作一等数据；只在需要算术含义时调用 strconv。可以用一句话检查实现是否可靠：任何数值转换失败时，错误信息还能指出用户输入的完整原文吗？如果答案是否定的，说明原始字面量保存得太晚了。

相关问题

为什么不能只保存 ParseInt 的结果？ 因为数值结果无法区分十进制、十六进制和带下划线的原始写法，回写和错误提示会失去上下文。

TokenText 可以在下一次 Scan 后再读吗？ 不建议。它描述的是最近一次扫描到的 token，应在同一轮中复制到自己的结构体或字符串字段。