用 strtoi 替代 atoi：C/C++ 字符串转整数与溢出检测实践

1. 从一次配置静默失效说起：为什么需要 strtoi

先说一个我自己踩过的坑。某项目的守护进程要读取一份运行时配置，其中有一项worker_pool_size，负责决定工作线程池的规模。代码里对配置项的处理是这么写的：pool_size = atoi(value);。上线后运维同学把配置改成了worker_pool_size = 8t，一个手抖多敲了个t，atoi安安静静返回了0，进程也就安安静静地按 0 个线程跑了起来，请求全堵在队列里。日志里没有任何报错，监控上看 CPU 和 QPS 都“正常”，最后定位花了将近两天。

从那之后我在项目里定了一条规矩：凡是外部输入转数字，一律不许用atoi。转换成功与否必须是一个显式可判定的返回值，而不是靠“值看起来像不像错误”去猜。这就是bool strtoi(const char *, int &)这个签名存在的全部理由——把“转换是否成功”和“转换出来的值”拆成两个独立的输出通道，调用方拿到false就知道要打日志、要拒绝启动、要回落到默认值，而不会把一个语义上完全合法的0误当成失败。

这个函数能干的事情其实很朴素：给一个 C 风格字符串，判断它能不能被完整、无溢出地解释成一个int，能就返回true并把结果通过引用写出去，不能就返回false。它解决的是“解析结果的可靠性”问题，而不是“解析速度”问题。适合谁看？写过配置文件解析、命令行参数解析、网络协议字段解析、以及任何需要从文本里抠数字的人，尤其是那些正在被atoi的静默失败折磨、又不想为了一个整数引入异常机制的 C/C++ 开发者。哪怕你平时写的是嵌入式裸机代码，没有<stdexcept>，这个签名也完全够用——它不依赖任何异常、不依赖 locale、不写全局errno，纯粹是入参进、bool 出。

2. 把接口契约钉死：什么叫“转换成功”

2.1 atoi 的返回值语义塌陷

atoi的签名是int atoi(const char *nptr)，返回值类型是int。这就是问题的根源：int这个类型要同时承载“解析出来的数值”和“解析失败”两种信息，而0既是合法的解析结果，又是失败时的默认返回值。信息在类型层面就已经冲突了，无论你怎么约定，都无法在调用点区分atoi("0")和atoi("abc")的返回结果。

更隐蔽的是溢出行为。C 标准对atoi在数值超出int范围时的行为是未定义的，注意是未定义，不是“返回 INT_MAX”或者“返回某个哨兵值”。在 x86 上你可能会看到它回绕成一个负数，在 ARM 上可能是另一个数，开了优化之后编译器甚至可以把整个判断优化掉。这类问题在单元测试里几乎测不出来，只有在上游传了一个异常大的数字时才炸。

至于“尾部垃圾字符”，atoi("123abc")返回123，atoi("abc123")返回0。一个宽松、一个失败，全部没有提示。如果你的配置里timeout = 30s这种带单位的写法被误传进来，atoi会给一个30，看起来“能用”，实际上单位被悄悄吞掉了——这种部分成功才是最危险的状态，因为它让错误延后暴露。

2.2 三种主流替代方案的代价

不甘心用atoi的人通常会转向strtol、std::stoi或者 C++17 的std::from_chars。这三条路都能正确报错，但代价各不相同，我做过一轮横向对比，结论整理在下面这张表里。

strtol的问题是它的错误报告方式依赖errno。errno是一个线程局部的全局变量，标准要求你在调用前手动置零：errno = 0; long v = strtol(s, &end, 10); if (errno == ERANGE) ...。这套流程本身没问题，但在团队协作里极易被漏掉——我见过太多代码直接调用strtol然后只检查endptr，完全不管ERANGE，于是"99999999999999999999"被悄悄截断成LONG_MAX。

std::stoi的问题在于异常。异常在正常路径上是零成本的，但在失败路径上要展开栈、构造std::invalid_argument或std::out_of_range对象，这个开销在解析高频报文字段的场景下是不可接受的。更麻烦的是很多嵌入式项目、内核模块、以及游戏引擎都会全局关掉异常（-fno-exceptions），这些环境里std::stoi直接编译不过。

std::from_chars是我目前最推荐的新项目方案，它的接口设计其实和strtoi的思路一脉相承：std::from_chars_result里既有ec表示错误种类，又有ptr表示停在哪里，值通过引用传入。但它有硬性门槛——GCC 8 以上、Clang 7 以上、MSVC 2017 15.8 以上，且浮点部分的支持还要更晚。如果你的代码要兼容一批还在跑的旧工具链，手写一个strtoi依然是性价比最高的选择。

