应手动累加每次Read返回的实际字节数来监控进度，而非依赖Position或CopyToAsync；推荐用IProgress配合async/await实现可控、可测的进度通知。
用 FileStream 配合 Read 循环时怎么拿到进度
直接读大文件不显示进度，是因为 FileStream.Read 是阻塞式批量读取，它只返回本次读到的字节数，不暴露内部偏移。想监控，就得自己维护已读总量。
关键不是换 API，而是把「每次读多少」和「读完累加多少」显式做出来：
- 用固定缓冲区（比如
new byte[8192]），每次调用stream.Read(buffer, 0, buffer.Length) -
Read返回值是实际读取字节数（可能小于缓冲区长度，尤其在结尾），必须用这个值累加，不能假设每次都读满 - 读取过程中定期触发回调或更新 UI，比如每读 1MB 报一次：
if (totalRead % 1048576 == 0) OnProgressChanged(totalRead, stream.Length); - 注意：不要在循环里频繁更新界面控件（如 WinForms 的
Label.Text），容易卡顿；改用Invoke或绑定到后台线程安全的属性
BackgroundWorker 和 async/await 哪个更适合监控
BackgroundWorker 自带 ReportProgress，写起来短，但已过时，且不支持 async 内部操作；async/await 更现代，但得自己搭进度通知机制。
真实项目中推荐后者，因为：
- 用
IProgress参数传入读取方法，比靠事件更可控、更易测试 - 避免
BackgroundWorker在 .NET Core/.NET 5+ 中缺失的问题 - 示例片段：
var progress = new Progress<int>(value => progressBar.Value = value);<br>await ReadFileAsync(fileStream, progress);</int>
- 别在
Progress回调里做耗时操作（比如写日志到磁盘），否则拖慢主线程
为什么 Position 属性不能直接当进度用
看起来简单：读一段就查 stream.Position，除以 stream.Length。但错在——Position 只反映上次读/写后的位置，不保证与当前缓冲区状态一致，尤其在异步或封装流（如 GZipStream）下会严重失准。
更隐蔽的问题：
- 某些流（如网络流、加密流）根本不支持
Length或Position，访问直接抛NotSupportedException - 即使支持，
Position是 long 类型，UI 更新时要做整数截断或百分比换算，容易溢出或精度丢失 - 真正可靠的进度只能来自你亲手控制的读操作 + 显式累加，别偷懒依赖流的元信息
用 CopyToAsync 还能监控吗
不能直接监控。CopyToAsync 是黑盒，不提供中间进度回调。但它底层其实也是分块读写，所以可以“自己重写一个带进度的 Copy”。
实操建议：
- 复制逻辑不复杂：开一个缓冲区，
while循环ReadAsync→ 更新进度 →WriteAsync - 别用
CopyToAsync然后靠反射或计时器去猜进度，既不准又难调试 - 如果目标是压缩或加密传输，优先考虑用支持进度回调的封装库（如
SharpCompress的ExtractProgress），而不是硬套FileStream
最常被忽略的一点：进度百分比不是线性的——磁盘缓存、系统预读、SSD 寿命均衡都可能导致前半段快、后半段慢，或者突然卡住。别把进度条做成“匀速动画”，用户感知反而更假。
