atoi静默返回0且无法区分失败与合法0，stoi则抛异常；stoi支持进制参数、返回解析位置，但性能开销大且依赖异常机制；推荐用std::from_chars替代atoi或stoi以兼顾安全与性能。
atoi 会静默失败，stoi 会抛异常
atoi 来自 C 标准库（0 —— 即使原字符串是 "abc" 或空串，也返回 0，无法区分“转成 0”和“根本没转”。stoi 是 C++11 引入的（std::invalid_argument；超出整型范围则抛 std::out_of_range。
常见错误现象：
- 用 atoi(" ") 得到 0，误以为转换成功
- 用 stoi("") 程序崩溃（未捕获异常）
- 用 stoi("123abc") 成功返回 123（它只读到首个非法字符为止，这点和 atoi 一致）
实操建议：
- 不要依赖 atoi 的返回值做错误判断
- 用 stoi 必须加 try/catch，尤其处理用户输入或文件读取时
- 若需类似 atoi 的“尽力而为+不抛异常”行为，可用 std::from_chars（C++17，更轻量且不抛异常）
stoi 支持进制参数，atoi 固定按 10 进制解析
atoi 只识别十进制，且会跳过开头空白，识别 "0x" 前缀当十六进制（但这是实现相关行为，标准不保证）；stoi 明确支持 base 参数，可指定 2–36 进制，且默认行为是“按前缀自动识别”：即 "0x1F" → 31，"017" → 15（注意：stoi 默认 *不* 把 0 开头当八进制，除非显式传 8）。
实操建议：
- 需要解析二进制字符串（如 "1010"）必须用 stoi(s, nullptr, 2)
- 显式传 0 表示“按前缀自动推断”，等价于 stoi(s, nullptr, 0)
- atoi 对 "0123" 的行为不可靠：有些平台当八进制，有些当十进制 —— 别依赖它
stoi 可返回解析位置，atoi 完全丢弃偏移信息
stoi 第二个参数是 size_t* 类型的指针，填入后可获得“实际解析到第几个字符”，比如 stoi("42px", &idx) 后 idx == 2；atoi 没有这个能力，想获取偏移只能自己手写跳过空白+找数字边界。
实操建议：
- 验证字符串是否“完全由整数构成”：调用 stoi 后检查 idx == s.length()
- 解析混合格式（如 "123,456,789"）时，可循环用 stoi + idx 推进位置
- atoi 在这种场景下必须配合 strtol（它也有 char** endptr 参数）才能拿到位置，但接口更 C 风格
性能与 ABI 兼容性差异被低估
atoi 是纯 C 函数，零开销抽象，内联友好，几乎所有编译器能把它优化成几条指令；stoi 是 C++ 函数，内部可能构造临时对象、抛异常栈展开 —— 即使你 catch 了，异常机制本身在某些嵌入式或禁用异常的环境下不可用。另外，stoi 依赖 std::string，而 atoi 只要 const char*，对 C 风格字符串更直接。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 在性能敏感路径（如游戏主循环、高频日志解析）优先测 atoi 或 std::from_chars
- 禁用异常（-fno-exceptions）时，stoi 编译失败，必须换方案
- 跨语言接口（如导出给 Rust/Python 调用）中，atoi 更易封装，stoi 的异常跨越 ABI 边界是未定义行为
真正容易被忽略的是：stoi 对 Unicode 空格（如 \u3000）不识别为“空白”，而 atoi 依赖 C locale，行为随环境变化 —— 如果输入可能含全角空格，两者都会失败，得先清洗。
