tp6跨域时自定义响应头（如x-total-count、authorization）前端无法获取，根本原因是未配置access-control-expose-headers显式暴露；预检阶段还需在access-control-allow-headers中精确列出前端发送的非简单请求头，且必须通过$response对象设置头、注册于中间件首位。
TP6 接口跨域时 Header 丢失，核心问题不是“没发出去”，而是浏览器没让前端拿到——尤其是自定义响应头（如 X-Total-Count、X-Pagination）或带认证信息的请求头（如 Authorization、token）在跨域场景下被浏览器拦截。根本原因在于服务端未正确声明哪些响应头可被前端读取，或预检阶段未放行对应请求头。
必须暴露响应头：Access-Control-Expose-Headers
浏览器默认只允许前端 JavaScript 读取部分“简单响应头”（如 Cache-Control、Content-Language、Content-Type 等）。如果你的接口返回了自定义分页头、计数头或鉴权刷新 token 头，必须显式告诉浏览器：这些头可以暴露给前端。
- 在 CORS 中间件中，对 $response 对象调用 header() 方法时，务必加入：
Access-Control-Expose-Headers: X-Total-Count, X-Pagination, Authorization, X-Auth-Token - 值必须与前端实际尝试 getResponseHeader() 读取的字段完全一致（大小写敏感）
- 不能写成
*，TP6 不支持通配符暴露
预检阶段必须放行请求头
当请求携带 Authorization、Content-Type: application/json 或自定义头（如 X-Token）时，浏览器会先发 OPTIONS 预检。若服务端响应中 Access-Control-Allow-Headers 没包含该字段，后续 POST/GET 就会被静默拒绝——控制台可能只显示 “CORS header ‘xxx’ missing”，但不报错。
- 确保中间件中设置：
Access-Control-Allow-Headers: Authorization, Content-Type, X-Requested-With, X-Token, X-Auth-Token - 列表必须覆盖前端实际发送的所有非简单头；漏一个，整个请求就失败
- 不要依赖
AllowCrossDomain默认配置，它通常只含X-Requested-With
Nginx 层可能悄悄吃掉下划线 Header
如果前端传了类似 auth_token 或 x_user_id 这类带下划线的请求头，而 TP6 控制器里 $request->header('auth_token') 取不到值——大概率是 Nginx 默认丢弃了含下划线的 header。
- 在 Nginx 的 http 或 server 块中添加：
underscores_in_headers on; - 重启 Nginx 生效
- 更推荐长期方案：前后端约定使用短横线（auth-token），避免依赖 Nginx 配置
中间件里设头必须操作 $response 实例
直接写 header('Access-Control-Expose-Headers: ...') 在 TP6 中基本无效。框架基于 PSR-7，响应由 Response 对象封装，手动 header() 调用会被后续流程覆盖。
- 正确写法是在中间件 return $next($request) 之后，对返回的 $response 实例设头：
return $next($request)->header([ 'Access-Control-Expose-Headers' => 'X-Total-Count, Authorization', ... ]) - 确保中间件注册在 app/middleware.php 全局数组首位，防止被 session/auth 中间件提前中断
