应手动构造URL并跳转：取值→编码→导航，用encodeURIComponent()处理参数，新页面用URLSearchParams解析，表格初始化时将参数注入url或where选项。
搜索按钮点击后怎么跳转到新页面并带参数
不能靠 table.reload() 实现跨页跳转——它只刷新当前表格，不改变 URL，也不开新页。你要的是“用户点搜索，浏览器地址栏变掉”，就得手动构造 URL 并触发导航。
核心就三步：取值 → 编码 → 跳转。漏掉 encodeURIComponent()，中文或特殊字符一出现，后端就收不到完整参数。
- 用
$('#keyword').val()或表单data.field拿搜索值，别直接读 DOM 文本节点 - 所有参数必须
encodeURIComponent()，尤其是中文、空格、&、= 这类符号 - 跳转用
location.href或window.open()，不要用layui.router().href()——它不支持带参跳转到外部页面（非 layui 路由管理的页面） - 示例：
const keyword = $('#keyword').val().trim();<br>if (keyword) {<br> location.href = '/search-result.html?keyword=' + encodeURIComponent(keyword);<br>}
新页面怎么安全解析 URL 中的搜索参数
前端没框架帮你自动解 URL 参数，URLSearchParams 是最轻量、兼容性足够（IE 不支持，但 2026 年基本可忽略）的方案。别手写 split('?') 或正则，容易漏边界情况。
- 在新页面 JS 里直接用：
const params = new URLSearchParams(location.search);<br>const keyword = params.get('keyword') || ''; - 如果必须兼容老 IE，用函数封装：
function getUrlParam(name) {<br> const reg = new RegExp('(^|&)' + name + '=([^&]*)(&|$)');<br> const r = window.location.search.substr(1).match(reg);<br> return r ? decodeURIComponent(r[2]) : '';<br>} - 拿到参数后，别直接插进 HTML——先做基础校验：
if (!keyword || keyword.length > 100) return;，防 XSS 和后端查询爆炸
为什么不能用 localStorage 传搜索参数
看似简单，实则高危。多个标签页同时操作时，localStorage 是共享的，A 页存了 keyword，B 页点搜索覆盖掉，A 页新开的 Tab 就显示错结果。
- 用户开两个搜索页，先后输入“张三”“李四”，最终两个页面都可能显示“李四”的结果
- 页面刷新后
localStorage还在，但用户其实已经退出搜索上下文，造成状态残留 - 移动端 Safari 的无痕模式会禁用
localStorage，直接报错 - 真正干净的做法：参数只走 URL，新页面只从
location.search读——无共享、无残留、可 bookmark、可分享
跳转后表格初始化怎么带上搜索条件
新页面的 table.render() 不会自动读 URL 参数。你得手动把 keyword 塞进 where 或拼进 url 字符串里，否则表格还是拉全量数据。
- 推荐用函数式
url，动态拼参：url: function() {<br> return '/api/list?keyword=' + encodeURIComponent(keyword);<br>} - 如果用
where，确保初始化前已解析好参数：where: { keyword: keyword },<br>page: { curr: 1 } // 别忘了重置页码 - 注意：如果原表格用了
request自定义分页参数名（如pageNum），新页面也得保持一致，否则后端收不到 page 参数
URL 参数是唯一可靠、无状态、可追溯的跨页通信方式。任何绕开它的做法——无论是 localStorage、全局变量、还是靠 DOM 查找旧页面元素——都会在多标签、快速切换、刷新或并发操作时露出破绽。
