ntfs压缩由windows文件系统层实现，c#仅能通过file.setattributes设置fileattributes.compressed标记，无法直接控制压缩过程；该标记仅提示ntfs启用压缩，实际压缩时机和程度由系统决定。
NTFS 压缩不是 C# 控制的，而是 Windows 文件系统层的行为
你不能用 System.IO 里的任何 API “开启压缩”——C# 没有内置压缩开关。NTFS 压缩是文件系统属性，由 Windows 内核在读写时透明处理：写入时自动压缩，读取时自动解压，对应用完全无感。
这意味着：File.Copy、FileStream、BinaryWriter 等所有 I/O 操作照常工作，不需改代码，也不需要引用额外库。
但注意：这不是“ZIP 压缩”，不改变文件逻辑内容，也不跨平台兼容；Linux 或 macOS 挂载 NTFS 分区时通常看不到压缩效果，甚至可能报错或跳过。
如何用 C# 设置/查询 NTFS 压缩属性（FileAttributes.Compressed）
真正能做的，只有通过 Win32 API（经 SetFileAttributes）或 .NET 封装（File.SetAttributes）来设置/读取该标记。它只是告诉 NTFS：“请对这个文件启用压缩”，是否真压缩、压多少，由 NTFS 自行决定。
-
File.SetAttributes(@"C:\data\log.bin", FileAttributes.Compressed)—— 设置后，下次写入或系统空闲时可能触发压缩（非立即） -
File.GetAttributes(@"C:\data\log.bin") & FileAttributes.Compressed—— 判断是否已标记为压缩（但不代表当前物理上已压缩） - 目录也能设
FileAttributes.Compressed，新创建的文件会继承该标记（仅限同分区、同 NTFS 卷） - 移动（
File.Move）到非 NTFS 分区会丢失该属性；复制（File.Copy）则不会自动继承，目标文件默认无压缩标记
为什么 FileAttributes.Compressed 有时查不到，或者设了没反应？
常见现象：调用 File.SetAttributes 成功，但用资源管理器看属性没勾选，或用 fsutil behavior query disablelastaccess 查不到压缩状态——这很正常。
原因包括：
- 目标卷未启用 NTFS 压缩支持（极少见，但某些企业策略或 BitLocker 加密卷会禁用）
- 文件太小（
- 文件已加密（
FileAttributes.Encrypted），NTFS 不允许同时加密+压缩（二者互斥） - 进程没有管理员权限？其实不需要——只要对文件有写属性权限即可；但若文件被其他进程独占打开，设置会失败并抛
UnauthorizedAccessException
别指望靠它省大量磁盘空间，也别在 SSD 上盲目开
NTFS 压缩本质是 CPU 换 IO 和空间：压缩/解压耗 CPU，减少磁盘读写量。对 HDD 可能略降寻道时间，但对现代 SSD，多数场景反而降低吞吐（尤其高并发小文件）。
实测常见误区：
- 文本日志、JSON、XML 类文件压缩率高（40–60%），但
.png、.jpg、.zip这类已压缩格式几乎不变，还白费 CPU - 数据库文件（如
.mdf）、内存映射文件（MemoryMappedFile）设了压缩标记后，SQL Server 或 .NET 运行时可能拒绝加载或报IO.IOException - 防病毒软件扫描压缩文件时更慢，部分引擎会临时解压全量到内存，导致峰值内存飙升
最常被忽略的一点：压缩状态不可靠迁移。备份工具（如 robocopy /copyall）能保留，但普通拖拽、xcopy、7-Zip 解包默认都不传这个属性。上线前务必验证生产环境的实际压缩生效情况，而不是只看代码里有没有那行 SetAttributes。
