table.set()仅影响table请求且需在render前调用，可设全局默认headers；多表格差异化需配合render中headers参数（合并生效）；同名header以render配置优先。
table.set() 只影响 table 请求，不污染全局
如果你只想给 table 组件加请求头，且不同表格要配不同 headers，table.set() 是最干净的选择。它只修改 table 模块内部的默认配置，不影响 form、layer 或手动 $.get 等其他请求。
注意：它必须在 table.render() 之前调用，且每次调用会覆盖前一次设置 —— 所以不能靠它实现“多表格不同 headers”。真要差异化，得配合 render 时的 headers 参数单独设：
-
table.set({ headers: { 'X-Source': 'admin-table' } })→ 全局 table 默认带这个头 - 某个特定表格想额外加
Authorization，直接在render里写：headers: { 'Authorization': 'Bearer ' + localStorage.getItem('token') }，它会合并（非覆盖）table.set()的配置 - 如果
table.set()和render都设了同名 header（比如都设了Content-Type），render里的值优先生效
ajaxPrefilter 是唯一能动态注入 token 的方式
$.ajaxSetup() 看似简单，但在 Layui 1.x 中经常失效 —— 因为 Layui 内部有时绕过 jQuery 的标准流程，或模块加载顺序导致 setup 被后加载的代码覆盖。真正稳定可靠的方案是 $.ajaxPrefilter()：
- 它在每次请求发出前触发，可读取
localStorage或sessionStorage中的token并动态塞进headers - 必须显式判断请求是否发往你的 API 域名，避免把 token 错带到第三方资源（如 CDN 图片、统计脚本）：
if (options.url.indexOf('/api/') === 0) { options.headers.Authorization = 'Bearer ' + token } - 它不处理响应，所以 401 拦截得另配
$.ajaxComplete()，且要过滤掉非 API 请求（比如layui.css加载）
手动调用 $.ajax 时 contentType 不匹配会导致 headers 丢失
当你在 table.render() 里设 method: 'post'，又没指定 contentType，jQuery 默认用 application/x-www-form-urlencoded 编码 data 对象。但很多后端 JWT 校验逻辑只检查 application/json 请求头下的 Authorization —— 这时 headers 看似传了，实际被忽略。
解决方法只有两个：
- 后端统一支持两种 content-type 下的 token 提取（推荐）
- 前端强制指定：
contentType: 'application/json'，同时手动JSON.stringify(data)，否则后端收不到原始字段 - 如果用的是
where参数（非data），Layui 会自动拼 query string，此时contentType无效，headers 依然生效 —— 但这是 GET 行为，不适合敏感参数
跨域请求下 headers 必须由后端显式放行
哪怕你用 ajaxPrefilter 成功加了 Authorization，浏览器仍会在预检（OPTIONS）阶段拦住请求，报错类似 No 'Access-Control-Allow-Headers' header is present。这不是前端能绕过的。
后端必须在响应头中明确列出你用的自定义头：
Access-Control-Allow-Headers: Authorization, X-Request-From, Content-Type- 如果带
credentials: true（比如要传 cookie），Access-Control-Allow-Origin不能是*，必须写具体域名 - 本地开发时，别试
--disable-web-security，它会让后续调试失真；用 nginx 或local-web-server做反向代理更接近生产环境
header 设置本身不难，难的是它和后端 CORS 配置、content-type 类型、token 存储时机这三者必须咬合。漏掉任意一环，控制台就只会显示一个静默失败的 pending 请求。
