应于laypage.jump的!first分支中同步更新location.hash,解析现有hash并合并page参数;监听hashchange事件,在table.reload的done回调中确保hash同步,避免UI与地址栏不一致。
每次页码切换都该主动写 hash,否则用户刷新页面会丢失当前页。Layui 的 jump 回调是唯一可靠入口,但必须判 !first,否则首次渲染就写一次 hash,导致地址栏多出一个 #/page=1(实际还没用户操作)。
if (!first) 分支里执行 location.hash = '#/page=' + obj.curr
history.pushState() —— Layui 2.8 默认依赖 hash 路由,pushState 会绕过 layui.router() 解析逻辑,后续监听失效#/user/list?page=2),不要粗暴覆盖整个 hash,应先用 layui.router() 解析,再 merge page 字段后拼回:location.hash = '#/' + path.join('/') + '?' + $.param(Object.assign({}, search, { page: obj.curr }))
用户手动改地址栏 hash 或点浏览器前进/后退时,layui.router() 不会自动触发分页重载,得自己监听 hashchange 并调 table.reload() 或 laypage.render()。
index.html#/page=3)layui.router() 返回的 search.page 是字符串,要 parseInt() 再传给 page.curr,否则 table.reload() 会静默 fallback 到第 1 页table.reload({ page: { curr: pageNum } }),它会自动同步底层 laypage 实例;单独 laypage 则需完整配置重 render常见现象:点了页码,表格数据刷新了,但地址栏 hash 还是旧的。根本原因不是 hash 写失败,而是 reload 触发时机早于 jump 回调。
table.reload() 本身不触发 jump,所以你不能指望它自动更新 hash —— 必须在 reload 的 done 回调里手动写 hashpage: { hash: true }(Layui 2.8+ 新增选项),它会自动管理 hash,但仅限基础 page 参数;自定义参数(如 category=2)仍需手动拼接page)时,后 reload 的会覆盖前者的 hash 值,建议按表格 ID 区分:用 search.table1_page 和 search.table2_page
Layui 的分页组件不监听 hash 变化,它只管自己内部状态。你手动改 hash,laypage 的 curr 还是原来的值,UI 不会重绘,直到你显式调 laypage.render() 或 table.reload()。
laypage.getElem('id').curr = 5 强行改状态 —— 这个属性只读,改了也不触发 UI 更新hashchange → 解析新页码 → 调 table.reload({ page: { curr: newPage } }) → 在 reload 的 done 里确认 hash 已同步#/order/list?status=done&page=2)建议封装一个 syncHashToTable() 函数,统一处理 path、search、page 映射,避免每个表格重复写解析逻辑layui.router() 解出来的 page 值必须在 render 前就塞进配置里,否则第一页就错了。