std::to_chars比sprintf快且安全，但需手动管理缓冲区、不写'\0'、不支持格式控制；用错会导致读取未初始化内存或截断，必须检查ec并用ptr计算长度。
std::to_chars 比 sprintf 快且安全，但必须手动管缓冲区、不写 \0、不支持格式控制——用错就白换。
为什么 std::to_chars 不崩溃却输出乱码
它不检查缓冲区边界，也不写终止符 \0，只把数字字符挨个填进你给的内存区间，然后在 result.ptr 处停下。如果你忽略 result.ec 或直接拿 buf 起始地址当字符串用，就会读到未初始化内存。
- 错误写法：
std::string s(buf)—— 依赖\0，但to_chars根本没写 - 正确写法：
std::string s(buf, result.ptr - buf)—— 用返回指针算长度 - 常见误判：
result.ptr == buf + size不代表成功，得先确认result.ec == std::errc{} - 缓冲区太小的典型表现：返回
result.ec == std::errc::value_too_large，result.ptr可能等于last（即越界临界点）
int/double 缓冲区到底该开多大
硬写 char buf[16] 对 int 还凑合，对 double 就是埋雷。C++ 标准没规定最大长度，不同库实现差异大，尤其极小值（如 DBL_MIN）会走科学计数法，占满 24 字节以上。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
int32_t最坏情况：11 字节（-2147483648），推荐char buf[16] -
int64_t最坏情况：20 字节（-9223372036854775808），推荐char buf[24] -
doubleround-trip 安全：至少std::numeric_limits<double>::max_digits10 + 2</double>→ 17 + 2 = 19，但留余量建议char buf[32] - 别信
digits10（15），它只保精度下限；max_digits10（17）才是 round-trip 不丢值的底线
std::to_chars 返回值怎么用才不翻车
它返回 std::to_chars_result，含两个字段：ptr 和 ec。漏查任一个都可能让错误静默通过。
-
ec != std::errc{}：转换失败，常见原因只有缓冲区不够或传入 NaN/Inf（取决于实现） -
ptr == first：没写任何字符（比如传了NaN且库不支持），但ec可能仍是{}，得结合判断 - 想喂给
printf或系统调用？必须手动加\0：*result.ptr = '\0'，前提是ec正常且result.ptr - 只构造
std::string_view？完全不用\0：std::string_view{buf, static_cast<size_t>(result.ptr - buf)}</size_t>
什么时候不该用 std::to_chars
它不是万能替代品。如果你需要补零、千分位、固定小数位、左对齐或 locale 感知（比如德语小数点是逗号），它直接不支持。
- 要
"00123"？自己拼前导零，to_chars不管 - 要
"1,000.00"？换std::format（C++20）或sprintf - 要保留两位小数？
to_chars输出的是精确可逆表示，3.1415926可能变"3.1415926"，截断得自己做 - 要兼容老 locale 行为？
to_chars永远用 C locale，和sprintf在非 C locale 下结果可能不同
最易被忽略的一点：性能优势只在高频小数据场景兑现。如果每次转换后都要拷贝进 std::string、再拼接日志头尾、再进队列，那 to_chars 省下的几纳秒早被后续操作吞掉了——关键在整条链路是否围绕“零拷贝”设计。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
