不是layui的bug，是后端未对URL参数调用encodeURIComponent编码或前端错误使用decodeURIComponent导致URIError；浏览器在JS执行早期解析location.search时即报错，代码根本未进入layui逻辑。
直接结论：不是 layui 的 bug，是后端返回的 URL 参数没做 encodeURIComponent 编码，或前端用错了解码方式。浏览器在自动解析 location.search 时就已报错，代码根本走不到 layui 的逻辑里。
为什么 layui 渲染前就崩了？
很多人以为是 layui.upload 或 layui.table 解析中文出错，其实不是。URIError 发生在 JS 执行早期——比如你在 location.search 上直接调用 decodeURIComponent，或在 URL 中拼了未编码的中文/含 % 的字符串，浏览器还没进 layui 就抛错了。
典型场景：
- 跳转链接写成
list.html?name=张三（没编码）→ 浏览器地址栏显示乱码，location.search取出来就是损坏的字符串 - 后端返回的 JSON 里带 URL 字段，如
{"url": "/detail?title=测试"}，前端直接window.location.href = res.url→ 同样触发 URIError - URL 中出现孤立
%，比如?desc=浓度:5.0%vol→decodeURIComponent遇到%v就拒绝解析
decodeURIComponent 报错时怎么安全解码
别让一个参数毁掉整个页面。所有从 URL 拿参数的地方，必须加 try/catch：
function safeDecodeURIComponent(str) {
try {
return decodeURIComponent(str);
} catch (e) {
console.warn('URI decode failed on:', str);
return str; // 返回原始值，避免后续逻辑中断
}
}
使用示例：
const name = safeDecodeURIComponent(new URLSearchParams(location.search).get('name') || '')- 不要用
location.search.substr(1).split('&').map(...)手动解析——它绕不过decodeURIComponent调用，且无法容错 - 优先用
URLSearchParams，它内部已做基础校验，比手撕字符串可靠得多
传参时该用 encodeURI 还是 encodeURIComponent？
简单记：只对「单个参数值」编码，一律用 encodeURIComponent；对完整 URL 地址编码，才考虑 encodeURI。
-
encodeURIComponent('张三')→%E5%BC%A0%E4%B8%89（正确） -
encodeURI('张三')→ 同样能工作，但若参数含/、?、&就会漏编，导致 URL 结构被破坏 -
encodeURIComponent('浓度:5.0%vol')→%E6%B5%93%E5%BA%A6%3A5.0%25vol（把%自动转成%25，这是关键） - 拼接时别手动加
?和&，用URLSearchParams更稳：const p = new URLSearchParams(); p.set('name', '张三'); p.set('desc', '5.0%vol');
后端返回的 URL 字段含中文怎么办？
常见于表格列渲染、按钮跳转链接等场景。后端返回的 url 字段如果含中文或特殊字符，前端不能直接赋值给 href 或 window.location。
- 后端应确保返回的 URL 已完成
encodeURIComponent（或等效处理），例如/detail?title=%E6%B5%8B%E8%AF%95 - 前端拿到后，先用
decodeURIComponent解一次再用 —— 但前提是后端真编码了。否则解出来还是乱码 - 更稳妥的做法：后端只返回原始参数，前端自己拼 URL：
`/detail?title=${encodeURIComponent(data.title)}` - Layui 表格中，
templet里写链接时，务必包裹encodeURIComponent：<a href="/detail?title='+%20encodeURIComponent(d.title)%20+'"></a>
最容易被忽略的一点：URIError 不是“解码失败”，而是“语法非法”。它不关心你有没有中文，只认 %xx 是否成对、是否合法 UTF-8 字节序列。所以排查顺序永远是：检查 URL 字符串本身 → 看有没有裸 % → 看有没有截断的编码（如 %e4%b8）→ 再看是不是用了 escape 这种过时 API。
