流的cancel信号冒泡是取消请求从下游向上游逐层穿透，触发各环节主动退出并释放资源；需显式监听响应，依赖协作机制而非强制终止，各组件须集成取消逻辑并检查状态。
流的 cancel 信号冒泡，本质是让取消请求从下游向上游逐层穿透，触发整条处理链中每个环节主动退出并释放资源。它不是强制杀掉线程或协程，而是靠协作机制实现“通知—响应—清理”闭环。关键在于信号能被正确传递、监听和响应。
信号必须沿数据流向反向传播
流处理管道通常是线性或树状结构（如 source → transform → sink），cancel 信号需从最外层消费者发起，逆向传回源头。例如：
- 用户调用 stream.cancel() 或外部 CancellationToken.cancel()，源头协程收到 ctx.Done() 或 token.IsCancellationRequested
- 源头立即停止读取新数据，并向下游发送“结束”或“取消”帧（如 AsyncIterable 的
return()） - 中间转换层（如 map、filter）在 await 下一个 item 前检查 token 状态；一旦为已取消，跳过后续处理，直接执行 finally 或 defer 中的清理逻辑
- 最终 sink 层（如写入文件、发 HTTP 请求）在收到终止信号后关闭句柄、释放连接、清空缓冲区
每个环节都要显式监听并响应取消
冒泡不会自动发生，每个参与流处理的组件都需主动集成取消逻辑：
- 使用 async/await + CancellationToken（C#）、context.Context（Go）、asyncio.shield() + try/except CancelledError（Python）等原语封装每段逻辑
- 避免在协程内部用死循环
while True而不检查取消状态；应改为while !token.isCancelled()或select { case - 对 I/O 操作（如
readLineAsync()、recv()）要确保其底层支持取消——否则需包裹超时或手动中断
资源释放必须绑定到确定性退出路径
不能依赖 GC 或作用域自动回收，尤其对文件描述符、Socket、数据库连接、内存缓冲区等有限资源：
- 在 finally 块（Python/Java/C#）、defer 语句（Go）、using 块（C#）中执行
close()、release()、free() - 若某环节持有多个资源（如打开文件 + 启动心跳定时器），应在同一 finally 中全部清理，避免只释放部分
- 注意重放（replay）场景：Temporal 或某些流引擎会在故障恢复时重放历史事件，此时清理逻辑需加判断（如
if not is_replaying()）防止重复释放
父子上下文要继承且可独立控制
复杂管道常含子流或并行分支，需合理设计上下文层级：
- 主流创建 WithCancel(parent)，子流复用该 ctx —— 父取消则子自动收到信号
- 若某子流需独立生命周期（如后台日志上传），应创建 WithCancel(ctx) 并自行管理 cancel 函数
- 避免混合多个独立 token；否则需轮询所有状态，增加逻辑负担和响应延迟