2.3 bool + 引用输出：把“是否成功”从“值”里剥出来

bool strtoi(const char *, int &)的核心思想就是通道分离：bool负责回答“成不成功”，int &负责回答“成功时值是多少”。这两个问题在逻辑上本来就是正交的，硬塞进一个返回值里必然有一方要让位。

引用输出相比指针输出有几个实际好处。第一，调用点不用写&，int v; if (strtoi(s, v))读起来比if (strtoi(s, &v))少一层噪音。第二，引用参数在编译期就保证了非空，函数体内不需要再对输出参数做nullptr判断，少一个分支。第三，引用无法被重新绑定，语义上更明确地表达“这是出参，不是可选参数”。

代价也是有的。引用出参意味着这个函数不能直接用在表达式里，你不能写int v = strtoi(s) ? ... : ...，必须分成两句。另外，如果你的项目已经有大量指针风格的接口（比如 C 兼容层），混用引用和指针会显得不统一。我自己的做法是：C++ 侧统一用引用，同时提供一个bool strtoi(const char *s, int *out)的重载给 C 风格调用方，内部做一次空指针检查后转发——两个函数体加起来不到十行，维护成本可以忽略。

2.4 失败时输出参数必须保持原值

这是一个特别容易被忽略的契约细节：转换失败时，int &输出参数不应该被修改。为什么重要？因为调用方经常这么写：

int port = 8080; // 先放一个默认值 if (!strtoi(cfg.get("port"), port)) { log_warn("port 配置非法，沿用默认值 %d", port); }

如果strtoi在内部是先写值、后校验尾部字符，那么解析"8080abc"时会先把8080写进port，然后因为尾部非法返回false，此时port已经被污染成8080，而日志里告诉你“沿用默认值”——实际上默认值早就没了。这种 bug 极其隐蔽，因为它只在失败路径上出现，而且表现为“默认值偶尔不生效”。

正确的写法是：所有校验（包括尾部残留检查）全部做完，确认无误之后，最后一行才写out = value。这一个顺序上的讲究，能省掉后期大量的排查时间。

3. 手写实现的完整拆解

3.1 算法骨架：四段式解析

不管功能怎么扩展，一个可靠的整数解析函数在结构上永远是四段：

1. 跳过前导空白。isspace集合里的字符（空格、\t、\n、\r、\v、\f）允许出现在数字之前。这一条是为了兼容配置文件里key = 123这种写法，以及 shell 传参时残留的空白。
2. 处理符号位。识别一个+或-，记录下来，指针后移一位。注意最多只允许一个符号字符，--5和+-5都是非法的。
3. 至少消费一位数字。这是判断“这是不是一个数字串”的最低门槛。如果符号之后第一个字符就不是'0'-'9'，直接返回false。跳过这一步会导致空串、纯符号串被误判成0。
4. 逐位累加并检测溢出，同时推进指针，直到遇到非数字字符为止。

四段之后还有一段“收尾裁决”，这是区分严格模式和宽松模式的地方：严格模式要求指针必须停在字符串结尾（*p == '\0'），宽松模式则只要求至少解析出一位数字，剩下的交给调用方自己处理。

我个人的建议是默认严格。因为绝大多数场景下（配置解析、JSON 字段、协议文本字段），尾部残留都意味着上游出了问题，早点拒绝比晚点出事好。如果确实需要"123abc"返回123并告诉调用方abc从哪开始，那就再加一个带const char **endptr的重载，而不是把默认行为放宽。

3.2 溢出检测：为什么优先用无符号累加

溢出检测是这类函数里最容易写错的部分，也是面试里最爱问的部分。常见的三种写法，我逐个分析。

写法一：先存long long，累加完再判断是否超int范围。这是最直观的写法，可读性最好。但它有两个问题：一是依赖long long至少 64 位（标准只保证至少 64 位，实际都满足，理论上有风险）；二是如果输入串有 100 位数字，累加过程中long long本身就会溢出，你还是得在循环里做检查。所以这个写法只适合“输入长度有限”的场景，不能作为通用实现。

写法二：先算acc * 10 + d，再判断是否小于acc（回绕检测）。这个技巧依赖无符号整数的模运算性质：如果乘法溢出，结果会回绕变小。看起来聪明，但对于正负号不同的边界值（INT_MIN的绝对值比INT_MAX大 1），处理起来要绕一圈，可读性差，而且一旦有人把无符号改成有符号就立刻变成未定义行为。

