标注约定：✅ 已核验源码 · 🔁 已在本地复现或跑通 · ❓ 推断，未实测

• 应该进库。 库外做不到：socket 是 HttpClient 的私有状态，HttpClient 本身又不是线程安全的。库里也已经有半个先例：download_to_file 的 isCancelled 只在 body 的块与块之间检查。
• PR #23 的机制是对的，保留： 等待只发生在 Socket::wait_fd，有 token 时按 50 ms 分片 poll；bio_recv 读之前先等。它缺的是 token 的生命周期规则，H1 就是这个缺口造成的 bug：经 https 代理复用连接时，一个 POST 会被执行两次。
• 架构收敛成三条不变式： token 只放在传输链最底层的 Socket 上；token 只在调用期间挂着，连接回池时摘掉；不传 token 时行为和 0.3.3 完全一样。
• 改动量： 在 PR 基础上，src/ 约 +15 行（必需部分 +7 行），另加测试和 CI。必需部分已经做成原型跑通（§7）。
• CI 目前对这个功能只有一个配置有效： Linux + gcc 16。Windows job 不编译 test_cancel；Linux libc++（llvm 20/22）连链接都过不了；没有 macOS job。

结论：进。

反方意见及回应：“tiny 库不该长功能”。这里不是加功能，而是补全已有的取消语义（isCancelled 覆盖不全），并让三个入口一致。这和 #15 合并三个入口、只保留一份读取逻辑是同一个思路。

HttpClient::send / send_stream / download_to_file          ← 唯一接收 token 的地方
   │  perform_exchange: sock->set_stop(stop)               ← 挂上（每次调用、每次重试）
   │  PooledConnection::keep(): set_stop({})               ← 回池时摘下；drop() 直接销毁
   ▼
TlsSocket::set_stop ──转发──► lower_（https 代理隧道）──转发──► Socket
   │                         自己不存 token
   ▼
Socket::stop_  ── wait_fd()：分片 poll，片与片之间检查 stop_requested()
               ── bio_recv：有 token 时先 wait_readable(-1) 再 recv
               ── connect：每个地址、每次 DNS 回退前检查

为什么 token 必须作为状态存在 Socket 上，而不是作为参数一路传下去： mbedtls 的 BIO 回调只有一个 void* ctx，在这里就是 Socket* ✅。握手和 TLS record 的后半段都是从 bio_recv 里阻塞的，没有别的通道能把 token 送进去。既然状态没法避免，就用 I1 和 I2 限定它在哪里、活多久。

• Socket::wait_fd 的分片 poll（50 ms，固定值，不做成配置项）；bio_recv 的预等待；connect 前、每个地址、DNS 回退前的 stop 检查。
• perform_exchange 的 fail()：stop 优先于真实错误，并在这里 drop 连接；重试循环开头检查 stop；取消后不跟重定向。
• HttpResponse::cancelled，以及它在响应头到达前后的两种形态（见 §4）。
• proxy_tunnel 尾部的默认参数 stop（内部需要）。
• Socket 的 move 会带走 stop_；close() 不清 stop_，所以 set_stop 必须在 connect 之前调用，现在的顺序是对的 ✅。

三个入口共用 perform_exchange 和 read_body ✅。PR 只改了其中两个入口，download_to_file 仍然只有 isCancelled，又回到了 #15 那张“修复只落到部分入口”的矩阵。具体改法：

• 签名加尾部默认参数：download_to_file(url, dest, onProgress = nullptr, isCancelled = nullptr, std::stop_token stop = {})。
• DownloadToFileResult::cancelled：isCancelled 或 token 任一触发都置为 true。error 文本保持现有的 "cancelled" 不变，原来匹配文本的代码不受影响。
• 实现：perform_exchange(..., stop)；body 的 sink 里检查 stop；重定向递归时把 stop 传下去。预计约 +15 行。
• isCancelled 保留，不标记废弃。它是轮询式谓词，和 token 不冲突。

• proxy_connect(..., std::stop_token)：这是只返回 Socket 的遗留包装函数，库内部不用它。加参数只会扩大导出面（YAGNI）。

其他规则：

• ok() 不看 cancelled，就像它也不看 bodyComplete。取消的契约是那个 bool，不是文本。
• 取消后不做 stale-connection 重试，也不跟重定向。
• 真实失败和 stop 同时发生时，报告为取消。
• 响应时间约 50 ms（一个分片）。
• close_notify 只在握手完成之后的取消中发送。

已知限制：getaddrinfo 和 socks5:// 对目标地址的解析不可中断；对端不读导致的阻塞写不可中断（socket 在 connect 之后被设回阻塞模式，socket.cppm:257 ✅，见 D4）；openkal 上 connect 是同步完成的。

PR 已有 13 个用例，覆盖各阶段的首次建连 ✅。缺口在“复用连接”这一维度，H1 就漏在这里。补成下面这个矩阵：

时间断言使用 kPromptMs = 500。Windows 和 macOS 的 runner 比较慢，如果出现偶发失败，再按平台放宽，不要预先放宽。

• 在 llvm 20.1.7 和 22.1.8（libc++）上，先 #include <thread> 再 import std;，然后调用 stop_source::request_stop()，链接时报 undefined hidden symbol __atomic_unique_lock<...>::__set_locked_bit。llvm 23.1.0 和 gcc 16 正常。这是工具链 bug，不是本库的问题。
• 仓库测试文件的惯例是先 include 后 import，因为 gcc 必须这样：反过来在 gcc 16 上会报 redefinition of std::byte 等错误 🔁。
• 解决办法：在 test_cancel.cpp 里按标准库区分顺序（已验证 llvm 22 和 gcc 16 都能 16/16 通过）：

// libc++ (≤22) fails to link stop_source::request_stop() when <stop_token>
// was included textually before `import std`; libstdc++ needs the opposite.
#include <version>
#ifdef _LIBCPP_VERSION
import std;
#endif
#include <gtest/gtest.h>
#include "proxy_test_server.hpp"
#include "tls_test_server.hpp"

import mcpplibs.tinyhttps;
#ifndef _LIBCPP_VERSION
import std;
#endif

• llvm 20 在 Linux 上两种顺序都编不过（import 在前时报 requires clause differs）🔁，显式实例化 __atomic_unique_lock 也不行 🔁，因此 libc++ 只把 22 纳入 CI 矩阵（Linux 和 macOS 都用 llvm@22.1.8；Windows 上的 llvm@20.1.7 用的是 MSVC STL，不受影响）。
• README 的 jthread 示例对“include 和 import std 混用、用 libc++ ≤22”的使用者同样会链接失败，需要在 README 里加一行说明。

原型补丁（H1 + M1 + M2 + 3 个复现测试）已经在 PR 分支上跑通：test_cancel 16/16、test_pool、test_proxy、test_framing 通过（gcc 16），test_cancel 在 llvm 22 上也通过。之前那一轮（H1 + 复现测试）的全量 mcpp test 是 8/8 🔁。

顺序说明：1 和 2 是正确性修复，最先落地；3 必须在 6 之前，否则新加的 llvm job 第一次跑就会失败；6 失败时（比如 Windows 测试服务器不可移植），可以把 Windows 部分拆成 follow-up，不阻塞合并。