Go strconv.ParseInt 为什么 base=0 时下划线才可用

我在把一组“看起来像整数”的配置交给 strconv.ParseInt 时，最容易踩到的坑不是数值本身，而是把 base=0 和显式进制混成了一种调用。前者按 Go 整数字面量规则识别前缀，并且允许下划线；后者只按指定进制读入文本，不应默认接受这种字面量分隔符。

因此，Go strconv.ParseInt 为什么 base=0 时下划线才可用 的答案是：这是 API 明确区分的输入协议，不是下划线在某次调用中“偶然生效”。

官方地址：https://pkg.go.dev/strconv#ParseInt

先把输入协议说清楚

ParseInt(s, base, bitSize) 返回一个 int64 和一个 error。其中 base 为 0 时，函数会从字符串前缀推断进制：0b 或 0B 表示二进制，0o 或 0O 表示八进制，0x 或 0X 表示十六进制，没有这些前缀时按十进制处理。这个分支还允许符合 Go 整数字面量规则的下划线。

一旦把 base 写成 2 到 36 之间的具体值，含义就变成“按这一个进制读取输入”。如果业务协议是普通十进制表单，显式写 10 更容易限制输入；如果业务协议就是 Go 风格的整数文本，才适合让 base=0 接管前缀和分隔符。

用最小示例比较下划线和前缀

下面的例子故意把相同文本交给不同的 base。重点不是展示一个“万能解析器”，而是把配置边界固定下来：每次调用都记录原文、参数和错误。

package main

import (
    "fmt"
    "strconv"
)

// showParse 打印原文、进制和错误，避免只看返回数值做判断。
func showParse(text string, base int) {
    value, err := strconv.ParseInt(text, base, 64)
    if err != nil {
        // 错误分支中的 value 不能当成业务成功值。
        fmt.Printf("text=%q base=%d value=%d err=%v\n", text, base, value, err)
        return
    }
    // 成功时再把 value 交给后续业务逻辑。
    fmt.Printf("text=%q base=%d value=%d\n", text, base, value)
}

func main() {
    showParse("1_000", 0)   // base=0：按 Go 整数字面量规则识别下划线。
    showParse("1_000", 10)  // base=10：不要把普通十进制协议和字面量协议混用。
    showParse("0xFF", 0)    // base=0：从 0x 前缀推断十六进制。
    showParse("0b1010", 0)  // base=0：从 0b 前缀推断二进制。
}

这个例子中的第一条输入可以沿着字面量规则解析；第二条则落入显式十进制协议，通常应被视为语法不符合。第三、四条展示了为什么 base=0 不只是“默认十进制”，它还会解释前缀。

如果输入来自用户表单，通常不要为了兼容某一条失败文本就自动在 0、10、16 之间重试。重试会让同一段字符在不同环境中代表不同数值，反而扩大了输入风险。

把 ErrSyntax 和 ErrRange 分开

我后来把排查重点从“返回了什么数”改成“错误属于哪一类”。ParseInt 的错误通常包在 *strconv.NumError 中：文本为空、包含不允许的字符或格式不对时，重点看 strconv.ErrSyntax；数值超出 bitSize 能表示的范围时，重点看 strconv.ErrRange。

package main

import (
    "errors"
    "fmt"
    "strconv"
)

// classify 固定使用 base=0，演示 Go 风格整数配置的错误分类。
func classify(text string) {
    value, err := strconv.ParseInt(text, 0, 32)
    switch {
    case err == nil:
        // 只有 err=nil 时，value 才能作为成功的 int32 结果使用。
        fmt.Printf("%q -> valid: %d\n", text, value)
    case errors.Is(err, strconv.ErrSyntax):
        // 语法错误应回到输入格式提示，不要改成范围提示。
        fmt.Printf("%q -> syntax error: %v\n", text, err)
    case errors.Is(err, strconv.ErrRange):
        // 范围错误表示格式可能正确，但 bitSize 无法容纳该值。
        fmt.Printf("%q -> range error: %v\n", text, err)
    default:
        // 保留未知错误，避免把异常静默当成合法零值。
        fmt.Printf("%q -> other error: %v\n", text, err)
    }
}

func main() {
    classify("1_000")
    classify("0x7fff_ffff")
    classify("0x1_0000_0000") // 超出 32 位有符号整数范围。
    classify("0xGG")           // 非法数字字符，属于语法问题。
}

bitSize=32 只改变可表示的数值范围，返回类型仍然是 int64。当输入超过范围时，文档描述的返回数值可能已经是对应方向的极限值，但它仍然伴随错误；不能因为看到了一个非零值，就把它当成解析成功。

在配置边界固定唯一规则

把解析器放在配置加载或请求入口时，最重要的是先写下“允许什么文本”。我会按下面三个问题做决定：

1. 是否允许前缀？ 允许 0x、0b 等 Go 风格前缀时，使用 base=0；只接受十进制字符串时，使用 base=10。
2. 是否允许分隔下划线？ 只有协议明确采用 Go 整数字面量语法时才放开，不要为了“看起来更易读”临时加入。
3. 范围是否固定？ 跨机器、跨服务传输的字段优先使用明确的 bitSize，不要把平台相关的 int 宽度隐含进协议。

如果这是用户可编辑的字段，错误提示还应该保留原文，让用户知道是格式错误还是超范围。把失败结果统一改成空字符串，会抹掉最有用的线索；把合法的 0 也当成“未填写”，则会制造另一种空态。

对于安全边界，真正需要保护的是“文本到数值”的语义一致性：同一个配置在开发环境、生产环境和不同调用方之间应该得到同样的解释。显式记录 base、bitSize 和错误类别，比在日志里只输出最终整数更容易追溯。

参数速查与常见误区

为什么 base=0 才允许下划线？

因为文档把它定义为 Go 整数字面量解析路径的一部分，下划线规则与前缀推断绑定在同一个语法契约里；显式进制则是更窄的按进制读取。

把 base 改成 10 能不能兼容 1_000？

不能把它当作同一协议的自动兼容方案。若确实要接受分隔符，应在输入规范化层明确删除允许位置的下划线，再用固定进制解析，并记录这一转换规则。

ParseInt 返回 ErrRange 时为什么还带数值？

返回值是函数在该位宽下得到的边界结果，错误才是“这次输入不能作为合法结果”的决定性信号。业务层应先判断错误，再决定是否使用数值。

记住一句话就够了：base=0 选择的是 Go 字面量语法，显式 base 选择的是严格进制协议；下划线是否有效，取决于你选择了哪一条输入契约。