I1.06.1per-operation timeout设计
超时时长需按操作类型分别设定
别名: 分类超时 · timeout by action type · 一刀切超时
概念解释
搜索建议 3 秒还没回来，可以判超时；导出一份年报 3 秒还没回来，判超时就是错的。超时时长按操作类型分别设定，指每一种用户意图有自己的「再等就不合理」的钟，而不是全站一个 30 秒。钟要对着意图的合理工期，不是对着网关的默认值。
超时不是性能指标，是放弃等待的合法时刻。设错了，要么把还能成功的长任务杀掉，要么让已经死掉的短请求空转。
机制
人对不同操作带着不同的工期模型。读一条消息、点一个喜欢，模型是瞬间；生成视频、跑一次对账，模型是分钟。超时若短于模型，会被体验成系统不耐烦；超时若远长于模型，会被体验成死了还不说。网关、负载均衡、浏览器各有默认超时，那些默认是为保护服务器连接池，不是为对齐用户模型。两套钟叠在一起时，用户看到的是先响的那一只——往往是最粗的那只全局默认。
操作类型还要按失败代价分。幂等的读可以短；写、支付、投递一旦被超时切断，可能已经在服务端做成了，客户端却当成没做成。这类操作的超时要更长，并且与重试策略绑在一起，不能只改一个数字。
边界
同一入口若有时是读有时是写（「保存」有时只打本地、有时要过审核），不能共用一只钟，要按实际走的那条路径选。用户明确知道在跑批处理时，超时可以放到会话级，甚至不超时只给取消。极端弱网下任何短超时都会误杀，需要按网络质量抬钟，而不是按操作类型一条路走到黑。客户端超时和服务端超时必须谁短谁负责善后，否则两边都以为对方还在做。
怎么落地
- 给每类用户意图列一张表：读详情、搜索、提交表单、导出、支付、上传，各写超时和超时后的用户可见结果。
- 不要沿用网关 30 秒作为产品超时。网关钟可以更长，产品钟按意图更短或更长。
- 写操作的超时要长于读，并且超时文案不能说「未提交」——可能已经提交。
- 验证：把三类操作（瞬时读、表单写、长导出）都人为拖过各自的钟。短读应先结束等待；导出不应在 3 秒被杀；支付超时后界面不得断言「没扣款」。