Go strconv.ParseInt 为什么在边界输入上得到空结果

strconv.ParseInt 返回的是 int64 和 error，不会返回“空字符串”或 nil 数值。边界输入让页面显示为空，通常是业务代码在错误分支清空了展示值，或者把合法的 0 当成了未填写。要定位这个问题，应同时保留原始文本、解析状态和成功后的数值，而不是只保留一个整数。

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

用户任务：区分未填写、格式错误和合法零值

假设页面有一个十进制整数字段，允许 int32 范围，包含负数和零。用户删除内容时，输入框应允许暂时为空；用户输入单独的负号时，还没有形成完整整数；输入 0 时则已经是合法数字。这三个画面可能都让旧代码得到数值字段的零值，但业务意义不同。

ParseInt 的错误类型可用于区分语法与范围问题；界面是否清空则由调用方决定。如果模板只在值不为零时输出，就会把成功解析的 0 隐藏。若只在 err 为 nil 时写入另一个字符串变量，错误分支留下默认空字符串，也会表现为“空结果”。先查看错误处理和展示条件，不要把空态归因于解析函数返回了空对象。

交互拆解：固定进制和数值范围

示例显式使用 base=10、bitSize=32。这样字符串 010 按十进制理解，整数范围固定为 −2147483648 到 2147483647。bitSize 限定允许的数值范围，返回类型仍是 int64。成功后若业务需要，可以再转换为 int32；失败分支不能把返回数值当作有效输入。

base=0 会根据前缀推断进制，且允许符合 Go 整数字面量规则的下划线。这适合特定配置语法，不一定符合普通十进制表单的预期。bitSize=0 对应平台的 int 位宽，也不适合作为跨平台固定范围的替代写法。输入协议应该由产品需求决定，不能靠更换参数去掩盖错误。

组件实现：保存原文与明确状态

下面的 Go 组件模型不依赖具体网页框架，可以放到后端表单处理层。它保留 Raw 供输入框重新展示，使用 State 表达当前状态，仅在 valid 时读取 Value。Message 用于当前字段的文字反馈。

package field

import (
    "errors"
    "strconv"
)

type IntegerField struct {
    Raw string
    State string
    Value int64
    Message string
}

// ParseField 接受十进制 int32 范围；不自动裁剪用户输入。
func ParseField(raw string) IntegerField {
    r := IntegerField{Raw: raw}
    if raw == "" {
        r.State = "empty" // 空输入是表单状态，不等于数值零。
        return r
    }
    v, err := strconv.ParseInt(raw, 10, 32)
    switch {
    case err == nil:
        r.State, r.Value = "valid", v
    case errors.Is(err, strconv.ErrRange):
        r.State, r.Message = "range", "请输入 -2147483648 到 2147483647 之间的整数"
    case errors.Is(err, strconv.ErrSyntax):
        r.State, r.Message = "syntax", "请输入十进制整数，不要包含空格或小数点"
    default:
        r.State, r.Message = "error", "暂时无法解析该整数"
    }
    // 失败时不把 ParseInt 的返回数值当成有效业务值。
    return r
}

代码不裁剪空格，是为了把协议表达清楚。若产品允许复制粘贴后的首尾空白，可在单独的规范化层使用 strings.TrimSpace，但仍建议保留用户原文以便解释变化。不要在解析失败时不断尝试不同进制直到某一次成功，这会改变用户原本输入的含义。

这里的空输入分支在调用 ParseInt 前返回，是业务组件主动定义的状态。直接调用 ParseInt 解析空字符串会得到语法错误。IntegerField 在失败分支的 Value 也为零，但这个零不代表解析成功；调用方必须检查 State。

边界状态：按契约解释输入

表格依据接口契约和上述组件设计说明行为，并非本机执行记录。ParseInt 在超出范围时会同时返回范围错误和该符号方向的极限数值，因此“返回值不为零”也不能证明成功。不要将这个极限值直接入库，更不要把溢出当作自动限幅。

可访问性与性能：让错误可见且可修正

界面应给字段提供可读标签，把范围说明放在输入附近，并将错误文字与字段关联。不要只用红色边框表达失败。重新展示 Raw 时，使用模板的正常转义能力，不能将原始输入直接拼接成 HTML。提交失败后保留内容，能减少用户重复输入。

逐键输入与最终提交可以使用相同解析函数，但呈现节奏不同：输入过程允许短暂出现负号或空字符串；离开字段或提交时再显示完整错误。必填约束也应由表单层明确执行，empty 不自动代表可以提交。前端提示负责体验，后端仍按同一进制、范围和必填约束作出最终接收决定。

单字段解析不需要为每次输入建立网络往返。对于长文本输入，应由字段协议限制长度，并在允许范围内解析；不要为隐藏错误而不断重新提交。本文不提供性能测量结果，性能判断需要结合实际数据规模。

常见问题

为什么不直接用 Atoi？

Atoi 面向十进制和 int 类型。若需求明确要求固定 32 位范围，ParseInt 的显式 bitSize 更容易保持协议一致。

输入 0 是否可以用来表示没有填写？

只有业务明确禁止零且单独设计了缺省协议时才可能这样约定。普通整数字段应保留 empty 与 valid 两种状态，避免让零值同时承担两种含义。

出现 range 时能否继续使用返回值？

它可以用于了解接口行为，但不能作为本例中的有效表单值。若产品确实要限幅，应另行定义并向用户说明限幅规则。

处理“空结果”的关键，是让展示逻辑依据状态，成功逻辑依据 err，而不是依据数值是否为零。

Go 官方 ParseInt 文档