写法三：用无符号累加，配合边界预判acc > (limit - d) / 10。这是我最终采用的方案。核心是把上限limit提前算出来——正数上限是INT_MAX，负数上限是INT_MAX + 1（因为它要能表示INT_MIN的绝对值）。这个上限用unsigned int表示，然后每次循环前检查：当前累加值是否已经大到“再乘 10 加d就会超过limit”。数学上acc * 10 + d <= limit等价于acc <= (limit - d) / 10，用后者做判断就完全避开了溢出本身，不存在任何未定义行为。

这里有个细节值得说：limit - d永远不会下溢，因为d最大是 9，而limit至少是INT_MAX（远大于 9）。同理(limit - d) / 10是整数除法，向下取整，判断是保守的——保守意味着不会漏判溢出，最多是“刚好等于边界”的情况被判为合法，而这正是我们想要的。

3.3 完整实现代码（含进制版本）

下面是我在项目里用了三年多、经过上万条随机对拍验证的版本。先看十进制严格版：

#include <climits> #include <cstddef> namespace { // 跳过前导空白，避免依赖 <cctype> 的 isspace（它对负 char 有 UB 风险） inline const char *skip_ws(const char *p) { while (*p == ' ' || *p == '\t' || *p == '\n' || *p == '\r' || *p == '\v' || *p == '\f') { ++p; } return p; } // 把 0-9 / a-f / A-F 映射成数值，非法返回 -1 inline int digit_val(char c) { if (c >= '0' && c <= '9') return c - '0'; if (c >= 'a' && c <= 'f') return c - 'a' + 10; if (c >= 'A' && c <= 'F') return c - 'A' + 10; return -1; } } // namespace // 严格模式：整串必须被完整消费，不允许尾部残留 bool strtoi(const char *s, int &out) { if (s == nullptr) return false; const char *p = skip_ws(s); bool neg = false; if (*p == '+' || *p == '-') { neg = (*p == '-'); ++p; } if (*p < '0' || *p > '9') return false; // 至少要有一位数字 // 上限用无符号表示，负数比正数多一个 const unsigned int limit = neg ? (static_cast<unsigned int>(INT_MAX) + 1u) : static_cast<unsigned int>(INT_MAX); unsigned int acc = 0; while (*p >= '0' && *p <= '9') { const unsigned int d = static_cast<unsigned int>(*p - '0'); if (acc > (limit - d) / 10u) return false; // 溢出，提前退出 acc = acc * 10u + d; ++p; } // 严格模式收尾：只允许尾部空白 p = skip_ws(p); if (*p != '\0') return false; // 到这里才写输出参数，保证失败时 out 保持原值 if (neg) { // 避免 -INT_MIN 溢出：先减 1 再取负再减 1 out = -static_cast<int>(acc - 1u) - 1; } else { out = static_cast<int>(acc); } return true; }

这段代码里有三个地方值得单独拎出来讲。

第一处是-static_cast<int>(acc - 1u) - 1这个写法。直觉上你会想写out = -static_cast<int>(acc)，但当acc == 2147483648（也就是INT_MIN的绝对值）时，static_cast<int>(2147483648u)是实现定义行为，在补码机上会得到INT_MIN，然后对它取负就是未定义行为。先用acc - 1把值降到INT_MAX以内，取负之后再减 1，整个过程所有中间值都在int的合法范围内，没有任何 UB。

第二处是skip_ws没有用<cctype>的isspace。原因在 3.4 节展开，简单说就是char在很多平台上有符号，传入大于 127 的字节会踩到未定义行为。

第三处是收尾的“只允许尾部空白”。这意味着"123 \n"会成功，"123abc"会失败。如果你希望"123 456"也失败（显然应该失败，因为中间夹了空格之后又有数字），这个写法天然就做到了——跳过尾部空白后指针停在'4'上，不等于'\0'，返回false。

再来看带进制的版本。有些场景需要解析十六进制的寄存器地址或者二进制掩码，加一个base参数就能覆盖：

