最安全通用做法是先用std::to_String转std::string再调用c_str()；需保存string对象避免临时对象析构导致悬空指针；to_string不支持进制/填充/locale；snprintf更安全适用于c api；ostringstream适合复杂拼接与格式控制。
用 std::to_string 转成 std::string 再取 c_str()
这是最安全、最推荐的通用做法。c++11 起 std::to_string 支持 int、long、double 等基本类型，返回 std::string，再调用 c_str() 得到以 结尾的 const char*。
常见错误是直接对临时 std::string 调用 c_str() 后长期持有指针：
- ❌
const char* s = std::to_string(42).c_str(); /* s 指向已销毁内存 */ - ✅ 先存住
std::string对象：std::string s = std::to_string(42); const char* c = s.c_str();
注意：std::to_string 不支持自定义进制或填充，只输出十进制无符号/有符号形式，且不处理 locale（比如千位分隔符）。
用 sprintf / snprintf 写入固定大小缓冲区
需要 C 风格字符串且明确控制内存布局时（比如传给旧 C API），用 snprintf 更安全——它会截断并保证结尾 ；sprintf 有缓冲区溢出风险，应避免。
立即学习“C++免费学习笔记（深入）”；
典型场景：构造日志前缀、拼接文件名、填入结构体字段。
- 分配足够大的栈缓冲区，比如
char buf[32];（32 足够放 64 位整数 + 符号 + ） - 用
snprintf(buf, sizeof(buf), "%d", n);，返回值可检查是否截断（负值=编码错误，≥sizeof(buf)=缓冲区不够） - 之后
buf就是有效的 C 字符串，生命周期由你控制
性能上比 std::to_string 略高（无动态分配），但需手动管理缓冲区大小，容易因 sizeof 错误或格式符不匹配导致未定义行为。
std::ostringstream 适合多段拼接或格式复杂的情况
当不只是转一个整数，而是要混排数字、字符串、变量，或需要控制精度、进制、填充时，std::ostringstream 更灵活。
- 支持流操作符：
oss - 结果仍需通过
oss.str().c_str()获取 C 字符串，所以同样要注意std::string生命周期 - 比
snprintf开销大（动态分配 + 流状态管理），但可读性和扩展性更好
别写 oss ——这又掉进临时对象陷阱了。必须把 <code>std::string 保存出来。
绝对不要用 itoa
itoa 不是标准 C 或 C++ 函数，是某些 libc（如 MSVC、glibc 扩展）提供的非便携接口。在 clang++ 或跨平台构建时大概率报错：use of undeclared identifier 'itoa'。
即使编译通过，它也不接受缓冲区大小参数，无法防止溢出；还要求调用者自己分配并确保足够空间，错误率高。
替代方案明确：Windows 下可用 _itoa_s（带长度检查），但仍是扩展函数；更稳妥的做法就是前面三条里的任一标准方案。
真正麻烦的地方不在“怎么转”，而在于谁拥有那块内存、指针能活多久——漏掉这一层，程序可能跑几天才崩。