table.render 的 headers 必须显式传 plain object（如 {authorization: 'bearer xxx'}）才生效；table.set() 仅全局兜底且后调用覆盖前调用，不支持按表区分；upload 需在 before 回调中动态设 this.headers；三者 header 机制完全独立，无法互通。
table.render 的 headers 参数必须显式传对象
直接写 headers: {Authorization: 'Bearer xxx'} 才生效，table.set({headers: {...}}) 虽然能设全局默认值，但只在调用后、render() 前生效，且会被单个表格的 headers 配置完全覆盖——不是合并，是替换。
常见错误是以为 table.set() 一设就全局管用，结果多个表格混用时，只有最后一个 table.set() 生效；或者误把 headers 写成字符串或数组，导致请求头根本不出去。
-
headers必须是 plain object，不能是函数或 null -
token 值建议每次渲染前动态读取：
localStorage.getItem('access_token')，避免页面加载早于登录完成导致为空 - 如果后端要求的是
X-Access-Token或access-token，就按实际字段名写，别硬套Authorization - POST 请求下，若同时设了
contentType: 'application/json'，确保后端能正确解析带 header 的 JSON 请求（有些拦截器只校验特定 content-type 下的 header）
table.set() 只能设一次，且不支持差异化
table.set() 是全局兜底方案，适合所有表格共用同一类 token（比如固定测试环境 token），但它没有“按表区分”的能力。一旦你调用两次 table.set()，第二次会彻底覆盖第一次的配置。
如果你有用户列表页、日志页、监控页三个表格，分别需要不同来源的 token（如 localStorage、sessionStorage、硬编码测试值），就必须放弃 table.set()，全部改用 render() 中的 headers 字段单独配。
- 不要在循环里反复调用
table.set() -
table.set()必须在任何table.render()之前执行，否则无效 - 它不影响
form.submit()、$.get()等非 table 模块发起的请求
上传组件 upload 的 headers 和 table 完全不互通
upload.render() 底层不走 jQuery AJAX，而是原生 XMLHttpRequest + FormData，所以 $.ajaxPrefilter、table.set()、render.headers 对它全部无效。这是最常踩的坑——照搬 table 写法，上传请求始终没带 token。
唯一可靠方式是在 before 回调里给 this.headers 赋值，且必须每次上传前都读 token：
- 在
before中写：this.headers = {'Authorization': 'Bearer ' + localStorage.getItem('token')} - 不要手动设置
Content-Type，浏览器会自动设为multipart/form-data，硬写application/json会导致后端解析失败 - 如果 token 会刷新（如 JWT 过期续签），
before是唯一能保证用最新值的时机 - 跨域上传时，自定义 header 字段（如
X-Auth-Token）必须和服务端Access-Control-Allow-Headers白名单一致，否则预检（OPTIONS）被拦
GET 和 POST 下 headers 行为不一致
对 table.render() 来说，method: 'get' 时 headers 总是生效；但 method: 'post' 时，是否携带 header 取决于 contentType 设置和后端拦截逻辑。
例如：默认 contentType: 'application/x-www-form-urlencoded'，某些 Spring Security 配置只校验 application/json 请求头里的 Authorization，这时你得显式加上：
method: 'post',
contentType: 'application/json',
headers: {'Authorization': 'Bearer ' + token},
data: JSON.stringify({...})
- 不加
contentType时，jQuery 默认发 form-encoded，header 可能被后端忽略 - 加了
contentType: 'application/json'就必须自己JSON.stringify(data)，否则后端收不到 body - 如果后端用统一拦截器（如基于 RequestHeader 的 JwtFilter），通常对 GET/POST 一视同仁；但若用 @RequestBody + @RequestHeader 混合校验，POST 的 header 有效性更依赖前端 contentType 是否匹配
