table.cache 是 Layui 表格渲染后自动维护的原始数据内存快照，仅在渲染完成后通过表格 ID（如 table.cache['test']）访问，分页/排序/搜索不改变其内容，修改后须调用 table.reloadData() 同步。
table.cache 是什么，什么时候能用
table.cache 不是“可选缓存”，而是 Layui 表格渲染后自动维护的内存快照——它存的是你传给 table.render() 的原始数据（或服务端返回的 data 字段），不是 DOM 状态。
它只在表格完成渲染后才可用，且必须通过表格 ID 访问：table.cache['test']，ID 必须和 render() 时配置的 id 完全一致。
- 渲染前访问
table.cache['test']→ 返回undefined或空对象 - 分页切换、排序、搜索后，
table.cache['test']始终是全部原始数据，不是当前页数据 - 想拿当前页数据？Layui 2.6.0+ 请改用
table.getData('test')；旧版本只能自己从table.cache里按page.curr和limit手动切片
修改 table.cache 后为什么表格没变
直接改 table.cache['test'] 数组（比如 push()、splice()）只是动了内存里的数据副本，layui 不会自动监听或响应这种变更。dom 还是老样子，后续 obj.data 拿到的仍是旧值。
- ✅ 正确做法：改完缓存后，必须调用
table.reloadData('test', { data: newCacheData }) - ❌ 错误写法：
table.cache['test'].push(newRow); table.reload('test');——reload()会重新请求接口，丢掉你刚塞进去的数据 - ⚠️ 注意：
reloadData()第二个参数里的data必须是完整新数组，不是差量；若含临时字段（如LAY_TABLE_INDEX），建议先过一遍table.clearCacheKey()过滤
哪些操作会悄悄污染 table.cache
table.cache 看似“只读”，但部分内置方法会隐式修改它，导致后续逻辑错乱：
-
obj.update({})：仅更新视图和缓存中对应行，安全 -
table.sort()：不更新table.cache，只影响当前渲染顺序 → 若你依赖缓存做后续计算，结果会和界面上看到的不一致 - 树形表格
treeTable：父子节点展开/折叠状态存在独立缓存，table.cache里只存扁平数据，别混用 - 使用
done回调手动改table.cache时，如果忘了深拷贝原始data，可能污染源数据（尤其多人共用一个数据数组时）
服务端缓存和前端 table.cache 是两回事
有人把 PHP 文件缓存（如 cache/data_cache.json）和 table.cache 搞混。前者是服务器磁盘上的数据快照，后者是浏览器内存里的 JS 对象，两者生命周期、作用域、更新方式完全隔离。
- 前端
table.cache刷新页面就消失，和服务端缓存无关 - 服务端缓存要自己控制过期（比如加时间戳字段）、清理（
unlink()）、权限校验（别让cache.php被公开访问） - AJAX 请求拿到服务端缓存数据后，仍需通过
table.reloadData()写入并同步到table.cache，不能跳过这步
table.cache 看着简单，但它是 Layui 表格所有动态操作的“事实源头”。动它之前，先想清楚：这次改动是只影响视图，还是会影响后续提交、导出、筛选？多数 bug 都出在“以为改了缓存就等于改了表格”，其实差了一次 reloadData。
