取消 HttpClient 请求必须显式传递 CancellationToken，否则 Cancel() 无效；它需传入 GetAsync 等方法，并在封装方法和 Controller 中正确透传与注入，本质是协作契约而非强制命令。
取消正在执行的 HttpClient 请求必须传 CancellationToken
不传 cancellationtoken，httpclient 的所有异步方法（如 getasync、postasync）默认无法被外部取消——哪怕你调用了 cancellationtokensource.cancel()，请求仍会继续发出去并等待响应，只是后续 await 会抛出 operationcanceledexception。
真正起作用的只有把 CancellationToken 显式传进请求方法里：
var cts = new CancellationTokenSource();
// ⚠️ 必须传进去，否则 cancel 无效
var response = await client.GetAsync("https://api.example.com", cts.Token);
-
CancellationToken不是“监听器”，而是由HttpClientHandler底层在连接建立、读取响应流等关键节点主动检查的信号 - 如果请求已发出且服务器开始返回数据，取消可能只中断客户端接收，服务器端请求通常仍会执行完（HTTP 协议本身无强制中止机制）
- 在 Blazor WebAssembly 中，因浏览器 Fetch API 限制，取消行为可能不如 .NET Desktop 稳定，部分场景会降级为忽略取消
用 CancellationTokenSource.CancelAfter() 做超时比 TimeSpan 更可靠
很多人习惯用 HttpClient.Timeout 控制超时，但它只作用于整个请求生命周期（从调用开始到响应完成），且一旦触发会直接 dispose HttpClient 实例，无法复用；而 CancellationTokenSource.CancelAfter(3000) 是更细粒度、可组合的控制方式。
常见误用：client.Timeout = TimeSpan.FromSeconds(3); + 单例 HttpClient → 多个并发请求互相干扰超时判断。
- 每个请求应配独立的
CancellationTokenSource，避免跨请求污染 -
CancelAfter()可与用户手动取消（如 UI 按钮）共用同一个Token，统一处理逻辑 - 注意：
CancelAfter()后再调用cts.Cancel()不会重复抛异常，但多次调用Cancel()本身是安全的
传递 CancellationToken 到自定义异步方法时别丢掉它
当你封装一个带网络调用的业务方法（比如 FetchUserAsync(int id)），很容易只在内部 new 一个 CancellationToken，却忘了把上游传入的 token 向下透传。
错误写法：
public async Task<user> FetchUserAsync(int id) // ❌ 没有接收 token 参数
{
var cts = new CancellationTokenSource(TimeSpan.FromSeconds(5));
return await _httpClient.GetFromJsonAsync<user>($"/users/{id}", cts.Token);
}</user></user>
正确写法：
public async Task<user> FetchUserAsync(int id, CancellationToken cancellationToken = default)
{
return await _httpClient.GetFromJsonAsync<user>($"/users/{id}", cancellationToken);
}</user></user>
- 参数默认值用
= default，不是= CancellationToken.None（虽然效果一样，但前者是约定） - 若方法内部还调用了其他可取消的异步操作（如
FileStream.ReadAsync），必须把同一个cancellationToken传给它们 - 不要在方法内重新创建
CancellationTokenSource并覆盖传入的 token，除非你明确要隔离取消语义
ASP.NET Core Controller 里接收 CancellationToken 要加 [FromServices]
Controller 方法参数里的 CancellationToken 不是自动绑定的模型，也不是从请求体解析出来的——它是框架在每次请求上下文创建时注入的实例，需显式声明并标记来源。
错误写法：
[HttpGet("{id}")]
public async Task<actionresult>> GetUser(int id, CancellationToken cancellationToken) // ❌ 编译通过但实际得不到有效 token
{
// cancellationToken 始终是 default，不会随请求终止而触发
}</actionresult>
正确写法：
[HttpGet("{id}")]
public async Task<actionresult>> GetUser(int id, [FromServices] CancellationToken cancellationToken)
{
var user = await _userService.GetUserAsync(id, cancellationToken);
return Ok(user);
}</actionresult>
-
[FromServices]告诉 MVC 从 DI 容器取当前请求绑定的CancellationToken（本质是HttpContext.RequestAborted） - 这个 token 会在客户端断开连接、超时或主动关闭时自动触发，无需额外管理
CancellationTokenSource - 如果同时需要手动取消（如后台任务）+ 请求生命周期取消，建议用
CancellationTokenSource.CreateLinkedTokenSource()合并多个 token
CancellationToken 的真正难点不在语法，而在理解它不是“命令”而是“协作契约”：每个参与方都得主动检查、及时响应、不自行吞掉异常。漏掉一次传递、错用一次默认值、或在 IO 阻塞点没做适配，取消就会静默失效。
