std::to_chars和std::from_chars不分配内存，因直接操作用户缓冲区、无new/malloc、不写入\0、无locale依赖、无格式字符串解析。
std::to_chars 和 std::from_chars 为什么不用内存分配？
因为它们不依赖 std::string 或内部堆分配，而是直接操作用户提供的缓冲区。比如 std::to_chars 只接受 char* 起始和结束指针，全程无 new、无 malloc、无隐式扩容——而 sprintf 内部可能要多次估算长度、重试写入，sscanf 则常需复制子串或构造临时对象解析。
常见错误现象：std::to_chars(buf, buf + size, 12345) 返回的 std::to_chars_result 中 ptr 若超出 buf + size，说明缓冲区太小，但不会崩溃；而 sprintf 缓冲区溢出是未定义行为，容易被误用成“刚好够用”，实则埋雷。
- 缓冲区大小必须手动计算：整数转字符串最坏情况是
std::numeric_limits<int>::digits10 + 2</int>（含负号和结尾 \0） -
std::to_chars不写入终止符\0，std::from_chars也不要求输入以 \0 结尾——它只读到首个非数字字符为止 - 没有 locale 依赖，不查表、不走格式化字符串解析逻辑，路径极短
格式化逻辑被彻底剥离，没有 printf 风格的解析开销
sprintf 每次调用都要扫描格式字符串（如 "%d %x %.2f"），跳过空格、识别 %、匹配修饰符、分派类型处理函数……这部分开销在高频小数据转换中占比极高。而 std::to_chars 是模板特化函数，编译期就确定了转换路径：整数 → 十进制 ASCII 字符串，仅做除法/取模 + 查表（小范围甚至用位运算+查表），无任何运行时分支解析。
使用场景对比：日志系统每秒序列化百万个计数器值，用 sprintf(buf, "%d", n) 会卡在格式字符串解析和符号处理上；换成 std::to_chars(buf, buf + 32, n)，热点函数可退化为几十条汇编指令。
立即学习“C++免费学习笔记（深入）”；
-
std::to_chars支持的类型有限（int,long long,float,double等），不支持自定义格式（如前导零、千位分隔符） - 不支持宽度填充、对齐、进制切换（
%x/%o）——这些功能得自己实现或换回sprintf -
std::from_chars对浮点数的解析精度和边界处理（如"inf","nan"）严格遵循 IEEE 754，但比sscanf少一层字符串 tokenization
避免了 IO 流与 locale 的间接层
std::stringstream 或带 locale 的 std::to_string 会触发 facet 查找、facet 虚函数调用、数字分组符插入等——哪怕你只是想把 42 变成 "42"。而 std::to_chars 完全绕过 iostream 和 locale，连 std::locale::global() 的设置都不影响它。
性能差异典型值（x86-64，Clang 16 -O2）：
转换 int → 字符串，std::to_chars 比 sprintf 快 2.5×，比 std::to_string 快 4×；std::from_chars 解析整数比 std::stoi 快 3×，比 sscanf 快 1.8×。
- Windows 上
_sprintf_s有额外安全检查开销，差距更明显 - ARM64 下，
std::to_chars对int64_t常用优化路径（如 10 进制查表）比通用除法快一个数量级 - 注意：glibc 2.28+、MSVC 2019 16.8+、libstdc++ 11 才完整支持浮点数的
std::to_chars；旧版本对float/double可能回退到慢路径
实际用起来要注意哪些硬约束？
它快，但不是万能替代品。最大陷阱是「缓冲区大小算错」和「忽略返回值中的错误码」。
char buf[32];
auto [ptr, ec] = std::to_chars(buf, buf + sizeof(buf), 123456789012345LL);
if (ec == std::errc::value_too_large) {
// 缓冲区不够！需要至少 ptr - buf + 1 字节（+1 是为了放 \0，如果后续要当 C 字符串用）
}
// 注意：ptr 指向写入末尾，不包含 \0；buf 本身未初始化为 0
- 整数转换必须预留足够空间，否则
ec == std::errc::value_too_large，但不会自动扩容 - 浮点数转换结果长度不可预测（科学计数法 or 小数点后位数），建议用
std::chars_format::fixed或std::chars_format::general显式控制 -
std::from_chars解析失败时ec可能是std::errc::invalid_argument（无有效数字）或std::errc::result_out_of_range（溢出），必须检查，不能只看ptr是否移动 - 没有异常抛出机制，所有错误都通过
ec返回——这点和strtol类似，但比std::stoi更底层、更可控
缓冲区大小、错误码检查、无终止符、无 locale 干预——这四点漏掉任一，就可能把性能优势抵消成 bug。它不是“更好用的 sprintf”，而是“更接近汇编语义的字符串编码原语”。
