std::to_chars 是 C++ 数字转字符串最快路径，但仅在复用缓冲区、避开 std::string 构造、不控浮点精度时成立；缓冲区需整数 24 字节、浮点 32 字节，忽略返回值或误用 null 终止将导致截断或越界。
std::to_chars 是目前 C++ 标准库中数字转字符串的最快路径，但“快”只在你避开 std::string 构造、复用缓冲区、且不碰浮点精度控制时成立；一旦传错缓冲区大小、忽略返回值、或指望它输出固定小数位，性能优势立刻归零，甚至引入静默错误。
缓冲区大小算不准，std::to_chars 就会静默截断
常见错误现象：输出字符串变短、末尾字符乱码、后续内存被意外覆盖，但程序不崩溃也不报错。
- 整数（
int64_t）最坏情况是"-9223372036854775808"（20 字符），建议用std::numeric_limits<int64_t>::digits10 + 2</int64_t>计算，固定分配char buf[24]更稳妥 - double 必须按
std::numeric_limits<double>::max_digits10 + 2</double>（即 17 + 2 = 19）起步，但实际极小值如DBL_MIN可能写入 24 字符以上，保守起见直接用buf[32] - 别用
sizeof("123")或硬编码[16]—— 它不含负号、不兼容科学计数法、也不防1e-100这种长格式 -
std::to_chars不检查last是否够用，只靠返回的ec == std::errc::value_too_large提示；忽略它等于默认接受截断
std::to_chars_result::ptr 不是字符串结尾，而是写入结束的下一个位置
错误写法：std::string s(buf) 或 printf("%s", buf) —— 因为 buf 里没有 '\0'，且 ptr 指向的是有效数据之后的位置，不是末尾。
- 要构造
std::string：用std::string(buf, result.ptr - buf)，显式传长度，不依赖'\0' - 要喂给 C 接口（如
write()、send()）：直接用buf起始地址和result.ptr - buf长度，无需加'\0' - 要转成
std::string_view：用std::string_view(buf, result.ptr - buf)，零拷贝且安全 - 非要当 C 字符串用？只在确认
result.ec == std::errc{}后，执行*result.ptr = '\0'；别写buf[31] = '\0'，那可能覆盖有效数据
浮点数用 std::to_chars 输出固定小数位？做不到
常见错误现象：UI 显示 0.1 变成 "0.10000000000000001"，日志里金额对不齐，金融计算校验失败。
立即学习“C++免费学习笔记（深入）”；
-
std::to_chars对float/double仅支持std::chars_format::general（默认）、fixed、scientific三种格式，但**不接受精度参数**；C++17 中precision参数未被任何主流标准库实现 -
std::chars_format::fixed只强制格式，不控位数——0.1在不同平台可能输出"0.1"或"0.10000000000000001"，取决于 round-trip 最短表示逻辑 - 想保留两位小数？必须换工具：
std::sprintf(buf, "%.2f", x)（注意线程安全）、fmt::format("{:.2f}", x)，或自己做 IEEE-754 舍入+拼接 - 若只要 round-trip 安全（转回浮点数不变），确保 buffer ≥ 19 字节，并验证
std::from_chars(to_chars_result) == original
真正拖慢性能的，往往不是 std::to_chars 本身
高频调用场景下，瓶颈常藏在缓冲区分配、std::string 构造、或反复栈拷贝里。
- 每次调用都
char buf[32]？栈上重复分配 + 缓冲区复用失败 → 比函数调用开销还重 - 用
std::string(buf, result.ptr - buf)是 OK 的，但若后续还要.c_str()或传给 C 接口，不如直接消费std::string_view - 避免
std::to_chars→std::string→std::string::data()这种链式转换；一次写入、多次视图消费更高效 - 跨线程使用？缓冲区可线程局部存储（
thread_local char buf[32]），比每次 new/delete 或锁保护更快
最易被忽略的一点：浮点转换行为在不同标准库实现间尚未完全一致，尤其对 NaN、Inf 和极小值的格式选择；关键业务中，必须用真实数据在目标编译器（GCC/Clang/MSVC）上实测输出长度与格式，不能只看标准文档里的“至少”要求。
