layui table跨域请求必须全局配置xhrFields: { withCredentials: true }，否则无法携带Cookie或token；后端需设置Access-Control-Allow-Origin为具体域名且Access-Control-Allow-Credentials: true；table.reload不继承xhrFields和request，须依赖$.ajaxSetup全局配置。
layui table 跨域请求必须配 xhrFields: { withCredentials: true }
不加这句，跨域请求永远带不上 Cookie 或认证头，后端拿不到 session 或 token。Layui 底层用的是 layui.jquery.ajax，它不会自动开启凭据传输，必须手动声明。
常见错误是只在 table.render() 里写 headers 或 contentType，但漏掉 xhrFields——这些都不影响凭据携带。
- 必须在
layui.use后、table.render前调用$.ajaxSetup({ xhrFields: { withCredentials: true } }) - 不能只对单个表格设，因为
table.reload()不继承xhrFields，必须靠全局 ajax 配置兜底 - 如果后端没配
Access-Control-Allow-Credentials: true，浏览器会直接拒绝响应，控制台报 “CORS header ‘Access-Control-Allow-Origin’ cannot be ‘*’ when credentials flag is true” - 后端
Access-Control-Allow-Origin必须写具体域名（如http://localhost:8080），不能写*
跨域时 request 和 where 仍按原逻辑工作
跨域不影响参数名映射或业务条件拼接，request: { pageName: 'pageNum', limitName: 'pageSize' } 和 where: () => ({ keyword: $('#kw').val() }) 照常生效。
容易混淆的点：有人以为加了 withCredentials 就要改 where 传 cookie，其实不用——cookie 是自动随请求发出的，where 只管业务字段（比如搜索词、状态筛选）。
-
where里的键名完全由你定，和后端接收字段一致即可，例如后端用q_status，就写{ q_status: 1 } -
request控制分页参数名，和跨域无关；但若后端跨域接口要求特定分页字段（如current_page），就得配request: { pageName: 'current_page' } - reload 时，
where函数会重新执行，所以推荐用函数形式，避免静态对象缓存旧值
跨域 + 分页 reload 容易漏掉的两个关键点
table.reload() 不会自动带上 xhrFields，也不自动重传 request，这两项都得靠前置配置或显式传参兜住。
- reload 时若没传
request，它沿用初始化时的request配置，不是默认值；但如果你初始化时根本没配request，那 reload 也还是发curr/limit - reload 时若想覆盖
where，必须显式传入，例如table.reload('id', { where: { keyword: '新关键词' } })；不传就不会更新 - reload 不触发
$.ajaxSetup重设，所以全局xhrFields必须在最外层一次性设置好，不能 reload 里再调一次$.ajaxSetup
开发阶段验证跨域分页是否生效的最快方法
别等页面全跑起来，直接看 Network 面板里翻页请求的 Request Headers 和 Response Headers。
- Request Headers 中必须有
Cookie（或Authorization）字段，且值非空 - Response Headers 中必须有
Access-Control-Allow-Origin（值为你的前端域名）和Access-Control-Allow-Credentials: true - 翻页 URL 参数名必须是你配的
pageName/limitName，不是默认curr/limit；否则说明request没生效或被覆盖 - 如果第一次加载正常、翻页失败，大概率是 reload 时漏传
request或where函数没取到最新输入值
