std::to_chars 比 sprintf 更快，因为它无格式解析、无 locale 查表、无内存分配，仅将数字转为 ASCII 写入用户缓冲区；整数性能为 sprintf 的 2–3 倍，浮点数略慢但稳定。
std::to_chars 为什么比 sprintf 更快
因为 std::to_chars 是无格式、无 locale、无内存分配的纯写入操作，它只把数字转成 ASCII 字符串写进你提供的缓冲区，不解析格式字符串、不查本地化表、不 new 任何东西。实测在整数转字符串场景下，性能通常是 sprintf 的 2–3 倍，浮点数略慢但依然稳定。
但它不处理前导零、对齐、进制切换（比如十六进制）——这些得你自己补。常见错误是传入太小的缓冲区导致返回 std::errc::value_too_large，而很多人直接忽略这个错误码。
- 整数转换至少需要
std::numeric_limits<int>::digits10 + 2字节（+1 符号位，+1 结尾空字符预留，虽然to_chars不写\0，但你后续用std::string_view或 C 接口时得留位置） - 浮点数转换推荐用
std::to_chars(buf, buf + size, value, std::chars_format::general)，避免用std::chars_format::fixed或scientific时因精度不足触发失败 -
std::to_chars对float支持依赖编译器实现，GCC 11+ 和 Clang 12+ 完整支持，MSVC 从 19.30 开始支持；老版本可能静默降级为std::sprintf
如何安全分配缓冲区并检查错误
别硬写 32 或 64 这种“看起来够大”的数字。正确做法是按类型上限算最小尺寸，再加一两个字节冗余。转换后必须检查返回的 ptr 是否落在缓冲区内，且 ec 是否为 std::errc{}。
char buf[64]; // int64_t 最多 20 位十进制 + 符号 = 21，64 足够
auto [ptr, ec] = std::to_chars(buf, buf + sizeof(buf), 123456789012345LL);
if (ec != std::errc{}) {
// 处理错误，不是抛异常，而是重试或 fallback
return;
}
std::string_view result(buf, ptr - buf); // 注意：不包含 '\0'- 浮点数建议用
buf[128]起步，double在general格式下最长可能达 ~100 字符（含指数部分） - 不要用
std::string的.data()直接传给to_chars，C++17 中它不一定可写；改用.reserve()后取.data()，或用std::array<char, N> - 错误码只有
std::errc::value_too_large和std::errc::invalid_argument（后者极少，仅当传入 NaN/Inf 且 format 不支持时）
怎么处理浮点数精度与截断问题
std::to_chars 默认使用“最短精确表示”（shortest round-trip），即生成的字符串能无损还原回原浮点值。但它不保证人类可读的“保留两位小数”效果——那是 std::sprintf 或 std::format 的事。
立即学习“C++免费学习笔记（深入）”；
如果你需要固定小数位（比如金额），不能靠 to_chars 直接实现，得先乘缩放因子转整数，再调用整数版 to_chars：
// 想输出 "123.45"
double v = 123.45;
long long scaled = static_cast<long long>(v * 100 + 0.5); // 注意舍入
char buf[32];
auto [ptr, ec] = std::to_chars(buf, buf + sizeof(buf), scaled);
if (ec == std::errc{} && ptr - buf <= 30) {
// 手动插入小数点：buf → "12345" → 插入 '.' 倒数第二位前
std::rotate(ptr - 2, ptr - 1, ptr);
*(ptr - 2) = '.';
std::string_view result(buf, ptr + 1 - buf); // 现在是 "123.45"
}- 直接对浮点数调
to_chars并截断字符串会破坏精度，比如1.0000000000000002可能被截成"1."导致信息丢失 - 不要用
std::chars_format::fixed强制小数位，它只控制格式，不改变实际精度；而且容易因缓冲区不够失败 - IEEE 754 double 能精确表示的十进制小数非常有限，做金额务必用整数运算
和 std::format / fmt::format 比有什么 trade-off
std::to_chars 快，但只干一件事：数值到字符序列。没有字段宽度、填充字符、进制切换、locale 感知。如果项目里已有 fmt::format，且吞吐量没到百万次/秒级别，别为了微秒级优化强行切到 to_chars。
- 要 hex 输出？
std::to_chars不支持，得自己写除法循环或用std::sprintf(buf, "%x", x) - 要右对齐 10 字符宽？得手动计算空格数，再 memmove 字符串
- 要线程安全？
to_chars是纯函数，无全局状态，天生线程安全；但你的缓冲区要是栈上局部变量，就得确保不逃逸 - C++20 的
std::format底层其实也用了to_chars，但它封装了格式解析开销——所以单次调用慢，批量调用可借助编译期格式字符串优化
真正关键的是：你是否在 hot path 上做大量数值转字符串？如果是，to_chars 值得引入；如果只是日志拼接或配置序列化，优先选可维护性。
