Go strconv.ParseInt处理边界数值和位宽的实现方式

处理请求参数时，我更愿意把 strconv.ParseInt 当成一道边界闸门，而不是简单的“字符串转数字”函数。关键在于第三个参数 bitSize：传入 32，就按有符号 32 位整数检查范围；传入 64，才允许完整的 int64 范围。解析返回 int64，但目标位宽在解析阶段就已经决定，非法字符应识别为 ErrSyntax，越界应识别为 ErrRange。

先把 base 和 bitSize 对准业务字段

这次我处理的场景是把配置文件中的端口、重试次数和租户编号交给不同的业务字段。它们看起来都是整数，边界却不一样。端口可能需要无符号范围，重试次数通常只接受非负的小整数，而数据库主键可能需要完整的 64 位范围。

ParseInt 的签名是 ParseInt(s string, base int, bitSize int) (i int64, err error)。十进制传 10，十六进制传 16；只有在确实要让前缀决定进制时才使用 base=0。bitSize=0 按 int 的宽度判断，跨平台配置不建议依赖这个隐含选择。

解析成功前先拦住非法字符和溢出

不要只判断 err != nil 后返回一句“参数错误”。调用方往往需要知道是格式不对，还是数值超出了协议允许范围。*strconv.NumError 会保留函数名、输入字符串和底层错误，可以用 errors.Is 做稳定分类。

package main

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

func parseRetryCount(raw string) (int32, error) {
    // bitSize=32 让 ParseInt 在转换前检查 int32 的上下界。
    value, err := strconv.ParseInt(raw, 10, 32)
    if err != nil {
        // 语法错误和范围错误要分开，便于返回不同的业务提示。
        if errors.Is(err, strconv.ErrSyntax) {
            return 0, fmt.Errorf("重试次数不是合法整数 %q: %w", raw, err)
        }
        if errors.Is(err, strconv.ErrRange) {
            return 0, fmt.Errorf("重试次数超出 int32 范围 %q: %w", raw, err)
        }
        return 0, fmt.Errorf("解析重试次数失败: %w", err)
    }
    // 解析已经按 32 位完成范围判断，此处转换不会静默截断。
    return int32(value), nil
}

输入 "12x" 会落到 ErrSyntax；输入 "2147483648" 会落到 ErrRange。空字符串、带小数点的文本和超出上界的数字都不应靠默认值“兜底”，否则配置错误会延迟到更远的业务环节才暴露。

位宽校验与转换顺序决定结果是否可靠

最容易踩的坑是先按 64 位读取，再把结果强制转换为 int32，然后才比较大小。这样写把检查放晚了，越界值可能已经变成一个看似正常的负数或小数值。正确顺序是：确定目标位宽、按该位宽解析、检查错误、最后做显式类型转换。

如果业务还规定“重试次数不能超过 10”，那是语义校验，不是 bitSize 能替代的内容。先做语法和机器位宽检查，再做业务上限检查，错误定位会更清楚。

用边界用例把解析契约固定下来

测试不必铺满所有数字，但至少要覆盖零值、符号、上下界、边界外数值和非法字符。下面的表可以直接转成表驱动测试：-2147483648 与 2147483647 在 32 位有符号范围内，超出一位就应该失败。

• 合法："0"、"-1"、"2147483647"。
• 越界："2147483648"、"-2147483649"，应识别为 ErrRange。
• 非法："12x"、""、不符合约定进制的字符串，应识别为 ErrSyntax。

最后再确认输入协议：如果前端允许空白、前缀或加号，要在协议层明确是否先做裁剪或是否使用 base=0。解析函数不会替你猜业务意图；边界写在调用参数和测试里，后续维护才不会靠经验。

相关问题

ParseInt 的 bitSize 传 0 有什么影响？

它按 int 的宽度检查，结果仍是 int64。需要跨平台保持相同协议边界时，建议明确传 32 或 64。

解析无符号编号可以继续用 ParseInt 吗？

不建议。非负编号应使用 strconv.ParseUint，这样负号和上界都按无符号类型的规则处理。

为什么不直接使用 Atoi？

Atoi 等价于十进制、按 int 宽度解析。字段位宽或进制需要明确控制时，ParseInt 更合适。