layui table的page事件监听分页参数更新后、数据请求前的时机，回调参数为{curr, limit}，用于拦截或修改请求；需在render的done回调中用this绑定，且仅对服务端分页生效。
layui table 的 page 事件不是点击事件，别当 UI 事件用
page 事件触发时机是：分页参数（curr 和 limit）已更新、但新数据尚未发出请求——这是你拦截或改写请求的最后机会。它不响应“点击下一页”这个动作本身，而是响应表格内部完成参数计算后的钩子。
常见错误是把它当成 click 事件来监听，比如在回调里弹个 alert('翻页了')，结果发现点一次弹两次，或者根本没反应。这是因为表格默认会自动重载，你又手动调了 table.reload()，造成重复请求。
- 必须在
render的done回调中用this绑定，否则this指向不对，拿不到实例 - 只对服务端分页生效（即配置了
url），前端分页（只传data）不会触发 - 回调参数只有
{curr, limit}，不是完整实例，不能调this.config.url或其他方法 - 想取消默认请求？直接
return false，然后自己调table.reload()并传入修改后的where
request 对象必须显式声明，否则参数名永远是 curr/limit
Layui 2.8 默认发的是 curr=1&limit=10，不是旧版的 page/limit，更不是后端常见的 pageNum/pageSize。不配 request，请求参数名就固定为默认值，后端收不到对应字段。
常见错误是只写 page: true 就以为分页能通——其实只是启用了分页 UI，参数名仍按默认走。
-
request必须是对象，字段名严格区分大小写：pageName不等于pagename - Spring Boot 后端？写
request: { pageName: 'pageNum', limitName: 'pageSize' } - ThinkPHP 后端？写
request: { pageName: 'page', limitName: 'listrows' } -
where和request完全独立：where是业务参数（如搜索条件），request只管分页字段名
reload 时 request 不继承，漏传就会沿用初始化配置
table.reload('id', { where: {} }) 不会自动继承或覆盖 request，它只合并你传入的字段。没传 request，就继续用初始化时那一套——这是最常被忽略的坑。
比如你初始化时写了 request: { pageName: 'currentPage' }，但 reload 时只传了 where，那这次请求还是发 currentPage=2；可如果后端这次期望的是 pageNum，接口就直接 400 了。
- 每次
reload都要显式重传request，哪怕和初始化一样 - 建议封装一个默认配置对象，比如
const defaultRequest = { pageName: 'pageNum', limitName: 'pageSize' }，所有 render 和 reload 都引用它 - 不要依赖
table.setOptions做全局修改——它不支持request和parseData这类通信层配置
真正可靠的拦截点：beforeSend + 自定义 response
如果你需要在请求发出前动态改参（比如加 token、拼接租户 ID、根据权限过滤字段），page 事件和 where 都不够用——因为它们不触碰请求本身。Layui 2.8+ 提供了 beforeSend 和 response 配置，这才是真正的请求层拦截点。
beforeSend 在请求发出前拿到原始 config 对象，你可以直接改 config.data 或 config.headers；response 则控制响应体结构映射，配合 parseData 做最终解析。
-
beforeSend不是改where的地方，where是渲染层逻辑，beforeSend是请求层逻辑 - 示例：在
beforeSend中给所有请求加 header：config.headers = { 'X-Tenant-ID': localStorage.getItem('tenant') } - 注意：
beforeSend返回值不会影响请求是否发出，它只是让你有机会干预请求对象 - 如果你用 axios/fetch 替代 layui 内置请求，那就完全绕过这些限制，但得自己接管分页状态和重载逻辑
