<p>std::to_chars是C++中数字转字符串的最快方法，但需复用缓冲区、避免std::string构造、忽略浮点精度控制；缓冲区不足时静默截断，须检查result.ec；整数最多20字节，double建议32字节；result.ptr指向写入结束位置，长度为result.ptr - buf。</p>
直接说结论：std::to_chars 是目前 C++ 标准库中数字转字符串的最快路径，但“快”只在你绕过 std::string 构造、复用缓冲区、且不碰浮点精度控制的前提下成立。
缓冲区大小算不准，std::to_chars 就会静默截断
传太小的 buffer 不会崩溃，但 result.ec 会被设为 std::errc::value_too_large，而很多人忽略返回值，结果拿到半截字符串还浑然不觉。
- 整数（
int64_t）：最多需要std::numeric_limits<int64_t>::digits10 + 2</int64_t>字节（即 20 字节），覆盖最坏情况"-9223372036854775808" - double：C++17 要求至少
std::numeric_limits<double>::max_digits10 + 2</double>（17 + 2 = 19），但实际建议留 32 字节；DBL_MIN可能输出长达 24 字符（如"2.2250738585072014e-308"） - 别用
sizeof("123")这类硬编码——它不含符号位，也不适配科学计数法或负数 - 高频场景下，用
static char buf[32]复用栈缓冲区，比每次std::string构造省得多
result.ptr 不是字符串结尾，而是写入结束位置
std::to_chars 返回的 ptr 指向写入后**下一个字节**，不是 buffer 末尾，也不是 <p><code>std::to_chars 返回的 ptr 指向写入后**下一个字节**，不是 buffer 末尾，也不是 \0 终止符位置。误把它当 c_str() 用会导致越界读或乱码。
c_str() 用会导致越界读或乱码。
- 正确取长度：
result.ptr - buf，不是strlen(buf)（buf里根本没有\0） - 需要
std::string？用std::string(buf, result.ptr - buf)，别用std::string(buf)（会读到第一个\0，但没写） - 若后续喂给
std::string_view或系统调用（如write），根本不用加\0 - 非要 C 字符串？只在
result.ec == std::errc{}且result.ptr 时，执行 <code>*result.ptr = '\0'
std::to_chars 对 float/double 的行为不可控
它选 f 还是 e 格式取决于“最短可 round-trip 的表示”，但无法指定小数位数、不支持补零、不同标准库实现输出长度可能差很多。
立即学习“C++免费学习笔记（深入）”；
- 想固定 2 位小数？
std::to_chars做不到。要么切回std::sprintf（注意线程安全），要么用fmt::format("{:.2f}", x) -
std::chars_format::fixed只控制格式，C++17 中precision参数未被实现支持 - 要无损 round-trip？确保 buffer ≥ 19 字节，并验证
from_chars(to_chars()) == original - C++23 的
std::chars_format::hex可输出 IEEE-754 十六进制字符串，但 Clang 15+ 才完整支持，GCC 13 尚未落地
真正卡性能的地方，往往不是 std::to_chars 本身，而是后续构造 std::string 或反复分配栈 buffer。缓冲区复用、std::string_view 直接消费、避免隐式 \0 终止，比函数调用开销重要得多。
