layui table.render() 中 timeout 参数无效，需通过 $.ajaxSetup 或手动接管请求实现；超时后需手写带锁重试逻辑，不可依赖自动重试。
layui table.render() 里直接写 timeout 参数无效
你填了 timeout: 6000 在 table.render() 配置对象里，表格照样不超时中断——因为这个参数根本不在 layui table 的公开配置项中。它底层调用的是 layui.jquery 封装的 $.ajax，但 table.render 并未透出 timeout 字段给用户。所有直接塞进去的 timeout 都会被静默忽略。
真正生效的两种方式：全局 $.ajaxSetup 或手动接管请求
必须绕过默认请求流程才能控制超时：
- 全局方式：
$.ajaxSetup({ timeout: 6000 })—— 但 layui 2.8+ 模块化环境下不可靠，多个模块共用时容易互相覆盖，生产环境慎用 - 推荐局部接管：把
url设为函数，在函数内用$.ajax({ url, timeout: 6000 })手动发请求，再调obj.done(data)或obj.error() - 注意：不能在
url函数里用fetch或原生XMLHttpRequest却不手动处理timeout，否则依然没效果
超时 ≠ 自动重试，重试必须手写且带锁机制
timeout 只是中断当前请求，不会触发下一次请求。常见错误是把 setInterval 塞进 error 回调里硬刷，结果 loading 状态堆叠、DOM 报错 Cannot read property 'appendChild' of null。
- 定义一个锁变量：
let retrying = false - 在
obj.error中先判断!retrying && textStatus === 'timeout'才执行重试 - 重试前设
retrying = true，成功或最终失败后恢复false - 延迟建议从
1000起步，最多递增至3000，避免雪崩
移动端和接口 SLA 要求不同，timeout 值不能一概而论
查列表接口通常 2–5 秒应返回，设 6000 较平衡；带复杂搜索或导出的接口可提到 15000。移动端更保守：
- Wi-Fi 下建议
8000 - 4G 下建议至少
12000 - 如果后端响应头有
X-Response-Time，取 P95 值 × 2 更合理
别依赖 timeout 当重试兜底——它只负责“断”，不负责“续”。真正的容错能力来自你写的那几行带锁的递归请求逻辑，而不是配置项本身。
