Go strconv.ParseUint 前导加号为什么解析失败

strconv.ParseUint 不接受前导符号，包括加号。+25 数学上是正数，并不表示它符合这个函数的输入语法；负号同样不允许。应先决定字段是否允许加号，再做明确的输入处理，不能把所有失败都归结为位宽不足。

官方文档入口：https://pkg.go.dev/strconv。下面做一个只解析批量大小的小命令行工具，固定十进制，并将语言层的 uint16 范围与业务层的 1 到 1000 分开。

1. 先明确这个参数允许什么

本例接收一串十进制数字，不自动去空格、不接收加号负号、不允许十六进制前缀或下划线。前导零允许，因此 025 在固定十进制下表示 25。这个约定是示例的业务选择，不是所有接口必须采取的格式。

ParseUint 与 ParseInt 不能按名字相近就互换：ParseInt 接受符号，但结果受有符号整数范围约束。为了接收加号而先 ParseInt 再强制转 uint64，既可能漏掉负数检查，也会缩小可接受的正数上限。

2. 保存一个带明确错误信息的小程序

准备 Go 环境，将以下代码保存为 main.go。parseBatchSize 可以被命令行、配置读取器或请求处理器复用，外层按不同入口返回合适的提示。代码是原创教学示例，本文未运行它，也不将预期输出表述为实测结果。

package main

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

func parseBatchSize(s string) (uint16, error) {
    if s == "" {
        return 0, fmt.Errorf("batch-size 不能为空")
    }
    if s[0] == '+' || s[0] == '-' { // 无符号字段不接受任何符号前缀
        return 0, fmt.Errorf("batch-size 不允许前导加号或负号")
    }
    n, err := strconv.ParseUint(s, 10, 16) // 固定十进制和 16 位范围
    if err != nil {
        switch {
        case errors.Is(err, strconv.ErrSyntax):
            return 0, fmt.Errorf("batch-size 只能包含十进制数字: %w", err)
        case errors.Is(err, strconv.ErrRange):
            return 0, fmt.Errorf("batch-size 超出 uint16 范围: %w", err)
        default:
            return 0, fmt.Errorf("batch-size 解析失败: %w", err)
        }
    }
    if n == 0 || n > 1000 { // 业务范围比 uint16 更窄，不能由位宽代替
        return 0, fmt.Errorf("batch-size 必须位于 1 到 1000")
    }
    return uint16(n), nil // 仅在解析和业务范围都通过后缩窄类型
}

func run(args []string) error {
    if len(args) != 1 {
        return fmt.Errorf("用法: batchsize ")
    }
    n, err := parseBatchSize(args[0])
    if err != nil {
        return err // 不使用解析失败时同时返回的数值
    }
    fmt.Printf("batch_size=%d\n", n)
    return nil
}

func main() {
    if err := run(os.Args[1:]); err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1) // 失败给调用脚本非零退出码
    }
}

第一处检查特意先处理空串，之后才能安全访问 s[0]。符号错误给读者明确提示；其余非法字符由 ParseUint 拒绝。不要使用 TrimLeft 把一串加减号都删掉，也不要为了让输入通过就无条件删除所有空白。

errors.Is 识别被 NumError 包装的 ErrSyntax 或 ErrRange；%w 保留原因供上层继续判断。符号错误在本例是业务入口主动拒绝，不伪装成函数原生 NumError。对外接口可只返回受控提示，不必回显包含原始输入的完整底层错误。

3. 本地运行时，核对成功与失败分支

go run main.go 25 # 预期成功，输出 batch_size=25
go run main.go +25 # 预期前导符号被拒绝
go run main.go 65536 # 预期超过 uint16 范围
go run main.go 1001 # 预期解析成功，但业务范围不通过
go run main.go ' 25' # 预期空格导致语法错误

成功时应输出解析后的值；失败应写入标准错误并返回非零状态。使用 go run 时外层工具可能另外显示退出状态提示，所以不要把它与编译后的程序输出完全等同。若需要独立二进制，读者可自行构建后使用相同参数核对。

4. base 和 bitSize 不会帮你消除加号

base 控制数字解释方式；设为 0 时会依据前缀推断进制，并允许符合规则的下划线。这样 025 可能按八进制解释，而不是固定十进制的 25。面向普通业务数量的输入，明确 base=10 能避免这种隐含变化。把 base 从 10 改成 0，并不会放开 ParseUint 对符号前缀的限制。

bitSize 限制结果必须装得下的无符号整数位宽，返回值的 Go 类型仍是 uint64。设置 16 不等于返回 uint16；也不要先用 64 位解析成功，再直接缩窄为 uint16 以为仍有范围保护。示例在解析阶段限制位宽，再在成功分支缩窄。

解析失败时不要继续使用同时返回的数字，尤其是超范围错误。它不是可靠业务值。也不要用 bitSize=0 表达“无限大”；如果需要明确且稳定的位宽，应写清具体位数，大于 uint64 的整数则应另选合适的数据模型。

5. 如果旧协议必须接受一个加号

兼容层可以在明确允许的前提下，只移除开头恰好一个 ASCII 加号，再把剩余字符串交给固定进制的 ParseUint。移除后还需拒绝空串以及残留符号，因此单独的 +、++25、+-25 不应变成合法输入。是否允许空白、前导零和数字分隔符，也要分别约定。

这种处理应局限在旧协议边界，不要偷偷改变公共解析函数的契约。尤其不要把负号一起删掉；把 -25 变为 25 改变了数值含义。如果业务真的需要正负数，使用有符号模型并检查范围通常比“清洗”符号更清楚。

为什么 +0 也不行？符号是否合法取决于语法，而不是数值大小；ParseUint 不因为结果为零就接受前导加号。

中文全角加号也能删掉吗？本例不做字符归一化。若协议允许归一化，应先定义字符集合与错误反馈，不能随意把不同字符当成相同输入。

能只检查返回数字是否为零吗？不能。零可能是合法解析结果，也可能伴随错误；必须先处理 err，再检查业务范围。

接入配置或请求参数时，保留这一分工即可：入口决定符号策略，ParseUint 决定数字语法及位宽，业务层决定允许区间。这样读者看到加号失败时，才能知道该改输入合同，而不是盲目增大 bitSize。

参考：strconv.ParseUint、ParseInt 的进制与位宽说明、NumError。