// base 取值：0（自动识别）、2、8、10、16 // base == 0 时，0x/0X 前缀按 16 进制，0 前缀按 8 进制，否则 10 进制 bool strtoi(const char *s, int &out, int base) { if (s == nullptr) return false; if (!(base == 0 || base == 2 || base == 8 || base == 10 || base == 16)) return false; const char *p = skip_ws(s); bool neg = false; if (*p == '+' || *p == '-') { neg = (*p == '-'); ++p; } // 自动识别进制 if (base == 0) { if (p[0] == '0' && (p[1] == 'x' || p[1] == 'X')) { base = 16; p += 2; } else if (p[0] == '0') { base = 8; // 注意：不前进，"0" 本身要作为一位八进制数字被解析 } else { base = 10; } } else if (base == 16 && p[0] == '0' && (p[1] == 'x' || p[1] == 'X')) { p += 2; // 显式指定 16 进制时也允许 0x 前缀 } const char *first_digit = p; const unsigned int limit = neg ? (static_cast<unsigned int>(INT_MAX) + 1u) : static_cast<unsigned int>(INT_MAX); unsigned int acc = 0; for (;; ++p) { const int d = digit_val(*p); if (d < 0 || d >= base) break; const unsigned int ud = static_cast<unsigned int>(d); if (acc > (limit - ud) / static_cast<unsigned int>(base)) return false; acc = acc * static_cast<unsigned int>(base) + ud; } if (p == first_digit) return false; // "0x" 后面没数字，非法 p = skip_ws(p); if (*p != '\0') return false; out = neg ? -static_cast<int>(acc - 1u) - 1 : static_cast<int>(acc); return true; }

进制版本里有个坑点要提醒：base == 0且输入是"0"时，会被识别成八进制，但"0"本身作为一位八进制数字是合法的，所以不能像"0x"那样把指针往前推。我最初的版本在这里写成p += 1，结果strtoi("0", v, 0)直接返回false，单元测试当场抓出来。

3.4 字符判断的隐藏地雷

<cctype>里的isdigit(c)看起来是判断数字字符的标准做法，但它的参数约定是：c必须是unsigned char能表示的值，或者EOF。如果你传一个负的char进去，行为未定义。而char在 x86 Linux 和 Windows 上默认是有符号的，这意味着任何一个字节值大于 127 的 UTF-8 字符（比如中文注释里的字）传进去就是 UB。

这个 UB 在实际中的表现是什么？在 glibc 上通常没事，因为它的实现用了查表加偏移，负索引也落在某块内存里，返回一个“看起来合理”的结果；但在某些嵌入式 libc 上，它可能直接越界读。更麻烦的是，如果你的代码开了 UBSan，-fsanitize=undefined会直接在运行时报错。我之前在一个跨平台项目里就被这个坑过——同样的代码在 x86 上跑得好好的，交叉编译到 ARM 之后解析一段带中文的配置就崩了。

规避方式有两个：一是像上面代码那样直接写范围比较c >= '0' && c <= '9'，标准保证'0'到'9'在字符集中的编码是连续的，这个比较是绝对安全的；二是如果非要用isdigit，就显式转型isdigit(static_cast<unsigned char>(c))。

还有一个更高层的建议：如果只是判断 ASCII 数字，永远不要用 locale 相关的函数。isdigit在默认的"C"locale 下行为没问题，但万一有人调用了setlocale(LC_ALL, "")，某些 locale 下isdigit的行为会变得和你预期不一样。手写范围比较零成本，还省掉一次函数调用。

4. 测试用例：把边界值钉在表格里

4.1 必须覆盖的 12 类输入

这个函数的单元测试我前前后后改了五六轮，每次线上出问题都会往里加一条。现在沉淀下来的必测清单是这样：

表格里我特意把"-2147483648"和"-2147483649"放在一起，这两个就差一个数，但前者必须成功、后者必须失败。任何在INT_MIN边界上用-static_cast<int>(acc)直接取负的实现，都会在前者上踩到未定义行为。这一对用例是我认为最能暴露实现缺陷的，建议每次改完代码先跑这两条。

4.2 表驱动单测代码

用表驱动写这个测试最省事，加用例只是往数组里加一行：

