应于laypage.jump的!first分支中同步更新location.hash，解析现有hash并合并page参数；监听hashchange事件，在table.reload的done回调中确保hash同步，避免ui与地址栏不一致。
laypage.jump 里怎么同步更新 location.hash
每次页码切换都该主动写 hash，否则用户刷新页面会丢失当前页。Layui 的 jump 回调是唯一可靠入口，但必须判 !first，否则首次渲染就写一次 hash，导致地址栏多出一个 #/page=1（实际还没用户操作）。
- 只在
if (!first)分支里执行location.hash = '#/page=' + obj.curr - 别用
history.pushState()—— Layui 2.8 默认依赖 hash 路由，pushState会绕过layui.router()解析逻辑，后续监听失效 - 如果已有其他 hash 参数（如
#/user/list?page=2），不要粗暴覆盖整个 hash，应先用layui.router()解析，再 merge page 字段后拼回：location.hash = '#/' + path.join('/') + '?' + $.param(Object.assign({}, search, { page: obj.curr }))
如何监听 hash 变化并触发分页跳转
用户手动改地址栏 hash 或点浏览器前进/后退时，layui.router() 不会自动触发分页重载，得自己监听 hashchange 并调 table.reload() 或 laypage.render()。
在SEO发布前，从路由清单生成XML网站地图和robots.txt
下载
当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。
- 监听事件必须在 laypage 初始化前注册，否则可能漏掉首次 hash 加载（比如用户直接访问
index.html#/page=3） - 从
layui.router()返回的search.page是字符串，要parseInt()再传给page.curr，否则table.reload()会静默 fallback 到第 1 页 - 若同时用了表格分页和独立 laypage，优先走
table.reload({ page: { curr: pageNum } })，它会自动同步底层 laypage 实例；单独 laypage 则需完整配置重 render
table.reload 后 hash 没变？检查这几个点
常见现象：点了页码，表格数据刷新了，但地址栏 hash 还是旧的。根本原因不是 hash 写失败，而是 reload 触发时机早于 jump 回调。
-
table.reload()本身不触发jump，所以你不能指望它自动更新 hash —— 必须在 reload 的done回调里手动写 hash - 如果表格启用了
page: { hash: true }（Layui 2.8+ 新增选项），它会自动管理 hash，但仅限基础page参数；自定义参数（如category=2）仍需手动拼接 - 多个表格共用一个 hash 参数名（如都用
page）时，后 reload 的会覆盖前者的 hash 值，建议按表格 ID 区分：用search.table1_page和search.table2_page
为什么直接改 location.hash 后 laypage 不响应
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 前就塞进配置里，否则第一页就错了。
