用户反馈页面一直转圈。排查发现导出报表接口响应 20s但前端统一超时 15s直接断了。加大超时简单但粗暴——所有接口都变成 30s 超时普通查询也要等 30s 才报错体验更差。我让 AI 帮我设计了一个动态超时策略根据接口类型自动适配。问题分析接口类型 实际响应时间 统一 15s 超时的问题 ────────── ────────── ────────────────── 普通查询 200ms-2s 正常 列表分页 500ms-5s 正常 复杂查询 3s-8s 正常 导出小数据量 5s-15s 偶尔超时 导出大数据量 15s-60s 必然超时 ❌ 文件上传 10s-120s 必然超时 ❌ 批量操作 5s-30s 经常超时 ❌不同接口需要不同的超时时间但又不想每个接口调用时手动传。AI 设计的方案3 层超时策略优先级高→低 Layer 1: 接口级覆盖单个接口指定 ↓ 没指定则走 Layer 2: 场景级默认按 API 类型分类 ↓ 没匹配则走 Layer 3: 全局默认15s// 超时策略配置constTIMEOUT_STRATEGY{// 全局默认default:15_000,// 场景级scenes:{query:15_000,// 普通查询list:20_000,// 列表请求mutation:20_000,// 增删改export:120_000,// 导出upload:180_000,// 上传batch:60_000,// 批量操作},// 接口级覆盖特殊接口overrides:{/report/export/full:300_000,// 全量报表5min/goods/batch-import:180_000,// 商品批量导入},}核心实现请求拦截器constgetTimeout(config:AxiosRequestConfig):number{consturlconfig.url||// Layer 1: 接口级覆盖config 里手动传的if(config.timeout)returnconfig.timeout// Layer 2: 接口路径匹配constoverrideObject.entries(TIMEOUT_STRATEGY.overrides).find(([path])url.includes(path))if(override)returnoverride[1]// Layer 3: 场景推断constsceneinferScene(config)returnTIMEOUT_STRATEGY.scenes[scene]||TIMEOUT_STRATEGY.default}constinferScene(config:AxiosRequestConfig):string{const{url,method,responseType}config// 导出类responseType 为 blob 或 URL 包含 exportif(responseTypeblob||url.includes(export))returnexport// 上传类Content-Type 包含 multipartif(config.headers?.[Content-Type]?.includes(multipart))returnupload// 批量操作URL 包含 batchif(url.includes(batch))returnbatch// 列表类URL 包含 list/page 且为 GETif(methodget/\/(list|page)/.test(url))returnlist// 增删改if([post,put,delete].includes(method||))returnmutation// 默认查询returnquery}关键设计不需要改任何现有代码。现有的接口调用完全不用动拦截器自动推断超时时间。使用方式// 普通使用——自动推断大部分场景exportconstgetStoreList(params)request.get(/store/list,{params})// → 自动匹配 list 场景20s 超时// 导出——自动识别exportconstexportReport(params)request.get(/report/export,{params,responseType:blob})// → 自动匹配 export 场景120s 超时// 特殊接口——手动覆盖exportconstexportFullReport(params)request.get(/report/export/full,{params,responseType:blob,timeout:300_000})// → Layer 1 手动指定5minAI 帮我发现的额外优化点对话过程中AI 还建议了两个我没想到的优化1. 超时 ≠ 报错给用户进度感知// 对于已知耗时长的操作显示进度提示constexportWithProgressasync(params){consthidemessage.loading(正在生成报表数据量较大请耐心等待...,0)try{returnawaitrequest.get(/report/export,{params,responseType:blob,})}finally{hide()}}2. 超时后的重试策略不同// 普通查询超时静默重试 1 次// 导出超时提示用户数据量大是否继续等待// 上传超时不重试提示检查网络consthandleTimeout(config:AxiosRequestConfig,error:AxiosError){constsceneinferScene(config)switch(scene){casequery:caselist:returnretryOnce(config)// 静默重试caseexport:returnconfirmRetry(报表生成中是否继续等待,config,300_000)caseupload:message.error(上传超时请检查网络后重试)returnPromise.reject(error)default:message.error(请求超时请稍后重试)returnPromise.reject(error)}}效果优化前 ├── 导出接口超时率 35%用户点击后无响应 → 以为卡死 → 重复点击 ├── 批量操作超时率 15% ├── 用户投诉每周 8-10 条页面卡死 优化后 ├── 导出接口超时率 2%剩余是真的后端慢需要优化 ├── 批量操作超时率 0% ├── 用户投诉每周 3-4 条减少 60% ├── 额外收益定位到 5 个真正需要后端优化的接口什么时候需要动态超时需要的信号 ├── 有导出/上传等长耗时接口 ├── 经常收到超时报错 ├── 不同接口耗时差异大200ms vs 60s └── 统一超时值怎么调都不合适 不需要的 ├── 所有接口 5s 就能响应 ├── 后端保证响应时间 SLA └── 项目小接口少于 20 个 你们项目的接口超时是怎么设置的有没有遇到过超时导致体验差的问题完整 Skills 源码已开源github.com/sleepyccat/ai-native-workflow欢迎 Star ⭐ 和 PR。