#include <cstdio> #include <cstring> #include <climits> struct Case { const char *input; bool expect_ok; int expect_val; // expect_ok 为 false 时忽略 }; static const Case kCases[] = { {"123", true, 123}, {"-456", true, -456}, {"0", true, 0}, {"-0", true, 0}, {"+789", true, 789}, {" 42", true, 42}, {"42 ", true, 42}, {"", false, 0}, {" ", false, 0}, {"+", false, 0}, {"-", false, 0}, {"123abc", false, 0}, {"abc123", false, 0}, {"--5", false, 0}, {"2147483647", true, INT_MAX}, {"-2147483648", true, INT_MIN}, {"2147483648", false, 0}, {"-2147483649", false, 0}, }; int main() { int failed = 0; for (const auto &c : kCases) { int v = 0x5A5A5A5A; // 哨兵值，用来验证失败时不修改出参 const bool ok = strtoi(c.input, v); if (ok != c.expect_ok) { std::printf("[FAIL] \"%s\" 期望 ok=%d 实际 %d\n", c.input, c.expect_ok, ok); ++failed; continue; } if (ok && v != c.expect_val) { std::printf("[FAIL] \"%s\" 期望值 %d 实际 %d\n", c.input, c.expect_val, v); ++failed; continue; } if (!ok && v != 0x5A5A5A5A) { std::printf("[FAIL] \"%s\" 失败时污染了出参 %d\n", c.input, v); ++failed; } } std::printf("%s: %d/%zu 通过\n", failed ? "FAILED" : "PASSED", static_cast<int>(sizeof(kCases)/sizeof(kCases[0])) - failed, sizeof(kCases)/sizeof(kCases[0])); return failed ? 1 : 0; }

注意那个0x5A5A5A5A哨兵值。它不是一个随手挑的魔数，而是一个“几乎不可能被正常解析结果命中”的值，用来检查失败时出参是否被污染。如果你的实现在失败路径上写了一次out，这个断言会立刻炸出来。这个技巧我从一个老同事那里学来，之后每个带出参的函数我都会这么测。

4.3 与 strtol 的随机对拍

表驱动测试覆盖的是“我想到的边界”，随机对拍覆盖的是“我没想到的边界”。做法很简单：随机生成长度 1 到 20 的字符串，字符集限定为0-9、+、-、空格、a、x，然后用strtol作为参考实现，逐个比对结果。

对拍的关键是参考实现本身要写对：

