Windows 下 C# 需以管理员权限调用 DeviceIoControl 发送 IOCTL_STORAGE_MANAGE_DATA_SET_ATTRIBUTES 命令触发 SSD TRIM，构造对齐的 DEVICE_DATA_SET_RANGE 数组并打开卷句柄（如。C:），其他方式无效。
Windows 上 C# 调用 DeviceIoControl 发送 TRIM（UNMAP）命令需要管理员权限和裸设备句柄
直接在 C# 里“通知 SSD 回收块”不是调用某个高级 API 就能完成的——.NET 没有封装 FSCTL_SET_ZERO_DATA 或 IOCTL_STORAGE_MANAGE_DATA_SET_ATTRIBUTES 这类底层存储控制。你得自己 P/Invoke DeviceIoControl，打开物理驱动器或卷句柄，构造 DEVICE_DATA_SET_RANGE 数组，再发指令。
常见错误现象：Access is denied（没管理员权限）、Invalid handle（路径错或没开 GENERIC_WRITE）、Incorrect function（目标设备不支持 UNMAP，比如某些 USB 桥接 SSD 或虚拟磁盘）。
- 必须以管理员身份运行进程，否则
CreateFile打开\.C:或\.PhysicalDrive0直接失败 - 推荐操作卷（
\.C:）而非物理驱动器，避免干扰其他分区；但需确保该卷是 NTFS/exFAT 且启用了 TRIM（fsutil behavior query disablelastaccess不影响，但fsutil behavior query disabledeletenotify应为 0） - 调用前先用
IOCTL_STORAGE_QUERY_PROPERTY查StorageAdapterProperty，确认TrimEnabled为 true，否则发了也白发
IOCTL_STORAGE_MANAGE_DATA_SET_ATTRIBUTES 是唯一可靠方式，SetEndOfFile 或 FileStream.SetLength(0) 完全无效
有人试过清空文件后调 SetEndOfFile、删文件后调 FileStream.SetLength(0)，甚至用 FileOptions.DeleteOnClose——这些对 SSD 的 GC 毫无帮助。操作系统不会仅因文件变小或删除就自动下发 UNMAP；TRIM 必须由文件系统或用户显式触发，且最终落到设备驱动层。
真正起作用的是 IOCTL_STORAGE_MANAGE_DATA_SET_ATTRIBUTES，它允许你传入一组逻辑块地址（LBA）范围，请求设备将对应区域标记为“未使用”。NTFS 在删除文件时会批量做这事，但应用层想立即触发就得自己来。
- 参数结构体是
DEVICE_DATA_SET_RANGE数组，每个元素含StartingOffset（字节偏移）、LengthInBytes，不是扇区数 - 偏移和长度都必须按设备最小分配单元对齐（通常 4KB），否则调用返回
ERROR_INVALID_PARAMETER - 一次最多传 512 个 range（Win10+），超出要分批；单个 range 长度建议 ≥ 4KB，太小效率低且部分 SSD 固件会忽略
C# 示例：用 P/Invoke 构造并发送 UNMAP 请求（仅核心骨架）
以下不是完整可运行代码，而是关键链路示意——省略了 Marshal.AllocHGlobal 错误检查、句柄清理、多 range 循环等工程细节，只保留最易出错的三处：
// 1. 打开卷句柄（注意冒号后不能有反斜杠）IntPtr hVolume = CreateFile("\.C:", GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, IntPtr.Zero, OPEN_EXISTING, 0, IntPtr.Zero); <p>// 2. 构造 DEVICE_DATA_SET_RANGE（假设要 trim 从 0x100000 开始的 64KB）var range = new DEVICE_DATA_SET_RANGE {StartingOffset = 0x100000UL, LengthInBytes = 0x10000UL}; int size = Marshal.SizeOf<DEVICE_DATA_SET_RANGE>(); IntPtr buffer = Marshal.AllocHGlobal(size); Marshal.StructureToPtr(range, buffer, false);</p><p>// 3. 发送控制码（注意：输入缓冲区是 range 数组首地址，不是结构体本身）bool ok = DeviceIoControl(hVolume, IOCTL_STORAGE_MANAGE_DATA_SET<em>ATTRIBUTES, buffer, size, IntPtr.Zero, 0, out </em>, IntPtr.Zero);</p> 容易踩的坑：CreateFile 路径写成 "\.C:\" 或 "C:" 会失败；StartingOffset 传了文件内偏移（如 0）而不是卷上 LBA；忘记 Marshal.FreeHGlobal(buffer) 导致内存泄漏。
Linux/macOS 不适用，此方案纯 Windows 特定，且 SSD 固件行为不可控
这套基于 DeviceIoControl 的方案只存在于 Windows 内核驱动模型中。Linux 用 ioctl(fd, BLKDISCARD)，macOS 用 ioctl(fd, DKIOCTRIM)，C# 在非 Windows 平台无法直通调用——即使跨平台运行时（如 .NET 6+）也绕不开 OS 层抽象。
更现实的问题是：即便调用成功，SSD 是否真把那些块擦除、何时擦除、是否合并相邻 TRIM 请求，完全取决于固件实现。有些低端 SATA SSD 对连续大范围 TRIM 响应慢，NVMe 盘则通常更快。没有日志、没有回调、也没有确认机制——你只能相信返回值为 true，然后观察后续写入延迟是否下降。
真正需要精确控制回收时机的场景（如数据库 WAL 清理后立刻释放空间），往往得配合 fsutil behavior set disablelastaccess 1 减少元数据更新，并依赖 NTFS 自身的定期 TRIM 策略，而不是每次删完都手动打一枪。
