优先使用gettemppathw，传入wchar_t*缓冲区并动态获取长度，返回路径总以反斜杠结尾，需验证可写性与磁盘空间。
GetTempPathA 和 GetTempPathW 用哪个？
Windows API 的 GetTempPath 是宏，实际调用取决于是否定义了 UNICODE。项目默认多字节时走 GetTempPathA，宽字符则走 GetTempPathW。不手动指定编码容易在跨编译配置时返回乱码或截断——尤其路径含中文时，GetTempPathA 会用系统 ANSI 代码页转换，而现代 Windows 默认临时目录（如 C:UsersXXXAppDataLocalTemp）常含 Unicode 字符，转换失败就只返回前几个字节。
- 统一用
GetTempPathW，传入wchar_t*缓冲区，避免编码陷阱 - 缓冲区大小至少设为
MAX_PATH（260），但更稳妥是32767（Windows 路径最大长度） - 调用前确保目标缓冲区已初始化，否则可能读到脏内存导致越界
缓冲区大小填多少才安全？
GetTempPath 第二个参数是缓冲区长度，单位是 wchar_t（宽字符）个数，不是字节数。填 260 看似够用，但 Windows 10+ 支持长路径且临时目录可能嵌套很深（比如 VS 编译器生成的临时子目录），实际返回值可能超限，函数返回 0 并设置 ERROR_INSUFFICIENT_BUFFER。
- 先调用一次
GetTempPathW(0, nullptr)获取所需长度（含结尾L' '） - 按返回值动态分配
wchar_t数组，再调用第二次 - 别直接用
std::wstring(MAX_PATH, L' ')初始化后传 data()——必须保证末尾有空字符，否则 API 可能越界读
返回路径末尾带不带反斜杠？
GetTempPathW 返回的路径**总是以反斜杠结尾**（如 L"C:UsersXXXAppDataLocalTemp"）。这和 GetEnvironmentVariable(L"TEMP") 不同，后者不保证结尾有分隔符。硬拼接文件名时若没注意这点，会得到 ...Tempmy.log（正确）或 ...Tempmy.log（错误）。
- 直接拼接时用
path + L"myfile.txt"即可，不用额外加L"\" - 若后续要删掉末尾分隔符（比如取父目录），用
path.pop_back()前先检查!path.empty() && path.back() == L'\' - 不要依赖
SHGetKnownFolderPath替代——它返回的是CSIDL_LOCAL_APPDATA下的子路径，和系统临时目录语义不同
为什么 GetTempPath 有时返回空字符串？
常见原因是传入缓冲区太小且未检查返回值。另一个隐蔽问题是进程权限：某些沙盒环境（如 MSIX 包、Windows Store 应用）会重定向临时目录，但若注册表 HKEY_CURRENT_USEREnvironmentTemp 被清空或指向无效路径，GetTempPath 会 fallback 到 GetSystemDirectory，而该目录无写权限，导致后续 CreateFile 失败。此时返回值非空，但路径不可写。
- 调用后立即用
GetLastError()检查是否为ERROR_SUCCESS - 用
PathFileExists和GetFileAttributes验证路径是否存在且可写 - 更健壮的做法是 fallback 到
GetEnvironmentVariableW(L"TEMP", ...)或L"."（当前目录），但需自行处理并发写冲突
临时目录不是“一定可用”的黑箱，尤其在容器、终端服务或低权限账户下，路径存在 ≠ 可写 ≠ 有空间。每次创建临时文件前，最好先用 GetDiskFreeSpaceEx 粗略判断剩余空间。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
