timeout 不在 table.render 参数中，需通过全局 $.ajaxSetup 或 url 设为函数手动发带 timeout 的 $.ajax 请求；重试须手动实现，配合锁机制、递增延迟及严格数据格式校验。
timeout 设置在哪？不是 table.render 的参数
layui table.render() 本身不接受 timeout 参数，它底层调用的是 layui.jquery 封装的 $.ajax，所以超时控制必须绕过默认请求流程。直接写 timeout: 5000 在 render 配置里完全无效。
真正生效的方式只有两种：
- 全局配置：
$.ajaxSetup({ timeout: 6000 })—— 但 layui 2.8+ 在模块化环境里已不保证可靠，生产环境慎用 - 局部接管：
url设为函数，在里面手动发$.ajax({ url, timeout: 6000 })，再调obj.done()或obj.error()
重试逻辑不能靠 timeout 自动触发
timeout 只是中断当前请求，并不会自动重发。你得自己写重试：在 obj.error 回调里判断 textStatus === 'timeout'，然后延时再调一次手动请求。
常见错误是把重试塞进 setInterval 里硬刷——结果请求还没结束就又发一个，loading 状态堆叠、表格卡死、甚至报 Cannot read property 'appendChild' of null。
安全做法是用锁 + 延迟递归：
- 定义一个布尔变量如
let retrying = false - 在
obj.error里检查!retrying才执行重试 - 重试前设
retrying = true，成功或失败后恢复false - 重试间隔建议从
1000起步，最多叠加到3000，避免雪崩
重试时怎么避免重复渲染或状态错乱
每次重试都必须确保回填数据格式正确，否则表格会卡在 loading 或空白状态。返回值必须严格是：
{code: 0, count: 100, data: []}
漏掉 count 字段，分页器就显示异常；data 不是数组，列就全空；code 不是 0，done 就不触发。
还要注意：
- 别在重试函数里调
table.render()—— 会销毁实例，后续table.cache全失效 - 重试应复用原始
obj（含page、limit、where），否则翻页参数丢失 - 如果用了
height导致固定表头，重试后要手动同步.layui-table-fixed-l .layui-table-body里的内容，不然倒计时或按钮可能错位
移动端和弱网场景下的 timeout 与重试策略
PC 上设 timeout: 6000 可能刚好，但 4G 环境下这个值大概率触发假超时。真实 P95 响应时间若为 3200ms，timeout 设成 6500 更稳。
更关键的是重试间隔不能固定：
- 首次失败后等
1000ms重试 - 第二次失败等
2000ms - 第三次失败等
3000ms，之后不再重试，改显“网络异常，请重试”按钮
用户连续点击重试按钮时，必须加防抖（比如 1.5 秒内禁止重复触发），否则接口压力陡增，后端限流直接返回 429。
真正难的不是写几行重试代码，而是让 timeout、重试次数、间隔、UI 状态、表格实例生命周期全部对齐——漏掉任意一环，用户看到的就是“点了没反应”或者“点了变空白”。
