C# 中 FileInfo.Length 的字节转可读大小应优先用 Humanizer 库，它自动处理二进制/十进制单位切换、边界判断与本地化；若自行实现，须严格按 1024 阈值分级、避免错误四舍五入，并预先捕获 UnauthorizedAccessException 等异常防止负值参与格式化。
用
Math.DivideByZeroException
？不，别自己除——用
Humanizer
库最稳
直接上结论：C# 没有内置的“字节→可读大小”格式化函数，
FileInfo.Length
返回的是
long
字节数，硬除容易错单位、漏边界、丢精度。推荐用开源库
Humanizer
，它处理了二进制（KiB）/十进制（KB）切换、小数位截断、本地化等所有细节。
实操建议：
安装：
dotnet add package Humanizer
调用：
bytes.Bytes().ToString("0.##", byteFormat: ByteFormat.Binary)
→ 输出
"1.23 MiB"
注意：默认是二进制（1024进制），要十进制（1000进制）得显式传
ByteFormat.Decimal
常见错误：直接
bytes / 1024.0 / 1024.0
后四舍五入，结果在 999.5–1023.9 字节区间会显示成
"1.0 KB"
，但实际应是
"1023 B"
——
Humanizer
自动选最合适的单位
string.Format
或插值字符串手动算？可以，但必须守住三道线
如果项目不能引入第三方库，就得自己写。核心不是“怎么除”，而是“在哪切单位、怎么取舍、谁来决定小数位”。
关键逻辑点：
单位阈值必须严格按 1024 切：B
小数位只对非整数单位生效：1024 字节就是
"1 KiB"
，不是
"1.00 KiB"
；而 1500 字节应是
"1.46 KiB"
避免
double
累积误差：用
decimal
做中间计算，或用整数移位（如
bytes >> 10
算 KiB 整数部分）
常见错误：用
Math.Round(value, 2)
直接套在除完的结果上，导致 1023.999 显示为
"1.00 KiB"
（实际该显示
"1023 B"
）
Windows API 的
StrFormatByteSize64
能用吗？能，但仅限桌面 Win32
这是 Windows 原生支持的格式化函数，返回带本地化单位（如中文“KB”“MB”）和千分位分隔符的字符串，
Shell32.dll
导出。
C知道
CSDN推出的一款AI技术问答工具
下载
适用场景有限：
只在 .NET Framework / .NET 5+ Windows 桌面应用中可用（
net6.0-windows
或更高）
跨平台项目（Linux/macOS）、Blazor、Unity IL2CPP 构建会失败
需要 P/Invoke 声明，且输入必须是
ulong
；负值或超
ulong.MaxValue
会崩
错误现象：
System.EntryPointNotFoundException: Unable to find an entry point named 'StrFormatByteSize64' in DLL 'shell32.dll'
—— 多见于 Nano Server 或容器环境
为什么
FileInfo.Length
有时是负数？这和格式化无关，但会影响你整个逻辑
FileInfo.Length
返回
long
，但某些特殊文件（如符号链接指向不存在路径、NTFS 稀疏文件未初始化区域、权限不足的系统文件）可能抛
UnauthorizedAccessException
或返回 -1。这不是格式化问题，但如果你没捕获就直接传给格式化函数，会导致单位错乱（比如 -1 字节被转成
"-1 B"
或触发除零）。
安全做法：
永远先检查异常：用
try/catch
包住
fileInfo.Length
访问
或改用异步方法
new FileInfo(path).GetAttributesAsync()
预判可访问性
若长度为负，不要参与格式化，应返回占位符如
"?"
或抛业务异常
容易被忽略的点：日志里看到
"-1 B"
，第一反应常是“格式化函数 bug”，其实是上游没兜住异常
