C产品如何满足特定用户需求？

本文共计1056个文字，预计阅读时间需要5分钟。

文件大小本质上是字节数，`FileInfo.Length` 属性直接返回+long+ 类型的字节数值，这是最可靠、无歧义的底层数据。

注意别用 File.GetAttributes 或检查文件系统元数据——那些可能不反映实际占用（比如稀疏文件、压缩卷），而 Length 是文件逻辑长度，也是用户真正关心的“大小”。

• 必须用 try/catch 包裹，权限不足或路径不存在时会抛 UnauthorizedAccessException 或 FileNotFoundException
• 对网络路径或符号链接，Length 仍有效，但访问延迟或失败风险更高
• 不要在 UI 线程反复调用——大目录下遍历多个文件时，I/O 会阻塞界面

手动换算 KB/MB 时注意二进制 vs 十进制单位

Windows 资源管理器显示的“KB”其实是 KiB（1024 字节），但有些报表系统按 1000 换算。C# 不内置自动格式化，得自己控制分母。

常见错误是写成 bytes / 1024 就当 KB，却没处理小数位、没区分 KiB/KB，导致 “1024 字节 → 1.0 KB” 看起来合理，但 “1025 字节 → 1.0009765625 KB” 显示太长。

• KiB（二进制）：除以 1024.0，适合和系统资源管理器对齐
• KB（十进制）：除以 1000.0，适合磁盘厂商标称容量或某些 API 要求
• 建议统一保留 2 位小数，用 Math.Round(value, 2)，避免 ToString("F2") 在负数或 NaN 时出问题

用 FileSizeHelper 类封装常用格式化逻辑

没有现成的 BCL 类做“智能单位切换”（如自动选 B/KB/MB/GB），但几行代码就能写个轻量工具：

public static string ToFileSizeString(long bytes) { string[] units = { "B", "KB", "MB", "GB", "TB" }; double size = bytes; int unitIndex = 0; while (Math.Abs(size) >= 1024 && unitIndex < units.Length - 1) { size /= 1024; unitIndex++; } return $"{Math.Round(size, 2)} {units[unitIndex]}"; }

这个逻辑优先用 KiB，且只在 ≥1024 才升单位——避免 “1023 B” 显示成 “1.0 KB”。注意它不处理负数或 long.MaxValue 溢出，真实项目里要加边界判断。

• 别直接拼接字符串加单位，否则本地化时单位词序错乱（如某些语言单位在前）
• 如果需支持本地化，把单位数组换成 ResourceManager 查表，而非硬编码
• 高频调用场景（如 ListView 列渲染）建议缓存结果，避免重复计算

FileSystemInfo 和 DriveInfo 的大小字段不是一回事

新手容易混淆：FileInfo.Length 是文件内容大小；DriveInfo.TotalSize 是磁盘总字节数；而 FileSystemInfo 本身没有 Length——它只是基类，具体要用 FileInfo 或 DirectoryInfo。

更隐蔽的坑是：想查文件夹大小，不能靠 DirectoryInfo.Length（它不存在），必须递归累加所有子文件的 Length。而且要注意跳过循环符号链接、处理访问拒绝异常。

• DirectoryInfo 的 GetFiles("*", SearchOption.AllDirectories) 可能因权限中断，要用 try/catch 在每层捕获
• 大文件夹下递归很慢，考虑用 EnumerateFiles 避免一次性加载全路径列表到内存
• NTFS 压缩文件的 Length 是解压后大小，不是磁盘占用 —— 如果真要查“占多少空间”，得用 GetCompressedSize Win32 API（P/Invoke）

实际业务中，多数情况只需要 FileInfo.Length + 手动除 1024，但单位切换逻辑、异常分支、递归统计这三处最容易漏处理。尤其在导出报表或批量处理时，一个未 catch 的 UnauthorizedAccessException 就会让整个任务崩掉。