DriveInfo 是 Windows 平台下获取驱动器剩余空间最直接的方式，通过 AvailableFreeSpace 获取当前用户可写入的可用空间，需先检查 IsReady 并捕获异常以确保健壮性。
用 DriveInfo 获取驱动器剩余空间最直接
Windows 平台下，DriveInfo 是 .NET 提供的标准类，不需要 P/Invoke 或第三方库就能拿到总空间、可用空间、根目录等基础信息。它会自动识别本地磁盘、网络驱动器（部分支持）、U 盘等，但对未格式化或无权限访问的驱动器会抛异常。
关键点：可用空间不等于“剩余空间”——AvailableFreeSpace 是当前用户有权限写入的部分，而 TotalFreeSpace 是驱动器上所有未分配空间（含系统保留区），一般推荐用前者。
-
DriveInfo.GetDrives()返回所有逻辑驱动器数组，需遍历判断IsReady再读属性，否则访问未就绪驱动器（如光驱空仓）会报IOException - 获取 C 盘剩余空间示例：
var drive = new DriveInfo("C:\"); if (drive.IsReady) Console.WriteLine($"剩余空间：{drive.AvailableFreeSpace / (1024.0 * 1024.0):F2} MB"); - 注意路径末尾反斜杠不是必须的，
"C:"和"C:\"效果一致
GetDiskFreeSpaceEx 在需要精确控制或跨平台时才考虑
如果项目跑在 .NET Core/.NET 5+ 且部署到 Linux/macOS，DriveInfo 仍可用，但行为受限（比如 Linux 上只返回挂载点信息，不区分物理磁盘）。此时若需更底层数据（如文件系统块大小、可用 inode 数），就得调用原生 API —— Windows 下是 GetDiskFreeSpaceEx，Linux/macOS 下用 statvfs。
纯 C# 场景下，除非你遇到 DriveInfo 返回值异常（例如某些加密卷、BitLocker 挂载后显示 0 空间），否则没必要绕路。它要处理指针、DllImport、平台条件编译，出错概率更高。
- Windows 调用
GetDiskFreeSpaceEx需引用kernel32.dll，且参数是long*类型，容易因平台位数（x86/x64）导致截断 - 常见错误：传入路径不带冒号反斜杠（如
"C"），API 返回失败；正确应为"C:\"或"C:" - .NET 6+ 推荐优先用
OperatingSystem.IsWindows()做运行时判断，而不是编译时#if WINDOWS
避免把 TotalSize 和 AvailableFreeSpace 当成“已用空间”直接相减
看起来 TotalSize - AvailableFreeSpace 就是已用空间，但实际可能不准。因为 AvailableFreeSpace 扣除了系统保留空间（如 Windows 的 10% 磁盘保护区）、配额限制、甚至当前用户无权访问的文件所占空间。
真正反映“用户可见已用空间”的，其实是 TotalSize - TotalFreeSpace。不过这个值也未必和资源管理器显示完全一致——Explorer 会排除回收站、系统还原点等隐藏占用，而 DriveInfo 不做这类过滤。
- 资源管理器显示的“已用”≈
TotalSize - TotalFreeSpace，但会动态减去回收站内容（若启用） - 想匹配 Explorer 显示，得额外调用
SHQueryRecycleBin（Windows）或解析.Trash-xxx目录（Linux） - 简单监控场景，直接用
AvailableFreeSpace判断是否低于阈值（如 500MB）更实用，比纠结“已用多少”更有意义
权限不足时 DriveInfo 会静默失败或抛异常
某些路径（如被 BitLocker 加密但未解锁的驱动器、NTFS 权限设为拒绝当前用户的卷）会导致 IsReady 返回 false，或者读 AvailableFreeSpace 时抛 UnauthorizedAccessException。这不是 bug，而是 .NET 尊重系统安全策略。
生产环境建议加 try/catch，并降级处理：比如跳过该驱动器、记录日志、或用默认值（0）代替。
- 不要依赖
DriveInfo.RootDirectory.Exists判断可访问性——它可能返回true，但后续读空间仍失败 - 最佳实践是先检查
IsReady，再在 try 块里读AvailableFreeSpace，捕获IOException和UnauthorizedAccessException - 服务程序（如 Windows Service）默认以 LocalSystem 运行，对用户目录无访问权，此时查 D:Usersxxx 下的映射驱动器大概率失败
实际使用中，95% 的需求用 DriveInfo 加基础异常处理就够了。真正麻烦的从来不是“怎么取数值”，而是“为什么这个值和资源管理器差几百 MB”——那通常意味着你得深挖回收站、卷影副本、系统保护这些隐藏玩家。
