table.reloadData()仅更新数据不重置索引和分页状态，适合同页内数据变更；table.reload()则完整重载并重建cache与LAY_INDEX，适用于需重置上下文的场景。
table.reloadData() 只更新数据，不重置索引和分页状态
当你只想换掉表格里的内容，比如筛选后刷新当前页数据、编辑完某行后局部更新，table.reloaddata() 是最轻量的选择。它不会重新请求接口（除非你显式传了 url），也不会重置当前页码、表头配置或 lay_index 行索引——但这也正是最大隐患。
- ✅ 适合场景：同页内数据变更（如状态切换、排序后重排）、配合
cache手动维护的行移动操作 - ❌ 常见错误：调用后发现
obj.tr.data('index')拿不到值，或双击编辑时找不到原始行 —— 因为reloadData不会重建LAY_INDEX字段 - ⚠️ 注意：如果服务端返回的数据结构没带原始
id或唯一键，树形表格（treeTable）的展开状态也可能丢失，必须配expandStatus: true且确保id字段稳定
table.reload() 会完整重载，但参数行为随版本变化大
table.reload() 看似“更彻底”，实际行为在 Layui 2.6 前后截然不同，很多线上 bug 都源于没意识到这点。
- ? 2.6 之前：默认深度合并参数，多次调用会导致
where里字段越叠越多，分页page.curr被覆盖成 1，后端收一堆异常查询 - ? 2.6+：默认
deep: false，即每次重载都以新传入参数为准，旧参数清空 —— 更符合直觉，但也意味着你不能再依赖“自动继承上次搜索条件” - ? 兼容老逻辑？可以手动加
true第三参数：table.reload('test', { where: {...} }, true)，强制走深度合并
什么时候该用 reload，什么时候该用 reloadData
别凭感觉选，看操作是否需要“重置上下文”。
- 用
reload：用户点了「重置筛选」按钮、切换了 Tab 导致查询条件全变、分页跳转后要拉新数据 —— 这些都需要清掉旧缓存、重走初始化流程 - 用
reloadData：拖拽调整行顺序后同步视图、批量修改几行状态后仅刷新这几行、弹窗编辑保存后只更新对应那一行 DOM —— 此时你已手动维护好table.cache，不需要框架再帮你生成一遍 - ? 关键区别：前者会触发
done回调并重绘整个表格；后者只替换tbody内容，done不执行，滚动条默认回到顶部（树表需加scrollPos: "fixed"）
最容易被忽略的细节：cache 和 LAY_INDEX 的生命周期
很多人以为 reload 就是“安全牌”，结果在 2.7+ 版本里发现行索引又丢了 —— 其实不是方法问题，是没理解 table.cache 的作用边界。
-
reload会清空并重建table.cache[id]，同时给每行打上新的LAY_INDEX -
reloadData默认复用旧cache，但如果传了data参数，它会直接用你给的数据覆盖 cache，而不会补LAY_INDEX - 所以如果你手动拼了个新
data数组传给reloadData，记得自己加LAY_INDEX字段，或者用table.clearCacheKey(newData)清掉干扰字段再传
真正麻烦的从来不是哪个方法“更好用”，而是你有没有在调用前，想清楚这一行数据在 cache 里长什么样、在 DOM 上靠什么定位、在业务逻辑里靠什么关联。
