Windows 碎片整理 API 在 C# 中不可直接调用
不能。C# 本身没有内置函数能直接触发磁盘碎片整理，也没有公开、稳定、受支持的 API 可查询当前碎片率或整理进度。微软从 Windows 8 开始将
defrag.exe转为系统后台服务（
Defrag服务），且明确不鼓励第三方程序直接干预——所有 UI 和调度逻辑由
dfrgui.exe和
OptimizeDrives服务控制。
常见错误现象：有人尝试 P/Invoke
Defrag相关未公开 DLL（如
defrag.dll或旧版
winmm.dll中的函数），结果是
EntryPointNotFoundException或
AccessViolationException，尤其在 Win10/11 上几乎必崩。 Windows 10/11 默认禁用传统“碎片整理”概念，对 SSD 自动跳过，对 HDD 也只做“优化”（含 TRIM、重排等，不等于旧式碎片分析）
defrag.exe /a的输出是面向用户的文本，非结构化数据，解析极不可靠（不同系统语言、版本格式差异大） PowerShell 的
Optimize-Volume命令底层仍走同一服务，无法返回碎片百分比
能做的有限操作：调用 defrag.exe 并捕获粗略状态
唯一可行路径是 Shell 调用系统自带的
defrag.exe，但只能获取“是否正在运行”“是否成功完成”这类信号，无法读取碎片率数值。它不是查询接口，而是触发命令行工具的副作用。
使用场景：仅适用于需要“尝试触发一次优化”并等待其结束的后台维护脚本，不适用于监控或决策逻辑。
必须以管理员权限运行，否则defrag.exe直接退出并返回错误码
0x89000021（“拒绝访问”）
defrag.exe C: /O是“优化”（推荐），
/D是传统碎片整理（已弃用，Win10+ 对 SSD 无效） 检查退出码：
0= 成功；
1= 需要重启后执行；
2= 错误（如权限不足、卷不支持）；其他值参考微软文档
defrag.exe /?不要解析标准输出文本——例如
You do not have sufficient privileges...和
Fragmentation has been reduced...在不同系统区域设置下会本地化
为什么没有可靠碎片率 API？
因为 Windows 已放弃向应用暴露“碎片率”这个指标。从 NTFS 驱动层看，“碎片”本身是模糊概念：文件分散程度、MFT 碎片、空闲空间连续性、SSD 的逻辑块映射……这些维度无法用单一百分比概括。微软选择隐藏细节，只提供“优化建议”和“执行动作”两个抽象层。
性能 / 兼容性影响：
试图用 WMI 查询Win32_Volume或
Win32_DiskDrive类，拿不到碎片信息——相关属性（如
DefragAnalysis）在 Win8+ 已被移除或始终返回 null 第三方工具（如 Sysinternals Contig）用驱动级手段扫描，但需安装内核驱动，C# 无法安全调用，且违反企业环境策略 即使硬解析
defrag.exe /a输出，在英文系统中也可能出现 “Current mounted files: 0% fragmented” 这类误导性描述（它指“当前加载的系统文件”，非整个卷）
替代思路：用 PowerShell + WMI 判断是否可优化
虽然拿不到碎片率，但可以确认卷是否支持并启用自动优化，这比强行查数字更实用。
示例逻辑（C# 中通过
System.Management调用）：
var query = "SELECT * FROM Win32_Volume WHERE DriveLetter = 'C:'"; // 检查 ResultProperty "DefragScheduled"（bool）、"DriveType"（3=HDD, 4=SSD）、"Capacity" > 0
关键点：
DefragScheduled表示该卷是否加入“按计划优化”（即设置里的“优化驱动器”开关）
DriveType == 3才值得考虑手动触发；
== 4（SSD）应跳过
defrag.exe，改用
fsutil behavior set disablelastaccess 1等辅助优化 注意：WMI 查询可能超时或被禁用，需加 try/catch 和 timeout 控制
事情说清了就结束。真正需要碎片率的场景极少，多数所谓“监控需求”其实只需要知道“是否该触发优化”或“上次优化是否失败”，而这两点都能绕过碎片率直接判断。
