根本原因是预检请求中Access-Control-Allow-Headers未精确匹配客户端发送的自定义请求头，包括大小写、空格、遗漏字段或被中间件覆盖；PHP需确保在OPTIONS请求中正确输出无空格的逗号分隔列表，且响应头须在任何输出前发送。
为什么加了 Access-Control-Allow-Headers 还报错“Request header field xxx is not allowed”
根本原因是浏览器在预检（OPTIONS）请求中，会比对客户端实际发送的自定义头（如 X-Auth-Token、X-Requested-With）是否被服务端明确列入 Access-Control-Allow-Headers 响应头。哪怕漏写一个，或者大小写不一致（比如写了 x-auth-token 但前端发的是 X-Auth-Token），就会失败。
PHP 中不能只写一次 header()，必须确保它在预检响应中生效——尤其当使用框架或中间件时，可能被覆盖或未执行。
- 用
getallheaders()或$_SERVER['REQUEST_METHOD'] === 'OPTIONS'显式拦截预检请求 -
Access-Control-Allow-Headers的值必须是逗号分隔的**精确字符串列表**，不能带空格（"X-Auth-Token,Content-Type"✅；"X-Auth-Token, Content-Type"❌） - 若需通配所有自定义头，可设为
*，但注意：不能和Access-Control-Allow-Credentials: true同时使用
PHP 设置响应头的三个关键时机
跨域头必须在任何输出（包括空白符、BOM）之前发送，否则 header() 会失败并报“headers already sent”。
- 纯 PHP 脚本开头直接写：
header('Access-Control-Allow-Origin: https://example.com'); header('Access-Control-Allow-Headers: X-Auth-Token,Content-Type'); header('Access-Control-Allow-Methods: GET,POST,OPTIONS'); header('Access-Control-Allow-Credentials: true'); - Apache + .htaccess：用
Header set指令（需启用mod_headers）Header set Access-Control-Allow-Origin "https://example.com" Header set Access-Control-Allow-Headers "X-Auth-Token,Content-Type" Header set Access-Control-Allow-Methods "GET,POST,OPTIONS" Header set Access-Control-Allow-Credentials "true"
- Nginx 配置中，在
location块内用add_header（注意：默认不继承父级，需在每个需要的 location 里重复写）add_header 'Access-Control-Allow-Origin' 'https://example.com'; add_header 'Access-Control-Allow-Headers' 'X-Auth-Token,Content-Type'; add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS'; add_header 'Access-Control-Allow-Credentials' 'true';
Access-Control-Allow-Headers 和 Access-Control-Expose-Headers 别混
前者告诉浏览器“你允许前端 JS 发哪些自定义请求头”，后者是告诉浏览器“你允许前端 JS 读取哪些响应头”。这是两个方向、完全独立的控制。
立即学习“PHP免费学习笔记（深入）”；
- 前端用
fetch(..., { headers: { 'X-Trace-ID': 'abc' } })→ 需检查Access-Control-Allow-Headers是否包含X-Trace-ID - 后端返回
header('X-Rate-Limit-Remaining: 99')→ 前端想用res.headers.get('X-Rate-Limit-Remaining')读取，就必须在响应头中加Access-Control-Expose-Headers: X-Rate-Limit-Remaining - 常见遗漏：
Set-Cookie不在默认暴露列表里，若需 JS 读取响应中的 cookie 状态，得显式暴露Set-Cookie（但通常不推荐）
调试预检失败最有效的三步
别只看主请求的 Network 面板，重点看 OPTIONS 请求本身。
- 在浏览器 DevTools 的 Network 标签页中，筛选
OPTIONS，点开它，看Response Headers里有没有你设置的Access-Control-Allow-Headers，值是否匹配 - 用
curl -I -X OPTIONS -H "Origin: https://example.com" -H "Access-Control-Request-Headers: X-Auth-Token" https://your-api.com/endpoint直接模拟预检，确认响应头内容 - 检查 PHP 错误日志：如果
header()调用失败（例如前面有 echo 或 BOM），Apache/Nginx 日志里通常会有 “Cannot modify header information” 提示
很多问题其实卡在预检没走 PHP 脚本——比如 Nginx 把 OPTIONS 请求直接返回 204，压根没转发给 PHP，这时在 PHP 里写再多 header() 都无效。
