\_snprintf 截断或乱码的根本原因是缓冲区不足且未检查返回值或补\0；应优先用snprintf（C++11起标准支持，自动补\0），并注意类型匹配、长度预估与用户输入截断。
为什么 _snprintf 总是截断或写入乱码？
根本原因不是你拼错了格式符，而是没给足缓冲区空间，或者忽略了返回值含义。_snprintf 在 Windows 上（尤其旧版 CRT）不会自动在末尾补 \0，如果实际需要字节数 ≥ 缓冲区大小，它就只写前 size - 1 字节，且不保证以 \0 结尾——这时你直接用 printf 打印，就会看到后面堆栈里的垃圾内容。
- 永远检查返回值：
_snprintf返回「本应写入的字符数（不含\0）」，若为负数或 ≥size，说明缓冲区不够 - 手动补
\0是必须动作，哪怕你刚调完_snprintf：比如buf[size - 1] = '\0'; - 别用
_snprintf(buf, sizeof(buf), ...)直接套数组名——万一buf是指针（比如函数参数），sizeof就变成指针大小（4 或 8），不是你想要的缓冲区长度
_snprintf 和 snprintf 到底该选哪个？
Windows 下用 _snprintf 是历史包袱；C++11 起标准要求支持 snprintf，它行为更可靠：只要 size > 0，一定以 \0 结尾，且返回值语义统一（负值表示编码错误）。但 VS2015 以前默认禁用 snprintf，需加宏：
#define _CRT_SECURE_NO_WARNINGS #include <cstdio> <p>char buf[256]; int ret = snprintf(buf, sizeof(buf), "x=%d, y=%.2f, s=%s", x, y, s.c_str());
- VS2015+ 默认开启
snprintf，行为和 POSIX 一致；老版本加_CRT_SECURE_NO_WARNINGS后仍可用snprintf，无需改代码逻辑 - 如果必须用
_snprintf（比如维护遗留代码），请记住：它的返回值不包含\0，而snprintf的返回值也不含\0，但snprintf会确保写满size-1后补\0 - 跨平台项目无脑用
snprintf，Linux/macOS 原生支持，Windows 新版也 OK
多个变量拼接时，怎么避免类型错配导致崩溃？
snprintf 是纯 C 函数，不检查参数类型。传 std::string 直接进去会崩，传 int64_t 用 %d 会截断——这些在编译期零提示，运行时才段错误或输出错乱。
-
std::string必须显式转：s.c_str()；std::string_view同理：sv.data() - 整型宽度敏感：32 位用
%d，64 位用%lld（Linux/macOS）或%I64d（Windows_snprintf），但snprintf统一推荐%" PRId64（需#include <inttypes.h></inttypes.h>） - 浮点数慎用
%.2f：如果值是NaN或Inf，某些 CRT 版本会返回负值并写空字符串，建议提前判断
写入文件前，要不要先算长度再分配内存？
没必要。两次调用 snprintf（第一次传 nullptr, 0 算长度，第二次再写）看似安全，但有竞态风险：中间变量被改，第二次结果就不对了；而且多一次调用，性能白丢。
立即学习“C++免费学习笔记（深入）”；
- 更稳的做法：预估最大长度（比如所有字符串变量加起来最长多少、数字最多几位），分配稍大缓冲区（如 512 字节），再用
snprintf一次写入 - 真不确定上限？用
std::string+std::to_string拼接，虽然慢点但绝对安全；或用fmt::format（现代 C++ 推荐，类型安全、无缓冲区溢出） - 如果必须用
snprintf且变量极多，把最宽的几个变量长度加总，再加 20% 余量，比硬算靠谱
真正容易被忽略的是：哪怕你用了 snprintf，如果格式串里混入了用户输入的字符串（比如日志中的路径名），而没做长度限制（如 %.100s），缓冲区仍可能被撑爆——这种动态内容必须加截断保护。