bool ref_strtoi(const char *s, int &out) { errno = 0; char *end = nullptr; const long v = std::strtol(s, &end, 10); if (end == s) return false; // 一位都没解析出来 while (*end == ' ' || *end == '\t') ++end; if (*end != '\0') return false; // 尾部有残留 if (errno == ERANGE) return false; // 溢出 if (v > INT_MAX || v < INT_MIN) return false; out = static_cast<int>(v); return true; }

跑十万条随机串，一旦出现不一致，就把那条串打印出来单独分析。我第一版实现就是在对拍里发现"0x10"在十进制模式下被我的实现判成“尾部有 'x' 所以失败”，而strtol的end停在'x'上，判的也是失败——两边一致。但" "（两个空格）这种输入我的实现返回false，strtol的end == s也返回false，同样一致。真正对不上的是一条" + "，原因是我早期版本在处理符号之前先跳了空白，符号之后又跳了一次空白，导致"+ 5"被误判成合法。这个 bug 表驱动测试里我没写到，是对拍捞出来的。

5. 性能账本与选型建议

5.1 实测：手写 vs strtol vs stoi vs from_chars

我在一台普通 x86-64 机器上做过一轮微基准，输入是一百万条长度在 1 到 6 位之间的十进制数字串，全部合法，编译器开-O2。结果大致是这样的量级关系（具体数字会随机器和编译器波动，这里只说相对关系）：

手写版本比atoi慢的那一点点，基本就是溢出检测的成本——每次循环多一次除法和比较。除法在 x86 上虽然慢，但(limit - d) / 10里的除数是编译期常量 10，编译器会把它优化成一次乘加和移位，实测开销可以忽略。相比之下strtol慢在它要支持任意进制、要查 locale 表、要处理千位分隔符（在某些 locale 下），这些你都不需要。

如果你的场景真的对性能极度敏感（比如每秒解析上百万条报文），还有一个优化点：把进制作为模板参数或者用单独的strtoi_dec函数，让编译器把进制常量 10 完全内联展开，循环里就只剩乘 10 和加，连除法都能省掉。这个小改动我实测能再快 15% 左右。

5.2 什么情况下该用 from_chars

如果你的项目已经全面 C++17，且工具链版本足够新，我建议直接用std::from_chars，不要自己造轮子。它的语义和strtoi高度一致：返回值里有ec表示错误类型（std::errc::invalid_argument、std::errc::result_out_of_range），有ptr表示解析停在哪，值通过引用传。而且它的严格程度比手写版本更高——from_chars不接受前导空白，也不接受+号前缀（-号接受），这一点和strtol不同，用的时候要注意。

#include <charconv> #include <system_error> bool strtoi_cpp17(const char *s, int &out) { if (s == nullptr) return false; const char *end = s + std::strlen(s); const auto r = std::from_chars(s, end, out); return r.ec == std::errc{} && r.ptr == end; }

短短几行，错误处理全靠errc，没有异常、没有errno、没有 locale。唯一的问题是from_chars在越界时不会写入out，这个行为正好符合我们前面定的契约，算是意外之喜。

反过来说，如果你的代码里有以下任一情况，老老实实手写：工具链是 GCC 7 及更早；项目编译选项里有-fno-exceptions且不支持 C++17；你需要支持自定义进制（from_chars的base参数是 C++17 就有的，但它不支持base == 0自动识别）；你需要在解析失败时区分“非法字符”和“溢出”两种错误并给出不同提示。

5.3 老代码渐进迁移

大规模替换atoi不能一把梭，容易在业务逻辑里引入回归。我采用的是“先加断言，再替换，最后清理”的三步走。

第一步，全局搜索atoi(，在每一处调用的后面加一行assert，断言返回值不是可疑值。这一步不改逻辑，只是让问题在测试环境里暴露出来。跑一周的回归测试之后，你就能拿到一份“哪些调用点真的会传垃圾数据”的清单。

第二步，优先替换那些已经出过问题的调用点。替换时保留原逻辑的兜底行为：原来atoi返回 0 就当 0 用，那就写成“解析失败时也置 0，但打一条 warn 日志”。这样行为不变，但问题变得可见了。

第三步，等日志里 warn 的数量降到零之后，再把兜底逻辑改成“拒绝启动”或者“使用默认值”。这时候你已经有了数据支撑，知道哪些配置项是真的可能非法的，不会上线就炸。

这个流程看起来慢，但它把“行为变更”和“可见性提升”拆成了两步，每一步的风险都可控。我见过太多团队直接一次性替换全部atoi，结果上线后一批原本“能跑”的脏配置变成启动失败，回滚都来不及。

6. 落地影响面与常见问题排查

6.1 影响范围盘点

strtoi这类函数的调用点分布之广，往往超出预期。我在一个中等规模的项目里做过一次统计，涉及的地方包括：配置文件的键值解析（ini、yaml、json的数值字段）、命令行参数解析（--port 8080）、网络协议文本字段（HTTP 头里的Content-Length）、日志回放工具（从日志里抠耗时数字）、测试框架的数据驱动表（把字符串表项转成数字）、以及各种“从环境变量读配置”的胶水代码。

这些场景对“严格性”的要求其实不一样。环境变量和命令行参数通常来自人，尾部残留是明显的输入错误，应该严格拒绝；而日志解析和协议字段来自机器，格式可能存在历史包袱，需要宽松模式加endptr来容忍。所以我在实际项目里最终提供了三个入口：严格版strtoi、宽松版strtoi_prefix（返回bool加const char **）、以及带进制的重载。三者共用同一套核心解析逻辑，通过一个内部函数加参数控制行为，避免了三份实现三份 bug 的窘境。

6.2 排查速查表

下面这张表是我这几年遇到过的真实问题汇总，基本都是“看起来能跑但结果不对”的类型：

表里第一条特别值得说：if (!strtoi(s, v) || v == 0)这种写法看起来是在做双重保险，实际上是把strtoi的返回值语义又塌陷回去了——v == 0这个条件会把合法的"0"判成失败。写这种代码的人往往是习惯了atoi时代的“返回 0 就是错”，思维惯性一时改不过来。我的建议是：既然用了bool返回值，就只用bool判断成败，绝不再看值本身，这样才能真正把两个语义分开。

还有一个容易被忽略的细节：strtoi不修改errno。这一点和strtol不同。如果你的项目里有代码依赖errno判断错误，在strtoi之后读errno会读到上一次strtol残留的ERANGE，产生误判。所以迁移的时候，所有依赖errno的分支都要一起删掉，不能只换函数不换判断逻辑。

最后再补一个我个人的实现习惯：把边界值INT_MAX和INT_MIN的字符串形式硬编码成两条断言放在测试文件的最顶上，每次改完strtoi的代码先跑这两条。这两个值一旦出错，基本能覆盖 90% 的溢出检测逻辑问题，是最划算的两个测试用例。至于"0x7FFFFFFF"、"-0x80000000"这种十六进制边界，我一般放在单独的一组用例里，只在改动进制相关代码时才跑。