磁盘剩余空间低于阈值会触发ioexception、unauthorizedaccessexception或sqlexception等异常；因windows和.net均不主动预警，需监控driveinfo.availablefreespace并为关键盘设两级阈值。
磁盘剩余空间低于阈值会触发什么实际后果
不是所有“磁盘满”都立刻报错，但 IOException、UnauthorizedAccessException（尤其在日志轮转或临时文件写入时）、甚至 SqlException（SQL Server 数据库文件无法自动增长）往往都源于同一根源：可用空间不足。Windows 不会提前预警，.NET 运行时也不会主动检查磁盘——它只在 FileStream 打开、File.WriteAllText 写入、Directory.CreateDirectory 创建目录等操作真正执行时才抛异常。
实操建议：
- 监控
DriveInfo.AvailableFreeSpace，而非TotalFreeSpace（后者含系统保留空间，不反映应用可写空间） - 对关键盘（如
C:\、D:\logs）设置两级阈值：警告（如 - 注意 NTFS 的“系统保留空间”：即使显示还有 5 GB，若磁盘总大小为 128 GB，NTFS 默认预留约 4 GB 给管理员，普通用户进程可能已无法写入
文件句柄泄漏导致 IOException 的典型表现
“The process cannot access the file because it is being used by another process” 看似是并发冲突，但更常见的是本进程没正确释放句柄——比如忘了调用 Dispose()、没用 using 块、或异常路径跳过了关闭逻辑。Windows 单进程默认句柄上限约 16,384，耗尽后连 File.Exists 都可能失败（它内部也需打开句柄做元数据查询）。
实操建议：
- 所有实现
IDisposable的文件类型（FileStream、StreamWriter、BinaryReader等）必须走using语句，避免裸new+ 手动Close() - 用 Process Explorer 查看
Handle Count列，对比正常时段基线；若持续缓慢上涨，大概率存在泄漏 -
File.OpenRead(path)返回的FileStream仍需Dispose，它不是“只读就安全”
NTFS 日志满（USN Journal）影响文件变更监听
用 FileSystemWatcher 监控目录时，如果突然收不到 Created 或 Changed 事件，且无异常抛出，很可能是 USN Journal 溢出。NTFS 用这个日志记录文件系统变更，FileSystemWatcher 依赖它轮询——日志一满，新变更就丢弃，监听即失效。
实操建议：
- 检查日志状态：命令行运行
fsutil usn queryjournal C:，关注MaximumSize和AllocationDelta；若NextUsn接近MaximumSize，说明快满了 - 增大日志：用
fsutil usn createjournal m=0 a=0x20000000 C:（此处0x20000000≈ 512 MB），但需管理员权限 - 避免监听根目录或包含海量小文件的路径（如
node_modules），否则日志消耗极快
文件系统碎片率是否值得监控
对 SSD 来说，碎片率基本无关紧要——随机读写性能不受影响，且 Windows 自动禁用传统磁盘碎片整理。但对仍在用的机械硬盘（HDD），高碎片率会让 File.ReadAllBytes、Stream.Read 等顺序读操作变慢，尤其当单个大文件被切成上千片时。
实操建议：
- 仅对明确知道是 HDD 的驱动器查碎片：用
defrag C: /A /V获取分析报告，解析输出中的% Fragmentation - .NET 本身无直接 API 获取碎片率，必须调用 WMI（
Win32_Volume不提供该字段）或外部命令，成本较高，不建议高频轮询 - 更实用的替代指标是“大文件连续写入延迟”：用
Stopwatch测量File.WriteAllBytes一个 100 MB 随机数据块的耗时，持续上升可能暗示底层 I/O 压力或碎片问题
文件系统健康不是“看一眼剩余空间就完事”。真正的风险常藏在句柄生命周期、NTFS 底层日志、甚至硬件类型差异里——这些点一旦忽略，故障往往在凌晨三点以静默方式发生。
