std::format_to不能直接写入std::string缓冲区，因其要求可写输出迭代器，而std::string::begin()只读且data()未预分配时写入会越界；正确方式是用std::back_inserter或预分配后配合std::format_to_n。
std::format_to 为什么不能直接写到 std::string 缓冲区
因为 std::format_to 要求一个输出迭代器，而 std::string 的 begin()/end() 是只读的（C++20 中 std::string::data() 也不保证可写，且 size 不足时会越界）。直接传 s.begin() 通常编译失败或运行时崩溃。
正确做法是用 std::back_inserter 或预分配空间后用 s.data() + std::format_to_n：
-
std::format_to(std::back_inserter(s), "{}:{}", "key", 42)—— 安全但有重复内存重分配开销 - 更高效：先
s.resize(n)预估长度，再用std::format_to_n(s.data(), n, ...)，最后s.resize(result.out - s.data()) - 注意：
std::format_to_n返回的是std::format_to_n_result，其中out是实际写入结束位置，不是长度
std::format_to_n 的典型高效用法（避免 realloc）
当拼接内容长度可大致预估（比如日志前缀固定 + 数字最多 10 位），用 std::format_to_n + 手动 resize 是目前 C++20 中最省内存、最少拷贝的方式。
示例：
立即学习“C++免费学习笔记（深入）”；
std::string s;
s.resize(64); // 预分配足够空间
auto result = std::format_to_n(s.data(), s.size(), "id={:08x}, cost={}", id, ns);
s.resize(result.out - s.data()); // 截断到真实长度
- 如果预估过小，
result.out == s.data() + s.size()表示缓冲区不足，此时需重试（增大 size 后再调） - 不要用
s.c_str()传给std::format_to_n——c_str()返回 const 指针，编译不过 -
s.data()在 C++17+ 是可写的（只要 string 非 const），但前提是已调用resize()或reserve()确保容量足够
比 std::format_to 更快的场景：用 std::string::append + to_chars
纯数字拼接（如整数、浮点数转字符串再连接）时，std::format 开销明显高于手动 to_chars + append。尤其在高频循环中，差异可达 2–5 倍。
-
std::to_chars写入char*缓冲区是无异常、无内存分配、无 locale 依赖的 - 配合
std::string::append可复用同一缓冲区，例如：s.append(buf, end_ptr) - 整数：用
std::to_chars(buf, buf + sizeof(buf), val) - 浮点数若精度可控（如仅需 6 位小数），也可用
std::to_chars（C++17 起支持，但部分 libc++ 实现不完整，建议实测）
兼容性与编译开关要注意什么
std::format 系列在 GCC 13/Clang 15+ 默认启用，但 MSVC 从 19.32（VS 2022 17.2）才开始支持，且需 /std:c++20 或更高；GCC 还需链接 -lstdc++fs（部分旧版本）。
- 检查是否可用：
#ifdef __cpp_lib_format，否则退回到std::ostringstream或absl::StrCat - Release 模式下
std::format_to_n性能优势才明显；Debug 下迭代器调试开销可能掩盖差异 - 第三方替代：
fmt::format_to（fmt库）接口更友好，性能接近原生，且 C++17 就可用，很多项目实际用它代替标准库
预分配和 to_chars 这类优化，只有在热点路径（比如每秒万级拼接）才值得投入——多数业务代码用 std::format 已足够清晰且够快。
