PHP 8.5 默认不处理 OPTIONS 预检请求，它被 Web 服务器（如 Nginx/Apache）直接拦截或返回空响应，导致 CORS 预检失败；必须在 Web 服务器配置中显式处理并返回 204，或极少数场景下由 PHP 在无输出前安全输出响应头并 exit。
OPTIONS 预检请求为什么没进你的 PHP 路由
PHP 8.5 默认不处理 OPTIONS 请求——它压根不会走到你写的 index.php 或框架路由里，而是被 Web 服务器（如 Nginx/Apache）直接拦截或返回空响应。浏览器看到无响应头（尤其是缺失 Access-Control-Allow-Methods），就判定预检失败，后续 POST/PUT 根本发不出去。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
PHP 8.5.12
下载
修复 Core bailout 状态损坏安全问题，以及 BZ2、DOM、PDO、Opcache/JIT 内存与执行错误，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
- 别指望
$_SERVER['REQUEST_METHOD'] === 'OPTIONS'在 PHP 里能捕获到预检——多数情况下它根本不会进来 - 检查 Web 服务器日志，确认
OPTIONS请求是否被 405、404 或静默丢弃（Nginx 默认对未配置的OPTIONS返回 204 或 405） - 用
curl -X OPTIONS -I http://your-api.com/endpoint测试原始响应头，重点看有没有Access-Control-Allow-Origin
Nginx 中正确响应 OPTIONS 预检的配置写法
必须在 location 块里显式处理 OPTIONS，且优先级要高于 PHP 的 fastcgi_pass。常见错误是只加了 add_header 却没终止请求流程，导致请求继续往下走、最终 404 或 500。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在对应
location内添加：if ($request_method = 'OPTIONS') { add_header Access-Control-Allow-Origin "*"; add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS"; add_header Access-Control-Allow-Headers "Content-Type, Authorization"; add_header Access-Control-Allow-Credentials "true"; add_header Access-Control-Max-Age "86400"; return 204; } - 不要用
try_files或rewrite干扰OPTIONS；return 204是关键，它终止处理并返回空体响应 - 如果用了 JWT 或 session 鉴权，
OPTIONS必须绕过——它不带Authorization头，PHP 层鉴权会直接报错
PHP 8.5 中手动处理 OPTIONS 的边界场景
仅当 Web 服务器无法配置（如某些共享主机）、或需动态生成 CORS 头（比如按 Referer 白名单）时，才考虑让 PHP 接管 OPTIONS。但 PHP 8.5 的 fastcgi_finish_request() 或 header() 时机稍有不慎就会失效。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 确保在任何输出（含空格、BOM）前调用
header()，且必须包含Access-Control-Allow-Origin - 用
exit或die立即终止脚本，避免后续逻辑干扰响应体（OPTIONS应该无 body） - 示例最小安全写法：
if ($_SERVER['REQUEST_METHOD'] === 'OPTIONS') { header('Access-Control-Allow-Origin: *'); header('Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS'); header('Access-Control-Allow-Headers: Content-Type, Authorization'); header('Access-Control-Allow-Credentials: true'); http_response_code(204); exit; } - 注意：PHP-FPM 的
buffer_output配置可能导致 header 被缓存延迟发送，测试时加ob_end_clean()更稳妥
Access-Control-Allow-Credentials 和 Origin 不能共存的坑
如果你的前端设置了 credentials: 'include'，但后端 Access-Control-Allow-Origin 还是写成 *，浏览器会直接拒绝响应——这是硬性规范，PHP 8.5 不会帮你绕过，Web 服务器也不会。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 需要凭据时，
Access-Control-Allow-Origin必须精确匹配前端域名，例如https://app.example.com，不能是* - PHP 层动态判断时，务必校验
$_SERVER['HTTP_ORIGIN']是否在白名单内，再 echo 对应值，否则跨域失败且无提示 - Nginx 中无法做动态 Origin 判断，此时必须交由 PHP 处理，且要在所有可能路径（包括静态资源 location）都覆盖该逻辑
