windows下获取文档目录应优先用shgetfolderpatha(csidl_mydocuments)或shgetknownfolderpath(folderid_documents)，前者兼容xp至win11，后者需com初始化并释放内存；跨平台不可硬拼环境变量，须依赖系统api或标准路径规范。
Windows下用SHGetFolderPath获取文档目录
在Windows平台，SHGetFolderPath 是最稳定、兼容性最好的方式（支持XP到Win11），它不依赖用户环境变量或注册表手动拼接路径，避免了权限和重定向问题。
常见错误是传入错误的CSIDL值：CSIDL_MYDOCUMENTS 返回的是“我的文档”（如 C:UsersNameDocuments），而 CSIDL_PERSONAL 实际上是它的别名，二者等价；但千万别用 CSIDL_DESKTOP 或 CSIDL_PROFILE，它们返回完全不同的路径。
- 需链接
shell32.lib，否则链接失败报LNK2019: unresolved external symbol SHGetFolderPath - 第二个参数必须是
NULL（表示当前用户），传入其他句柄可能导致返回系统目录而非用户目录 - 缓冲区至少分配
MAX_PATH字节（260），否则可能截断路径（尤其启用长路径支持后更需注意）
#include <shlobj.h>
#include <windows.h>
char path[MAX_PATH] = {0};
if (SUCCEEDED(SHGetFolderPathA(NULL, CSIDL_MYDOCUMENTS, NULL, 0, path))) {
// path 现在包含类似 "C:\Users\Alice\Documents" 的字符串
}</windows.h></shlobj.h>
Windows下用SHGetKnownFolderPath替代旧API
SHGetKnownFolderPath 是Vista之后推荐的新接口，支持更多语义化路径（比如区分“文档”和“文档/子文件夹”），且返回的是宽字符路径，天然支持Unicode用户名和长路径。
关键点在于使用 FOLDERID_Documents —— 不是字符串，而是预定义的 KNOWNFOLDERID 常量。如果误传字符串字面量（如 L"Documents"），会直接返回 E_INVALIDARG。
- 必须用
CoInitialize(NULL)初始化COM，否则返回CO_E_NOTINITIALIZED - 返回的
pwchPath需用CoTaskMemFree释放，不能用free或delete[] - 若目标系统可能低于Vista（如仍需XP支持），不能只依赖此API，得回退到
SHGetFolderPath
#include <shlobj.h>
#include <combaseapi.h>
PWSTR pwchPath = nullptr;
if (SUCCEEDED(SHGetKnownFolderPath(FOLDERID_Documents, 0, NULL, &pwchPath))) {
// 使用 pwchPath，例如 WideCharToMultiByte 转为UTF8
CoTaskMemFree(pwchPath);
}</combaseapi.h></shlobj.h>
跨平台方案：std::filesystem + 环境变量（慎用）
Linux/macOS没有统一“文档目录”概念，通常靠 $HOME + 子路径模拟，比如 $HOME/Documents。但这是惯例，不是强制标准——GNOME用 XDG_DOCUMENTS_DIR，KDE可能改写该变量，甚至有些发行版根本不创建 Documents 目录。
直接读 getenv("HOME") 再拼接容易出错：环境变量可能为空、路径未标准化（含 ~ 或多余斜杠）、权限不足导致后续创建失败。
- 务必用
std::filesystem::path拼接，自动处理分隔符差异（/vs\） - 检查目录是否存在并可写：
std::filesystem::is_directory(p) && std::filesystem::permissions(p) & std::filesystem::perms::owner_write - 不要假设
$XDG_CONFIG_HOME或$XDG_DATA_HOME和文档目录有关——它们管配置和数据，不等于文档
为什么不能只用 getenv("USERPROFILE") + "\Documents"
USERPROFILE 在Windows上确实指向用户根目录（如 C:UsersAlice），但硬拼 "\Documents" 有三个实际风险：
- 某些企业域环境禁用“文档”库重定向，实际路径可能是
D:WorkAliceDocs，此时拼接结果根本不存在 - OneDrive或SharePoint同步会把文档目录移到云路径，
USERPROFILE下的Documents只是符号链接，std::filesystem::exists可能返回false（取决于符号链接解析策略） - UWP沙盒应用或以不同用户权限运行时，
USERPROFILE可能指向系统配置目录而非当前交互用户目录
真正可靠的路径必须由系统Shell API返回，而不是靠字符串拼接猜出来——哪怕看起来“应该对”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
