正确方案是后端通过 HttpOnly + Secure Cookie 存储 Token，前端不可读取；layui.escape() 仅转义 HTML 字符，无法防护 XSS 窃取凭据，因凭据存储本身就不应在前端。
不能用 layui 或任何前端框架安全存储高敏感凭据——这是设计边界问题，不是 API 能解决的。 layui 本身不提供防 XSS 的凭据存储能力，localStorage、sessionStorage、甚至非 HttpOnly 的 Cookie 都会被任意脚本读取。真正能防 XSS 窃取的，只有后端可控的 HttpOnly + Secure Cookie。
为什么 layui.escape() 和前端转义对凭据存储完全无效
layui.util.escape() 只做 HTML 字符转义（如把 变成 ），用于渲染用户输入内容到 DOM 时防反射型/存储型 XSS。但它不阻止脚本访问本地存储——攻击者写一段 document.cookie 或 localStorage.getItem('token') 就能直接拿走凭据，根本不需要构造 <script></script> 标签。
- 它只在「渲染环节」起作用，而凭据泄露发生在「存储与读取环节」
- layui 没有提供加密存储、内存隔离或自动销毁机制
- 哪怕你用
escape()处理过 token 字符串再存进localStorage，攻击者照样能原样取出来
真正有效的方案：绕过前端存储，让凭据根本不落地到 JS 可见域
核心思路是——让敏感凭据（如 JWT、session ID）从不出现在前端 JavaScript 的运行环境中。
- 后端设置
HttpOnly+Secure+SameSite=StrictCookie，例如 Node.js 中：res.cookie('auth_token', token, { httpOnly: true, secure: true, sameSite: 'strict', maxAge: 3600000 }) - 前端发起请求时，浏览器自动携带该 Cookie，无需
fetch手动传 token - 前端代码完全不调用
document.cookie、localStorage.setItem或任何凭据读写操作 - 若必须前端临时持有（如跨域调试、无后端配合场景），只能存在内存变量中，且禁止页面跳转或刷新——因为刷新即丢失
如果硬要“前端存”，这些做法只会让你更危险
以下常见误区在真实项目里高频出现，但每一种都会让凭据暴露面扩大：
- 用
localStorage存 token 后，再用layui.util.escape()包裹显示逻辑——escape()不影响存储本身，攻击者仍可localStorage.getItem('token') - 把 token 拆成多段存在不同 key 下（如
tkn_a+tkn_b）——JS 仍可拼接，且增加维护成本 - 用 AES 在前端加密后再存入
localStorage——密钥必然写在前端代码里，等于没加密 - 依赖
sessionStorage声称“关掉标签页就没了”——同一标签页内所有脚本仍可随时读取，XSS 攻击不关心你是否刷新
最常被忽略的一点：只要凭据出现在前端 JS 可读的存储介质里，它就已脱离服务端控制。XSS 攻击不是“能不能防住”，而是“有没有给攻击者留门”。真正的防线不在 layui，而在后端 Cookie 设置和请求链路设计上。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
