httpclient.timeout仅控制sendasync后的响应读取阶段，不涵盖dns、tcp、tls等前置环节；可靠超时需用cancellationtokensource+全程透传token。
超时不是加个 Timeout 属性就完事——HttpClient.Timeout 不管 DNS、TCP 连接、TLS 握手，也不保证能真正中断 I/O；真要可靠超时，必须组合 CancellationTokenSource + 正确传递 token。
HttpClient.Timeout 只控制 SendAsync 阶段
很多人以为 HttpClient.Timeout = TimeSpan.FromSeconds(5) 能让整个请求在 5 秒内结束，实际它只作用于 SendAsync 返回后的响应读取阶段。DNS 解析失败、TCP 连接卡在 SYN_WAIT、TLS 握手超时等前置环节，它完全无感，可能卡住 20–30 秒才抛出 TaskCanceledException。
常见错误现象：HttpClient 看似“没反应”，日志里既没成功也没异常，等了十几秒突然报错或返回。
- 它不触发
CancellationToken，所以无法与外部取消信号联动 - 不能用于
PostAsync等带 body 的请求的发送阶段超时（body 写入阻塞时无效） - 多个并发请求共用一个
HttpClient实例时，Timeout是全局覆盖的，无法 per-request 定制
异步超时必须用 CancellationTokenSource + 传 token
真正可控的超时，是靠 CancellationTokenSource 主动触发取消，并把 cts.Token 一路透传到底层支持取消的 API（如 HttpClient.GetAsync、Stream.ReadAsync）。
正确做法：
- 用
using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(5))创建带自动取消的源 - 把
cts.Token明确传给所有支持CancellationToken参数的异步方法 - 捕获
OperationCanceledException，并用cts.IsCancellationRequested区分是超时还是用户主动取消 - 避免在 UI 线程中用
Wait()或同步等待——会死锁
示例关键片段：
using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(5));
try
{
var response = await client.GetAsync("https://api.example.com", cts.Token);
return await response.Content.ReadAsStringAsync(cts.Token);
}
catch (OperationCanceledException) when (cts.IsCancellationRequested)
{
// 真正的超时路径
Log.Warning("Request timed out after 5s");
throw;
}
Polly TimeoutPolicy 是封装，但别误用 Pessimistic 模式
Policy.TimeoutAsync<tresult>(TimeSpan, TimeoutStrategy)</tresult> 是 Polly 提供的声明式超时策略，但它底层仍依赖 CancellationToken。关键在于策略模式选择：
-
TimeoutStrategy.Optimistic：仅检查 token 是否被取消（推荐），轻量、无额外线程开销，要求下游方法真正响应 token -
TimeoutStrategy.Pessimistic：启动独立监控线程，超时后强制调用cts.Cancel()——但若目标方法根本不检查 token，它只是“假装取消”，后台任务照常跑
容易踩的坑：
- 用了
Pessimistic却没验证下游是否真的支持协作取消（比如自定义 socket 读写没轮询token.IsCancellationRequested） - 在
ExecuteAsync中传了CancellationToken.None，导致 Polly 的 token 根本没传下去 - 把 Polly timeout 和
HttpClient.Timeout叠加使用，逻辑冗余且掩盖真实问题
同步方法加超时本质是“放弃等待”，不是“终止执行”
对纯同步方法（如 File.ReadAllText、自定义计算函数），Task.Run(...).Wait(timeout) 只是主线程不再等，Task.Run 启动的线程池线程仍会继续执行完——.NET 不允许强制中止正在运行的线程。
这意味着：
- 如果同步方法有副作用（如写文件、发 HTTP、改数据库），超时后你无法知道它是否已完成
- 不能用于幂等性不确定的操作（比如“扣款+发消息”，超时后重试可能重复扣款）
- 真正需要中断的场景，必须改造成异步 +
CancellationToken支持（例如用FileStream.ReadAsync替代FileStream.Read）
一句话收尾：超时的可靠性，永远取决于最底层那个 I/O 或计算操作是否真正响应 CancellationToken；所有上层包装（Polly、WaitAsync、HttpClient.Timeout）都只是“调度器”，不是“断路器”。
