std::to_chars仅支持整数转换且需预分配缓冲区、检查错误码、用result.ptr-buf获取长度，浮点数必须用fmt::format_to或snprintf；忽略任一环节将导致截断、越界或编译失败。
std::to_chars 是目前 C++ 标准库中整数转字符串的最快路径，但浮点数不支持直接转换（编译失败），且整数场景下“快”只在缓冲区预分配合理、返回值被检查、长度被正确提取时才成立；一旦漏掉其中任一环，性能优势归零，甚至引入静默截断或越界。
std::to_chars 编译报错：float/double 无重载
试图对 double 或 float 调用 std::to_chars 会触发编译错误：no matching function for call to 'to_chars'。C++17 标准只定义了整型（int、long long 等）和 char 的重载，没提供浮点版本——这不是 libc 实现缺失，而是标准层面的明确排除。
- 常见错误现象：代码在本地编译通过（误用了自定义重载或宏替换），上线后 GCC/Clang 报错
- 别写
std::to_chars(buf, buf + size, 3.14)，它永远不合法 - 想高性能转浮点？切到
fmt::format_to或std::snprintf，别硬扛 - C++23 引入了
std::chars_format::hex支持 IEEE-754 十六进制字符串，但 GCC 13 尚未落地，Clang 15+ 才开始支持，生产环境暂不可用
整数转换：缓冲区大小与静默截断风险
缓冲区太小不会崩溃，但返回 std::errc::value_too_large；忽略它，就等于接受半截字符串——线上日志里出现 "123" 而不是 "-9223372036854775808"，极难定位。
-
int64_t最坏情况是"-9223372036854775808"（20 字节），推荐声明char buf[24]，留出余量 - 别用
sizeof("123")或硬编码[16]：它不含负号、不覆盖base=2（二进制最长 65 字节）、也不适配base=16下的前缀 - 必须检查
result.ec != std::errc{}，否则无法区分成功与截断 - 实际写入长度唯一合法表达式是
result.ptr - buf，不是strlen(buf)（buffer 里没'\0'），也不是sizeof(buf)
ptr 指向哪？常见越界和乱码根源
std::to_chars 返回的 ptr 指向**最后一个有效字符的下一个位置**，不是 '\0' 位置，也不是 buffer 末尾。把它当 C 字符串指针用，必然读脏内存或构造出含垃圾内容的 std::string。
立即学习“C++免费学习笔记（深入）”；
- 错误写法：
std::string s(buf)—— 构造函数按'\0'截断，而 buffer 里根本没写它 - 正确写法：
std::string s(buf, result.ptr - buf)，显式传长度 - 只在需喂给 C 接口（如
write()、printf()）时，才执行*result.ptr = '\0'，且必须先确认result.ec == std::errc{} - 严禁
buf[31] = '\0'：若实际只写了 5 字节，这会覆盖后续可能的有效数据 - 只读场景（如日志拼接、HTTP 响应体）优先用
std::string_view(buf, result.ptr - buf)，零拷贝、零终止、零额外开销
性能瓶颈不在 to_chars 本身，而在你后续操作
实测 std::to_chars 单次调用仅 10–30 ns（x86-64），远快于 std::sprintf（100–500 ns）或 std::to_string（200–800 ns）。但真正拖慢吞吐的，往往是后续那行 std::string(buf)、反复栈分配 buf[64]、或强行加 '\0' 破坏 std::string_view 的零拷贝语义。
- 高频循环中，把
char buf[24]提到作用域外复用，比每次进函数都 new 一块快得多 - 避免隐式构造
std::string：能用std::string_view就别转std::string - 别为“看起来像字符串”而加
'\0'：除非下游 API 明确要求 C 字符串语义，否则纯属多余开销 - 浮点需求若含精度控制（如金融显示两位小数），
std::to_chars从一开始就不该出现在方案里——直接上fmt::format("{:.2f}", x)或线程安全的std::snprintf
