fileinfo.length 返回文件逻辑字节数，最可靠；需 try/catch 处理异常；网络路径和符号链接有效但风险高；ui 线程避免频繁调用；换算注意 kib（/1024.0）与 kb（/1000.0）区别，建议保留两位小数。
用 FileInfo.Length 获取原始字节数
文件大小本质就是字节数，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 <p>这个逻辑优先用 KiB，且只在 ≥1024 才升单位——避免 “1023 B” 显示成 “1.0 KB”。注意它不处理负数或 <code>long.MaxValue</code> 溢出，真实项目里要加边界判断。</p>
- 别直接拼接字符串加单位，否则本地化时单位词序错乱（如某些语言单位在前）
- 如果需支持本地化，把单位数组换成
ResourceManager查表，而非硬编码 - 高频调用场景（如 ListView 列渲染）建议缓存结果，避免重复计算
FileSystemInfo 和 DriveInfo 的大小字段不是一回事
新手容易混淆：FileInfo.Length 是文件内容大小；DriveInfo.TotalSize 是磁盘总字节数；而 FileSystemInfo 本身没有 Length——它只是基类，具体要用 FileInfo 或 DirectoryInfo。
更隐蔽的坑是：想查文件夹大小，不能靠 DirectoryInfo.Length（它不存在），必须递归累加所有子文件的 Length。而且要注意跳过循环符号链接、处理访问拒绝异常。
-
DirectoryInfo的GetFiles("*", SearchOption.AllDirectories)可能因权限中断，要用try/catch在每层捕获 - 大文件夹下递归很慢，考虑用
EnumerateFiles避免一次性加载全路径列表到内存 - NTFS 压缩文件的
Length是解压后大小，不是磁盘占用 —— 如果真要查“占多少空间”，得用GetCompressedSizeWin32 API（P/Invoke）
实际业务中，多数情况只需要 FileInfo.Length + 手动除 1024，但单位切换逻辑、异常分支、递归统计这三处最容易漏处理。尤其在导出报表或批量处理时，一个未 catch 的 UnauthorizedAccessException 就会让整个任务崩掉。
