应优先使用 snprintf 并检查返回值，或采用 C++20 std::format（限字面量格式串）；传统 sprintf 易致缓冲区溢出，std::ostringstream 安全但冗长。
用 sprintf 格式化字符串时，缓冲区溢出是默认行为
传统 C 风格依赖 sprintf 或 snprintf，但 sprintf 不检查目标缓冲区大小，写超就踩内存——这不是 bug，是标准定义。实际项目中只要没严格算好长度（包括末尾 \0），就可能触发未定义行为。
必须改用 snprintf，并检查返回值：
char buf[64];
int n = snprintf(buf, sizeof(buf), "id=%d, name=%s", 123, "alice");
if (n < 0 || n >= (int)sizeof(buf)) {
// 截断或编码错误，buf 可能不完整
}
-
snprintf返回「本应写入的字符数」（不含\0），不是实际写入数 - 若返回值 ≥
sizeof(buf)，说明内容被截断 -
sizeof(buf)必须是字面量数组大小；对指针传参无效
std::format（C++20）不支持运行时格式串，且编译器支持仍不统一
std::format 是目前最接近“安全 + 简洁”的现代方案，但它要求格式字符串必须是字面量（const char[]），不能是 std::string 或运行时拼接结果。否则编译失败：
std::string fmt = "x={}";
std::format(fmt, 42); // ❌ 编译错误：非字面量格式串
std::format("x={}", 42); // ✅ OK
另外，MSVC 2022 17.5+、GCC 13+、Clang 15+ 才提供完整支持；旧版本只能靠第三方库（如 {fmt}）模拟。
立即学习“C++免费学习笔记（深入）”；
- 启用需编译选项：
-std=c++20（GCC/Clang），MSVC 默认开启 - 不支持
%d这类 C 风格说明符，只认{}和{:x}等 Python-like 语法 - 性能优于
std::ostringstream，但比snprintf略慢（有类型擦除开销）
std::ostringstream 安全但冗长，适合多段拼接场景
它不依赖格式串，无缓冲区风险，也无需 C++20，是兼容性最强的现代方案。但写法啰嗦，尤其单次简单格式化时：
std::ostringstream oss; oss << "id=" << 123 << ", name=" << "alice"; std::string s = oss.str();
常见误用是反复创建 std::ostringstream 对象却忽略清空状态位（如 failbit），导致后续
- 多次复用时，调用
oss.str("")清空内容，再调用oss.clear()重置状态标志 - 避免在循环中隐式构造临时
std::ostringstream—— 构造/析构开销明显 - 若只需转数字，
std::to_string比ostringstream更轻量（但不支持进制、填充等）
第三方 {fmt} 库几乎解决了所有痛点，但引入依赖需权衡
{fmt} 是 std::format 的事实参考实现，API 兼容、功能更全（支持运行时格式串、自定义类型格式化），且 C++11 起可用。典型用法：
#includestd::string s = fmt::format("id={}, name={:s}", 123, "alice");
它还提供 fmt::print、fmt::format_to（写入 buffer）、fmt::memory_buffer（零拷贝）等扩展能力。
- 头文件仅需
fmt/core.h，无运行时依赖，静态链接友好 - 格式串仍推荐字面量以启用编译期检查；运行时格式串会降级为运行时解析（略慢且无类型安全）
- 和
std::format一样不接受%d，但支持{:d}、{:08x}等丰富说明符
真正难处理的是混合场景：比如日志系统既要支持用户配置的运行时格式模板，又要保证类型安全——这时候不能只靠语言原生工具，得配合模板特化或 DSL 解析逻辑。
