软超时没生效是因为未配对timeout和deadline：timeout控制单次请求等待上限，deadline才是从调用起算的绝对截止时间，且gRPC中deadline必须为float类型、需服务端配合响应取消。
软超时没生效，其实是没配对 timeout 和 deadline
Python 标准库本身不直接提供“软/硬超时”概念，这是 gRPC、HTTPX 或某些异步框架（如 trio）里的组合策略。常见误区是只设了 timeout 却没配 deadline，结果看起来像超时失效。
比如在 httpx.AsyncClient 中，timeout 是软超时（可重试），但必须配合 limits.max_keepalive_connections 和底层事件循环的 deadline 才能触发硬中断；而 gRPC 的 deadline 参数才是真正的硬超时（会直接断开连接）。
-
timeout控制单次请求的等待上限，超时后可能抛TimeoutException，但连接还活着，后续请求仍可用 -
deadline是从调用发起时刻起算的绝对截止时间，超时后整个 RPC 调用被强制终止，底层 socket 会被关闭 - 两者混用时，
deadline必须 ≤timeout+ 调用前耗时，否则软超时还没触发，硬超时就先炸了
gRPC Python 中 deadline 不起作用的三个典型原因
写完 stub.Method(request, deadline=5.0) 却发现延迟 10 秒才报错？大概率是下面某个环节漏了。
- 服务端没启用
grpc.EnableTracing或没正确处理context.cancelled()，导致它继续执行完才返回 —— 硬超时只管客户端断连，不管服务端是否响应 - 客户端用了同步 stub，但事件循环没跑起来（比如在非
async def函数里调用异步 stub），deadline会被忽略 -
deadline值传的是整数（如5），而 gRPC Python 要求 float 类型，传5会被当成无限期，得写成5.0
HTTPX 里怎么让软超时重试、硬超时立刻放弃
HTTPX 默认只有 timeout，要模拟“软+硬”组合，得靠 transport 层 + 自定义异常拦截。
立即学习“Python免费学习笔记（深入）”；
关键是用 httpx.Limits 控制连接生命周期，再配合 httpx.Timeout 的各字段分治：
-
timeout=5.0：软超时，控制读/写/连接三阶段总和，超时后抛httpx.TimeoutException，可捕获重试 -
limits= httpx.Limits(max_connections=10, max_keepalive_connections=5, keepalive_expiry=5.0)：限制连接池行为，避免因复用旧连接导致“表面超时但实际卡死” - 硬超时靠外层
anyio.fail_after(8.0)或trio.move_on_after(8.0)包裹整个请求，一旦触发就彻底 kill 当前 task，不给重试机会
示例：
async with httpx.AsyncClient(timeout=httpx.Timeout(5.0)) as client:
with trio.move_on_after(8.0):
resp = await client.get("https://api.example.com")
异步任务里混用软硬超时，最容易被忽略的资源泄漏点
软超时抛异常后如果没显式清理，连接、文件句柄、数据库游标都可能卡住。
- 用
async with包裹 client 是基础，但要注意：软超时异常发生时，__aexit__可能来不及运行 —— 得加finally块手动await client.aclose() - 硬超时（如
trio.move_on_after）会直接取消 task，但被取消的协程若正在 await 一个未设置 cancel scope 的 IO 操作（比如没包装trio.to_thread.run_sync的阻塞调用），就会变成 zombie task - gRPC channel 关闭必须显式调用
channel.close()，不能依赖 GC；软超时反复失败后若没关 channel，会堆积大量 idle 连接
真正麻烦的不是超时逻辑写不对，而是超时之后——谁来收尸、什么时候收、收得干不干净。
