layui表单提交不自动携带token,必须在form.on('submit')中阻止默认行为,用layui.admin.req或$.ajax手动发请求并显式设置headers;token应存于layui.data('platform'),读取需匹配存储位置,且必须走请求头而非data字段。
layui 表单提交本身不自动携带 token,必须手动注入到请求头或参数中;直接用 form.on('submit') 发起的原生 submit 事件不会走 layui.admin.req 或任何封装逻辑,token 不会自动附带——这是绝大多数人踩坑的起点。
form.on('submit') 提交时如何加 Token 到请求头
原生表单提交(form.on('submit(#formId)'))默认是同步 HTML 表单提交,不经过 JS 拦截,更不会自动塞 token。要实现带 token 的安全请求,必须阻止默认行为,改用 layui.admin.req 或 $.ajax 手动发请求。
- 在回调里第一时间调用
return false阻止页面跳转和默认提交 - 从
layui.data('platform')或sessionStorage.getItem('token')取 token(注意:Layui Admin 默认存于platform表名下,key 是access_token) - 使用
layui.admin.req发送,它会自动处理 headers、超时、错误跳转等;若不用 admin 模块,则用$.ajax并显式设置headers: { Authorization: 'Bearer ' + token } - 后端若要求
token字段而非Authorization,headers 写成{ token: token }即可,但需前后端约定一致
示例:
form.on('submit(save)', function(data){
const token = layui.data('platform').access_token;
if (!token) {
layer.msg('登录已失效,请重新登录');
return false;
}
layui.admin.req({
url: '/api/user/save',
type: 'POST',
data: data.field,
headers: { Authorization: 'Bearer ' + token },
done: function(res) {
if (res.code === 0) {
layer.msg('保存成功');
}
}
});
return false; // 必须返回 false,否则仍会触发原生提交
});
为什么不能在 form 标签里用 lay-headers?
lay-headers 是 table、upload、treeTable 等组件的专属属性,form 组件不支持该属性——Layui 的 form 模块没有解析 lay-headers 的逻辑,写了也无效。
- 试图在
<form lay-headers="{token:xxx}"></form>中写死 token,完全不起作用 - 哪怕 token 是动态模板变量(如
#{token}),Layui 的 form 渲染也不做任何替换或注入 - 唯一可控入口就是
form.on('submit')回调里的 JS 逻辑
Token 存哪里?取的时候容易出什么错?
Token 存储位置和读取方式不匹配,是 401 错误最常见原因。Layui Admin 默认用 layui.data('platform', {key: 'access_token', value: token}) 存,但很多开发者误用 localStorage.token 或 sessionStorage.getItem('token') 去读,结果读不到。
- 确认你用的是 Layui Admin 还是纯 Layui:Admin 版统一走
layui.data('platform');纯 Layui 需自己存取,推荐sessionStorage(关页即清) - 登录后立刻检查控制台:
layui.data('platform')是否有access_token字段;没有说明登录接口没正确调用layui.data写入 - 不要在页面加载时就取 token 并缓存到全局变量,因为登录可能是异步完成的;每次提交前实时取,才可靠
- 如果后端要求
Authorization: Bearer xxx,但前端拼成了Authorization: xxx,后端解析失败,返回 401 —— 注意格式细节
表单数据与 Token 的传参分工必须明确
Token 属于认证信息,必须走请求头(headers);业务字段(如 username、id)走请求体(data 或 field)。混在一起传,既违反 REST 规范,也容易被后端中间件拦截或忽略。
- 把 token 塞进
data.field.token是危险且低效的做法:可能被日志记录、被缓存、被 XSS 劫持 - 某些网关或 Spring Security 配置只从 header 解析认证信息,data 里的 token 直接被无视
- 如果后端同时支持 header 和 body 传 token,那只是兼容写法,不是推荐实践
真正需要关注的,是每次提交前能否拿到「最新、有效、格式正确」的 token —— 而不是想着怎么绕过 header 去“凑合”。











