统一超时处理需捕获asyncio.timeouterror并优先处理，确保任务取消、资源释放，返回标准化响应，并按场景差异化设置超时值。
核心是统一超时异常的捕获、响应和清理逻辑，而不是只做“try-catch 一下”就完事。
统一捕获 asyncio.TimeoutError
所有用 asyncio.wait_for 或 asyncio.timeout() 的地方，必须显式捕获 asyncio.TimeoutError。它不会自动被其他异常处理器兜住，漏捕获会导致未处理异常中断事件循环。
- 不要只写
except Exception:—— 它捕不到TimeoutError（它是Exception的子类，但常被忽略） - 推荐写法：
except asyncio.TimeoutError:单独分支，语义清晰、意图明确 - 若需兜底，再加一层
except Exception:，但 TimeoutError 必须优先处理
确保超时后任务真正取消
wait_for 触发超时时，默认会取消被等待的协程任务；但前提是该协程能响应取消信号。否则任务还在后台跑，消耗资源。
- 协程内部要定期检查取消状态：
if asyncio.current_task().cancelled(): return - 避免使用阻塞调用（如
time.sleep），改用await asyncio.sleep() - 对 I/O 操作（如 HTTP 请求、数据库查询），选用支持取消的异步库（如
aiohttp、asyncpg） - 用
async with管理连接/锁等资源，保证取消时自动释放
标准化超时响应格式
不同模块超时后返回的内容不一致（有的返回 None，有的抛自定义异常，有的返回字符串），会让上层调用方难以统一处理。
- 定义统一的超时结果类型：比如返回
{"status": "timeout", "detail": "api_call"} - 或统一抛出带上下文的自定义异常：
class OperationTimeoutError(Exception): pass - 在网关、API 层统一转换：把原始
TimeoutError转为 HTTP 408 或业务错误码，附带可读提示
区分场景设置差异化超时值
不是所有操作都该用同一个 timeout 值。硬编码固定值（如全设 5 秒）容易导致误判或浪费等待时间。
- 内部服务调用：1–2 秒（网络延迟低，失败应快速反馈）
- 第三方 API：根据 SLA 设置（如支付接口 15 秒，天气接口 3 秒）
- 用户触发的复杂任务：支持传入
deadline参数，由调用方控制 - 关键路径操作（如鉴权）建议更短，非关键路径（如日志上报）可设为可选超时或无超时
