timeout必须在uni.request中直接设为数字（如timeout: 5000）才生效，覆盖全局配置且无需重启；manifest.json中networktimeout仅兜底，修改后须重启项目生效；h5平台timeout仅提示不中断请求，ios真机存在系统级超时偏差。
uni-app 的网络请求超时必须手动设 timeout，且只在 uni.request 调用时传数字才真正生效；全局配置 networkTimeout 仅兜底，改了要重启项目。
timeout 参数怎么写才不白设
直接在 uni.request 里写 timeout: 5000 是唯一稳定生效的方式。它覆盖全局配置，也不依赖平台重启。
- ✅ 正确：
timeout: 5000、timeout: options.timeout ?? 8000 - ❌ 失效常见原因：
timeout: "5000"（字符串）、timeout: null、timeout: undefined - H5 平台下该参数仅作提示，实际请求由浏览器 fetch 控制，不会中断；iOS/Android 端才真正起作用
- 微信小程序中若服务端返回
Connection: close，fail回调可能报request:fail timeout，但真实是连接被断开，不是超时
manifest.json 的 networkTimeout 什么时候管用
networkTimeout 是全局兜底值，只对没显式设 timeout 的请求生效，但它有硬性限制：修改后必须重启整个项目（HBuilderX 或命令行服务），热重载不识别。
- ✅ 正确位置：与
"name"、"appid"同级，结构为"networkTimeout": { "request": 10000 } - ❌ 常见错误：写成
networktimeout（大小写错）、漏掉外层大括号、在可视化配置页修改（那里没这个选项） - iOS 真机上，即使设了 10s，底层
NSURLSession可能导致实际超时达 12–13s，建议预留 1–2 秒余量
fail 回调里怎么判断真是超时
不能只靠 err.errMsg === 'request:fail timeout'，不同平台返回差异大：
- Android / 微信小程序：基本稳定返回该字符串
- H5：多数情况不进
fail，而是走success但res.statusCode === 0 - iOS 真机：偶尔返回
request:fail abort或request:fail net::ERR_CONNECTION_TIMED_OUT - 可靠做法是结合
err.errMsg?.includes('timeout')+res?.statusCode === 0综合判断
为什么不能直接封装个“自动重试3次”的函数就完事
因为 fail 触发的场景太多，不是所有失败都该重试：
- ✅ 可重试：网络断开、
request:fail timeout、502/503/504 - ❌ 不该重试：
401（token 过期）、400（参数错）、404（路径不存在）、证书错误（如net::ERR_CERT_AUTHORITY_INVALID） - 常见坑：用户输错密码，后端返回
401，前端却连发 3 次登录请求，导致账号被锁 - 重试前必须检查
err.errMsg和res?.statusCode，再决定是否重发
超时不是设个数字就完事，关键在「按接口类型分设」——login 接口可设 15s，uploadFile 可能得 120s，而轮播图接口 3s 就该失败并触发重试或降级。最容易被忽略的是：H5 下的 timeout 不中断请求，只提示；而 iOS 真机的系统级超时偏差，往往让测试时没问题，上线后弱网下突然卡住几秒才报错。
