Environment.GetFolderPath 返回空或报错主因是传入非法 SpecialFolder 枚举值；应仅用文档支持的值（如大小写严格的 SpecialFolder.MyDocuments），并校验返回值非空且路径存在。
Environment.GetFolderPath 为什么返回空或报错
直接调用 Environment.GetFolderPath 却拿到空字符串或抛出 ArgumentException，通常是因为传了非法的 Environment.SpecialFolder 枚举值——比如手误写成 SpecialFolder.MyDocuments 拼错，或用了已废弃/不存在的值（如 SpecialFolder.CommonDocuments 在某些旧系统上不可用）。
实操建议：
- 只使用官方文档明确支持的枚举值，
SpecialFolder.MyDocuments是安全的，但注意大小写必须完全匹配 - 调用前加 null 检查：结果可能为
null（例如用户配置损坏、权限不足、漫游配置文件未加载），不能直接拼接路径 - 不要依赖返回路径一定存在，
Directory.Exists应该在使用前验证
C# 获取 MyDocuments 路径的可靠写法
最稳妥的方式是组合 Environment.GetFolderPath 和 Path.Combine，避免硬编码或字符串拼接。Windows 上它返回的是当前用户的实际文档目录（如 C:\Users\Alice\Documents），不是注册表或环境变量里“可能被改过”的值。
示例：
string docsPath = Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments);
if (!string.IsNullOrEmpty(docsPath) && Directory.Exists(docsPath))
{
string myFile = Path.Combine(docsPath, "config.json");
// 安全使用
}
注意点：
-
Environment.SpecialFolder.MyDocuments在 .NET Core 3.0+ 和 .NET 5+ 中跨平台行为一致，Linux/macOS 返回空（不抛异常），需自行 fallback - 如果目标是“应用专属子目录”，别忘了用
Path.Combine(docsPath, "MyApp")，而不是直接往docsPath写
为什么 ApplicationData 不等于 MyDocuments
新手常混淆 SpecialFolder.ApplicationData 和 SpecialFolder.MyDocuments：前者是隐藏的应用配置目录（%APPDATA%），后者才是用户可见的“文档”位置。用户手动保存文件时默认进这里，双击打开也指向它。
关键区别：
-
ApplicationData：适合存配置、缓存、数据库，路径带Roaming或Local，用户不可见，且可能被组策略重定向 -
MyDocuments：用户预期存放自己创建的文件，路径稳定、可读写、有明确语义，但受 UAC 或 OneDrive 重定向影响（见下条） - OneDrive 启用后，
MyDocuments可能被重定向到OneDrive\Documents，这是正常行为，GetFolderPath会自动返回重定向后的路径
OneDrive 重定向和权限问题怎么处理
当用户开启 OneDrive 文档备份，MyDocuments 实际指向 OneDrive 下的子目录。这时你写入文件不会失败，但可能触发同步延迟、冲突或被杀毒软件拦截（尤其写大文件时）。
应对方式：
- 不要假设写入立刻完成，
File.WriteAllText成功 ≠ 文件已落盘或同步就绪 - 避免在
MyDocuments中频繁写小文件（如日志轮转），容易触发 OneDrive 频繁扫描，拖慢性能 - 若需确保本地磁盘操作，可 fallback 到
Environment.GetFolderPath(SpecialFolder.LocalApplicationData)，但要向用户说明“此文件不随 OneDrive 同步”
真正麻烦的是权限：某些企业环境禁用文档库重定向，或用户以受限账户登录，GetFolderPath 返回路径却 Directory.CreateDirectory 失败——这时候得捕获 UnauthorizedAccessException，并提示用户手动选择位置。
