timeout参数需在uni.request中直接设为数字（如timeout: 5000）才生效，覆盖全局配置；manifest.json中networkTimeout为全局兜底但需重启项目生效；H5平台timeout仅提示不中断请求；uni.uploadFile不支持timeout，应改用uni.request手动上传。
uni.request 的 timeout 参数怎么用才生效
直接在 uni.request 里写 timeout: 5000 是最简单也最可靠的设置方式，它会覆盖全局配置，且无需重启项目。但注意：这个参数只对当前请求起作用，且必须是数字（单位毫秒），不能传字符串或变量未定义值。
- ✅ 正确写法：
timeout: 5000或timeout: options.timeout ?? 8000 - ❌ 常见失效原因：传了
"5000"（字符串）、写了timeout: null、或者在 H5 平台误以为能控制 fetch 底层超时（实际由浏览器决定，timeout在 H5 仅作提示，不中断请求） - ⚠️ 特别注意：微信小程序中，若服务端响应头含
Connection: close，有时会触发底层 socket 异常，导致fail回调里报request:fail timeout，但真实是连接被主动断开，不是真超时
manifest.json 里的 networkTimeout 到底管不管用
networkTimeout 是全局兜底配置，写在 manifest.json 的源码视图里，对所有未显式设 timeout 的 uni.request 生效。但它有个硬限制：修改后必须**重启整个 uni-app 项目（包括 HBuilderX 或命令行服务）才生效**，热重载不识别。
- ✅ 正确位置：与
"name"、"appid"同级，结构为"networkTimeout": { "request": 10000 } - ❌ 错误操作：在可视化配置页改（那里没有该选项）、写成
networktimeout（大小写敏感）、漏掉外层大括号 - ⚠️ 兼容性提醒：iOS 真机上，即使设了
networkTimeout，某些系统版本仍可能因 NSURLSession 底层行为导致实际超时略长（比如标 10s，实测 12–13s），建议留 1–2 秒余量
为什么 fail 回调里判断 errMsg === 'request:fail timeout' 有时不触发
这不是 bug，而是 uni-app 对不同平台错误归因的差异。Android 和微信小程序基本稳定返回该字符串；但 H5 下多数情况不会进 fail，而是走 success 但 res.statusCode === 0；而 iOS 真机偶尔会返回 request:fail abort 或 request:fail net::ERR_CONNECTION_TIMED_OUT。
- ✅ 推荐判断方式：
if (err.errMsg?.includes('timeout') || res?.statusCode === 0) - ✅ 补充逻辑：在
complete回调里统一加时间戳比对，避免依赖平台不一致的错误码 - ⚠️ 容易忽略：如果请求发出去后页面跳转或组件销毁，部分平台（尤其是支付宝小程序）可能直接丢弃回调，导致超时无感知——必须在发起前绑定生命周期钩子做清理
上传文件时 timeout 不生效？因为 uni.uploadFile 根本不支持
uni.uploadFile 的 API 设计里压根没有 timeout 字段，文档和源码都确认过。你给它传了也会被忽略。官方推荐方案是：**别用它，改用 uni.request 手动构造 multipart/form-data 请求**。
- ✅ 可行做法：用
uni.getFileSystemManager().readFile读取文件二进制，再用uni.request+header: {'Content-Type': 'multipart/form-data; boundary=xxx'}发送 - ✅ 超时控制：此时
timeout完全可用，还能配合onUploadProgress做进度+超时双控 - ⚠️ 真实体验坑：iOS 上传大文件（>10MB）时，即使设了 30s timeout，系统也可能在 15s 左右静默终止连接，建议服务端同步做分片上传适配
实际项目里，超时不是设个数字就完事——它连着错误恢复策略、用户等待耐心、服务端处理能力三者。最麻烦的往往不是怎么设，而是设完之后没人监听 complete 回调里的状态，结果 loading 一直转，用户以为卡死了。
