字符串转整数的边界与工程实践：从atoi到状态机设计

如果你做过在线评测系统上的题，多半见过那道经典的“字符串转换整数”。第一次在 OJ 上碰到的时候，我看了题目还挺不屑，心想这不就是 atoi 吗？结果一提交，案例没过，然后开始补丁套补丁，越补越乱。后来在工作里写后台接口、清洗数据、处理报表导入，才发现这道题根本不是在考调用一个函数，而是在考你有没有把“字符串变整数”这条链路里的脏数据、溢出、语言差异、框架坑全部想清楚。

这篇内容我会从三个层面展开：先讲清楚手写转换时到底要处理哪些边界；再带你看不同语言和标准库的行为差异；最后结合数据库、ORM 这些真实项目里最容易踩的场景，聊聊我自己的取舍。适合准备算法面试的人，也适合日常写业务代码却被各种类型转换搞得头大的朋友。

1. 字符串转整数：这道题为什么值得反复做

1.1 题面虽短，背后是一整套输入处理规范

先看最经典的要求：输入一个字符串，按规则把它转成 32 位有符号整数。规则一般是这样的：忽略前导空格，处理正负号，读取连续数字，遇到非数字就停止，超出整数范围就截断到 INT_MAX 或 INT_MIN，如果第一个有效字符不是数字或正负号，直接返回 0。

这条规则看起来是人为定的，但细看会发现它几乎复刻了真实解析器的行为。你做接口解析时，前端传一个“ -123abc”，到底该报错还是该解析成 -123？很多命令行工具和配置文件解析器采取的正是“尽量读有效前缀，读到不合法就停”的策略，因为这对用户更友好。

还有更重要的边界：空字符串、“+1”、“-0”、“2147483648”、“ +00 42”、“3.14”、全角数字、超大负数。任何一个没考虑进去，线上就可能出现“用户填了超大数字，程序崩溃”“导入了带空格的数据，匹配不上”之类的问题。

1.2 转换不只是“减去 '0' 再乘 10”

很多新手第一次写转换函数，逻辑就是：

c复制int result = 0;
for (int i = 0; i < strlen(s); i++) {
    result = result * 10 + (s[i] - '0');
}

这串代码单独处理“123”没问题，但哪怕你给它一个 " 12"，它都会算出 3360。问题不在于不了解数字字符的 ASCII 差值，而是没意识到“字符串到整数”这个动作的真实流程是：先判断当前状态，再决定是否把字符纳入计算结果。

这类题真正的考点，是你能不能提前把“输入是什么状态、该跳过还是继续、什么时候该停”全部考虑清楚。这也是为什么很多人一上来就 if 堆叠，写完自己都不知道分支会不会漏。

1.3 从刷题到工作，同一个函数的两种命运

同样一个转换逻辑，在竞赛里可能只是返回正确值；在生产环境里，它可能出现在订单号导入、Excel 上传、网关参数校验、数据库字段迁移中。一旦出现脏数据，你不会得到一个友好的错误信息，而是出现“某条记录没入库”“金额算错”这类更难查的问题。

更重要的是，真实场景不会只有字符串转 int 一种。你还会遇到字符串转 long、字符串转 short、十六进制字符串转整数、带千分位字符串转整数、科学计数法字符串转整数。所以这篇内容虽然由一道题出发，但我更希望你能把“转换”当成一个完整的工程问题来看。

2. 手写转换函数：状态机设计比硬编码判断更稳

2.1 先定义输入阶段，而不是上来就循环处理字符

如果只用 if 连环判断，状态一多代码就会变成一团浆糊。我建议先把字符串处理过程划分成几个状态：

• 起始状态：还没看到任何有效内容，可能遇到空格、正负号、数字、非法字符。
• 符号状态：已经吃掉了正负号，接下来只接受数字，如果遇到非数字就需要结束。
• 数字状态：正在累计数值，遇到非数字就必须结束。
• 结束状态：返回当前结果。

这种拆法最大的好处是，每个状态里你能清楚地知道下一步合法的字符是什么。你不用把“是否已经出现过符号”“是否已经出现过数字”这些信息散落在各个变量里，变量少了，逻辑分支也就清晰了。

下面我用类 C 的写法给一个状态机骨架，实际开发中换成 Java、Go 都是同一个套路：

c复制typedef enum {
    STATE_START,
    STATE_SIGN,
    STATE_NUMBER,
    STATE_END
} State;

int stringToInt(const cha