FileStream.ReadAsync/WriteAsync取消常失效，因Windows底层I/O不响应CancellationToken；CopyToAsync仅.NET Core 2.1+支持取消；文件打开不可取消；取消后需用await using确保DisposeAsync释放资源。
取消 FileStream.ReadAsync 和 WriteAsync 时为什么经常不生效
因为底层 I/O 操作在 Windows 上默认不响应 CancellationToken —— 它只是“挂起等待”，不是真正注册到系统调用里。你传了 cancellationToken，但线程池里的 IOCP 回调根本不会检查它是否被触发。
实操建议：
- 必须使用支持取消的构造方式：创建
FileStream时显式传入useAsync: true（.NET 5+ 默认为true，但旧版本或手动指定更稳妥） - 确保调用的是带
CancellationToken参数的重载，例如ReadAsync(buffer, cancellationToken)，而不是无参版本 - 避免混合同步/异步：不要在
async方法里调用Read或Write，否则取消令牌完全被绕过
CopyToAsync 能否被 CancellationToken 中断
可以，但仅限于 .NET Core 2.1+ 和 .NET 5+；旧版（如 .NET Framework 4.7.2）的 CopyToAsync 忽略 CancellationToken 参数，形同虚设。
实操建议：
- 检查运行时版本，若低于 .NET Core 2.1，必须手写循环 +
ReadAsync/WriteAsync并在每次迭代前调用cancellationToken.ThrowIfCancellationRequested() - 即使新版可用，也要注意：取消只发生在读/写操作之间，不会中断正在进行的单次系统调用（比如一个 64KB 的读可能已发往内核，此时取消只能等它完成再退出）
- 别依赖
CopyToAsync自动处理超时——它不响应CancellationTokenSource.CancelAfter()的倒计时逻辑，除非你在外部主动调用Cancel()
文件打开阶段（new FileStream）能取消吗
不能。构造 FileStream 是同步阻塞操作，不接受 CancellationToken，也无法中断正在执行的 CreateFile 系统调用。
实操建议：
- 把耗时的打开逻辑（尤其是网络路径、映射驱动器、权限检查）移到异步包装层外做预检，比如先用
File.Exists+Directory.GetAccessControl快速失败 - 如果必须打开远程 SMB 文件且怕卡住，改用
Task.Run(() => new FileStream(...))包一层，再配合Task.WaitAsync(cancellationToken)实现“伪取消”（本质是丢弃任务，但底层句柄可能泄漏，需谨慎） - 更稳妥的做法：用
FileStream的FileOptions.Asynchronous标志 + 异步打开封装（如File.OpenHandle+CreateFileAsyncP/Invoke），但这属于高级场景，普通业务不推荐
取消后资源没释放？常见泄漏点在哪
最常漏掉的是 FileStream 本身没及时 Dispose，尤其在 catch (OperationCanceledException) 分支里忘了 stream?.Dispose() 或没走 using 语句块。
实操建议：
- 永远用
using await（C# 8+）或await using，它会保证无论正常结束还是取消/异常，都调用DisposeAsync() - 不要在
finally块里手动Dispose()，因为FileStream.DisposeAsync()才真正取消挂起的写入缓冲区刷新；同步Dispose()可能阻塞 - 注意
MemoryStream不受取消影响，但它不是重点——真要取消的是磁盘或网络 I/O，不是内存拷贝
真正的难点从来不在“怎么写取消代码”，而在于判断哪一步真的可取消、哪一步只是假装响应。比如 FileStream 关闭时的缓冲区刷盘，哪怕你已取消读写，它仍可能默默阻塞几秒——这个行为连 CancellationToken 都管不了。
