std::to_string适合简单场景但有隐含开销；fmt::to_string更快且无格式解析；极端性能场景应优先用std::to_chars避免分配；关键在于是否真需std::string对象。
std::to_string 适合简单场景，但有隐含开销
std::to_string 是 C++11 引入的最直接方式，调用简洁：
std::string s = std::to_string(42);但它内部依赖
std::sprintf（或等效实现）走格式化路径，会进行内存分配、缓冲区管理、符号/进制处理等通用逻辑。对高频调用（如日志循环、大量数值序列化）会产生可观的堆分配和字符串拷贝开销。尤其当目标字符串长度可预估（如 int 最多 11 字符）时，这种“安全但保守”的设计反而拖慢性能。
fmt::format 比 to_string 快，但注意默认构造开销
使用 fmt::format（如 fmt::format("{}", 42)）通常比 std::to_string 快 2–3 倍，因为它避免了 std::string 的多次重分配，并做了更激进的栈缓冲优化。但要注意：
fmt::format("{}", x)仍需解析格式字符串；若只做纯转换，应改用更轻量的 fmt::to_string（非标准库函数，是 fmt 提供的专用接口）：std::string s = fmt::to_string(42);它跳过格式解析，直接走整数转字符串的快速路径，实测在 clang/gcc 下比
std::to_string 快 4–5 倍，且无额外依赖成本（只要已引入 fmt）。
极端性能场景下，考虑栈上缓冲 + std::to_chars
当毫秒级延迟敏感（如高频金融行情序列化、嵌入式日志），std::to_chars 是 C++17 提供的零分配方案：
char buf[12];auto [ptr, ec] = std::to_chars(buf, buf + sizeof(buf), 42);if (ec == std::errc{}) { std::string s(buf, ptr); }它不抛异常、不分配堆内存、不依赖 locale，输出严格按十进制无前导空格。但需手动管理缓冲区大小（int 用 12 字节足够）、检查错误码、再构造 std::string —— 这些步骤让代码变长，也容易漏掉 ec 判断导致未定义行为。
选型关键不是“用哪个函数”，而是“要不要 string 对象”
真正影响效率的常不是转换函数本身，而是后续是否立刻需要 std::string 实例。如果只是写入文件、网络流或日志缓冲区，可跳过 string 构造，直接用 std::to_chars 写入预分配 buffer，或用 fmt::memory_buffer 累积输出。很多性能问题源于“习惯性先转 string 再拼接”，而实际只需把数字字符写到某块连续内存里。这点比纠结 to_string 还是 fmt::to_string 更关键。
