Channel.CreateBounded卡死或抛OperationCanceledException的根本原因是未启动消费者任务，导致写入时缓冲区满而阻塞或取消；必须显式启动长期运行的Reader.ReadAsync循环，并合理配置BoundedChannelOptions。Channel.CreateBounded 为什么一用就卡死或抛 OperationCanceledException根本原因不是代码写错了，而是没启动消费端------Channel 默认不自动拉取，写入后没人 Reader.ReadAsync()，缓冲区满就会阻塞（同步模式）或抛 OperationCanceledException（异步限流模式）。这和 BlockingCollection 的"自动等待"直觉相反。实操建议：必须显式启动至少一个长期运行的消费者任务，调用 await channel.Reader.ReadAsync(cancellationToken) 循环读取不要在 UI 线程或短生命周期作用域（如 ASP.NET Core 中间件单次请求）里直接 WriteAsync 后就结束------写入可能永远挂起创建时显式传入 BoundedChannelOptions，避免依赖默认值：var channel = Channel.CreateBounded<int>(new BoundedChannelOptions(100) { FullMode = BoundedChannelFullMode.Wait });FullMode = BoundedChannelFullMode.DropWrite 可丢弃新写入项，适合日志、监控等容忍丢失的场景；但别在金融类流程里用WriteAsync 阻塞 vs TryWrite 的区别和选型依据WriteAsync 在有界通道满时会 await，直到有空位或超时/取消；TryWrite 立即返回 bool，不等待。这不是性能高低问题，而是语义差异：你要的是「背压控制」还是「尽力而为」。常见错误现象：用 TryWrite 替代 WriteAsync 却没处理 false 返回值，导致数据静默丢失。使用场景建议：需要精确控速、防止下游过载（如批量处理外部 API 调用）→ 用 WriteAsync + 合理 FullMode高频埋点、指标上报，可容忍少量丢失 → TryWrite，但必须检查返回值：if (!channel.Writer.TryWrite(item)) { /* 记录丢弃日志或降级处理 */ }TryWrite 不受 cancellationToken 影响，无法响应取消；WriteAsync 支持 cancellation，适合长时管道如何安全关闭 Channel 并确保所有数据被消费完调用 Writer.Complete() 只是标记"不再写入"，不会自动停止读取；如果消费者还在 ReadAsync，它会收到 ChannelClosedException 或读到 default(T)（取决于是否检查 WaitToReadAsync），但更常见的是漏掉最后一批数据。 Zeemo AI 一款专业的视频字幕制作和视频处理工具