std::to_chars 是 C++ 数字转字符串最快方法，但需手动计算缓冲区大小、检查返回值、用 result.ptr - buf 计算长度，且不支持浮点小数位控制；否则性能归零或引发静默错误。
std::to_chars 是目前 C++ 标准库中数字转字符串的最快路径，但它的“快”只在你绕过 std::string 构造、复用缓冲区、且不碰浮点精度控制时才成立；一旦传错缓冲区大小、忽略返回值、或指望它输出固定小数位，性能优势立刻归零，甚至引入静默错误。
缓冲区大小必须手动算准，不能靠猜
传太小的 buffer 不会崩溃，但 std::to_chars 会静默返回 std::errc::value_too_large —— 很多人忽略 result.ec，结果拿到半截字符串还浑然不觉，线上极难排查。
- 整数（
int64_t）最坏情况是"-9223372036854775808"（20 字符），推荐固定声明char buf[24]，留出符号、进制切换或未来扩展余量 - double 最小保证长度是
std::numeric_limits<double>::max_digits10 + 2</double>（即 19），但极小值如DBL_MIN可能输出长达 24 字符（例如"2.2250738585072014e-308"），保守起见统一用char buf[32] - 别用
sizeof("123")或硬编码[16]：它不含负号、不覆盖科学计数法、也不适配不同平台对极小值的输出长度 - 别对
std::string::data()调用resize(n)后直接传 ——resize(n)不保证末尾为'\0'，且result.ptr可能远小于data() + n
result.ptr 指向写入结束位置，不是字符串结尾
std::to_chars 返回的 ptr 指向**最后一个有效字符的下一个位置**，不是 buffer 末尾，也不是 '<p><code>std::to_chars 返回的 ptr 指向**最后一个有效字符的下一个位置**，不是 buffer 末尾，也不是 '\0' 所在处。误当成 C 字符串首地址直接传给 printf 或 std::string(const char*)，会读到脏内存或崩溃。
printf 或 std::string(const char*)，会读到脏内存或崩溃。
- 正确取长度只有一条公式：
result.ptr - buf。要喂给std::string_view就直接用这个长度 - 构造
std::string时，必须用std::string(buf, result.ptr - buf)，而非std::string(buf)—— 后者会一直读到内存里第一个'\0'，不可控 - 仅当必须传递给 C 接口（如
write()、printf()）时，才在确认result.ec == std::errc{}且result.ptr 后执行 <code>*result.ptr = '\0' - 严禁硬编码
buf[31] = '\0'—— 若实际只写了 5 字节，这会覆盖后面可能的有效数据
浮点数输出不可控，std::to_chars 做不到指定小数位
std::to_chars 对 float/double 的输出格式由“最短可 round-trip 的十进制表示”决定，不接受小数位参数，也不补零。同一值在 libstdc++ 和 libc++ 下可能输出 "0.1" 或 "0.10000000000000001" —— 这不是 bug，是标准允许的行为，但会导致 UI 显示错乱、金融校验失败、配置序列化不一致。
立即学习“C++免费学习笔记（深入）”；
-
std::chars_format::fixed只强制格式，不控制小数位数；C++17 中precision参数未被任何主流标准库实现支持 - 想输出
"3.14"而非"3.1415926"？必须切回std::sprintf(buf, "%.2f", x)（注意线程安全）、用fmt::format("{:.2f}", x)，或自己实现舍入+截断逻辑 - 若只要无损 round-trip（即转回浮点数能还原原值），确保
buffer ≥ 19字节，并验证from_chars(to_chars()) == original
真正拖慢吞吐的往往不是 std::to_chars 本身（实测单次调用通常在 10–30 ns），而是后续操作：反复分配栈 buffer、隐式构造 std::string、或强行加 '\0' 破坏 std::string_view 的零拷贝语义。高频场景下，这些细节比算法选择更关键。
