c++oding="utf-8" ?>
std::stop_token不能跨线程直接传递，必须通过std::stop_source共享同一stop_state；层级取消需手动传播，子任务需显式调用子级request_stop()，且回调注册顺序影响执行安全。
std::stop_token 不能跨线程直接传递，必须通过 std::stop_source 转发
层级化任务中常见误区是把一个 std::stop_token 对象直接拷贝给子任务，以为它能自动感知父级取消——实际不行。每个 std::stop_token 只绑定到创建它的 std::stop_source 实例，子任务若想响应上级取消，必须由父任务显式提供自己的 std::stop_source 或转发其 token 的“监听能力”。
正确做法是：父任务持有 std::stop_source，构造子任务时传入该 source 的 get_token()（或直接传 source，让子任务自己调用 get_token()）；子任务内部再用这个 token 构造自己的 std::stop_callback 或轮询。
- 错误写法：
auto child_token = parent_token;—— 这只是浅拷贝，子任务无法感知 parent_source 的 stop() - 正确写法：
auto child_token = parent_source.get_token();—— 共享同一 stop_state - 若子任务需主动触发取消（如自身出错要终止整个树），应接收
std::stop_source&而非只读 token
层级取消需手动传播，std::stop_source 不自动级联
C++20 的 std::stop_source 是单点控制，调用 request_stop() 只影响它自己绑定的 token 集合，不会递归通知子 stop_source。这意味着：如果子任务也维护了独立的 std::stop_source（例如用于内部子任务），你必须在父级停止时显式调用子级的 request_stop()。
典型场景：一个异步工作流包含 “下载 → 解压 → 解析” 三层任务，每层都用 std::jthread 启动，并各自持有 std::stop_source。主控线程调用顶层 stop_source.request_stop() 后，仅顶层 token 触发；解压和解析层不会自动停，除非顶层回调里手动调用它们的 stop_source。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 必须在父任务的
std::stop_callback中触发子stop_source.request_stop() - 注意调用顺序：先通知子层，再清理本层资源，避免竞态（如子层还在访问已被销毁的 shared_ptr）
- 推荐模式：每个层级暴露
stop_source()方法，上层统一管理生命周期
std::jthread 构造时传入的 token 是只读快照，不反映后续 stop_source 变更
很多人用 std::jthread([&](std::stop_token stoken) { ... }) 启动任务，误以为这个 stoken 会随外部 stop_source 变化而动态更新——其实它是构造时的拷贝，与原始 source 绑定，但本身不可重绑定。只要 source 没被 move 或销毁，token 就始终有效；问题在于：它不能“切换”绑定目标。
这在层级嵌套中尤其关键。比如你把一个临时 std::stop_source 的 token 传给 jthread，之后又把这个 source 移出作用域，token 会立即变为 stop_possible() == false，但线程函数里可能还在轮询它，导致永远不退出。
- 确保传入
jthread的 token 来自生命周期长于线程的stop_source（例如类成员变量） - 避免在 lambda 捕获中按值捕获局部
stop_source，否则 token 绑定失效 - 检查 token 状态：用
if (stoken.stop_possible())前置判断，防止对无效 token 调用stop_requested()
多级回调注册顺序影响取消响应及时性
同一个 std::stop_source 上可注册多个 std::stop_callback，它们执行顺序是后注册先运行（栈式）。在层级结构中，若父任务注册了清理回调，子任务也注册了同 source 的回调，子回调可能比父回调先执行——而此时父资源可能已被释放，导致崩溃。
这不是标准保证的行为，而是实现细节（libstdc++ 和 MSVC STL 当前都按栈序），但不应依赖。真正可控的方式是：让父任务负责所有子任务的停止协调，子任务只响应、不注册顶层 source 的回调。
- 子任务应使用自己专属的
stop_source，由父任务在其回调中统一调用child_source.request_stop() - 若必须共用 token，注册回调时明确分组：先注册子任务的“撤退”回调，再注册父任务的“收尾”回调
- 避免在回调里做耗时操作（如文件写入），否则阻塞其他回调执行，放大响应延迟
层级化取消最易被忽略的点是：stop_token 的“有效性”和“活跃性”不是一回事——stop_possible() 返回 true 只表示它曾绑定过有效 source，不代表当前 source 还活着；而 stop_requested() 返回 true 才代表信号已发出。很多 bug 出在没检查前者就直接轮询后者，结果未定义行为。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
