DriveInfo.GetDrives() 返回空数组主因是权限不足或运行于受限环境（如容器、沙盒、UWP）；应先用系统命令验证驱动器存在，再逐个构造 DriveInfo 实例并捕获 IOException，避免异常中断枚举。
DriveInfo.GetDrives() 返回空数组怎么办
常见错误是程序没权限读取系统驱动器，或者在容器、沙盒环境里运行。Windows 下某些受限账户（比如服务账户）可能无法枚举所有盘符；.NET Core/.NET 5+ 在 Linux/macOS 上调用 DriveInfo.GetDrives() 只返回挂载点，不保证包含 / 或 /home 等逻辑卷。
- 先检查是否真有可访问的驱动器：用
cmd运行fsutil fsinfo drives（Windows）或df -h（Linux/macOS）对比 - 避免在未捕获异常时直接遍历：加
try/catch (IOException)，部分驱动器（如光驱、未就绪的 USB 盘）会抛出异常中断整个枚举 - .NET 6+ 推荐改用
System.IO.DriveInfo.GetDrives()而非反射或 WMI，它更轻量且跨平台行为一致
DriveInfo.AvailableFreeSpace 和 TotalFreeSpace 的区别
AvailableFreeSpace 是当前用户可用的剩余空间（受磁盘配额、ACL 限制），TotalFreeSpace 是驱动器总空闲字节数（忽略用户配额）。多数场景该用前者——比如你要提示“用户剩余空间不足”，用后者会误判。
- NTFS 卷上若启用了配额，
AvailableFreeSpace可能远小于TotalFreeSpace - UWP 或 .NET MAUI 应用默认无权访问
AvailableFreeSpace，只能拿到TotalFreeSpace，需声明removableStorage权限并手动请求 - 值为 -1 表示无法获取（如网络驱动器、CD-ROM），务必判空再计算百分比
获取剩余空间时抛出 UnauthorizedAccessException
不是代码写错了，而是进程没权限访问那个驱动器的根目录元数据。典型于 Windows 上的系统保留分区、BitLocker 加密卷未解锁、或挂载了需要凭据的网络路径。
- 不要全局 try/catch 吞掉异常——这会让
D:盘失败后跳过，却误以为只有C:一个盘 - 逐个构造
new DriveInfo("D:")再调属性，比先GetDrives()再遍历更可控 - 对已知受限路径（如
\servershare），直接跳过或用FileSystemRights.ReadPermissions提前探测
为什么在 Docker 容器里 DriveInfo 显示不全
Docker 默认只挂载指定路径（如 -v /data:/app/data），DriveInfo.GetDrives() 在容器内看到的是宿主机的文件系统视图，但受限于挂载方式和命名空间，通常只显示 / 对应的 rootfs，其他盘符（如 Windows 的 D:）根本不可见。
- Linux 容器中别指望看到
C:或D:——它们不存在，DriveInfo会返回空或仅/ - Windows 容器若用
process隔离模式，可能看到宿主机盘符；但hyperv模式下仍被隔离 - 真正要查宿主机磁盘？得走宿主机 API（如 Windows 上调用 WMI 的
Win32_Volume），容器内代码做不到
DriveInfo 看似简单，但跨平台、权限、容器化这些上下文一叠加，AvailableFreeSpace 就可能变成 -1、0 或完全不出现。别假设它总能返回合理值，每次访问前都得按实际环境做兜底判断。
