答案是直接在PHP文件开头用header()设置CORS响应头即可生效。phpEnv作为Windows集成环境，不提供跨域开关，必须由PHP脚本控制；需确保header()在任何输出前调用，正确处理OPTIONS预检请求，并避免*与credentials共存。
phpEnv 里直接写 header() 就够了
phpEnv 是 Windows 下的集成环境（类似 XAMPP），它本身不提供跨域配置开关，CORS 必须由 PHP 脚本自己控制。你不需要改 php.ini、Apache 配置或 phpEnv 界面里的任何选项——只要在 PHP 文件开头正确输出响应头即可生效。
常见错误是把 header() 放在 echo、var_dump() 或 HTML 输出之后，导致 headers already sent 报错。务必确认：文件开头没有空格、BOM、UTF-8 签名，也没有任何 print 或 require 引入了带输出的文件。
-
header('Access-Control-Allow-Origin: *')仅限开发调试；上线前必须换成具体域名，比如https://localhost:3000 - 如果前端用了
withCredentials: true（比如传 Cookie），Access-Control-Allow-Origin不能为*，且必须加header('Access-Control-Allow-Credentials: true') -
Access-Control-Allow-Headers要和前端实际发的请求头对齐，比如用了Authorization或X-Requested-With，就得写全：Content-Type, Authorization, X-Requested-With
为什么在 phpEnv 里 OPTIONS 预检总失败
浏览器对非简单请求（如 Content-Type: application/json、PUT、DELETE 或带自定义 header）会先发一次 OPTIONS 请求探路。phpEnv 默认 Apache + PHP-FPM 环境下，这个请求可能被路由规则拦截，或 PHP 脚本根本没处理它。
关键不是服务器配置，而是你的 PHP 文件是否显式响应了 OPTIONS。漏掉这步，后续真实请求压根不会发出，控制台只报 Response to preflight request doesn't pass access control check。
立即学习“PHP免费学习笔记（深入）”；
- 必须在业务逻辑前加判断：
if ($_SERVER['REQUEST_METHOD'] === 'OPTIONS') { http_response_code(204); exit; } - 别用
exit(0)或die()，用http_response_code(204)更规范（204 表示无内容，符合预检语义） - 不要依赖 .htaccess 里的
RewriteRule拦截 OPTIONS —— phpEnv 的 Apache 模块顺序和 rewrite 规则容易导致 PHP 根本收不到该请求
phpEnv 中 Apache 层统一加 CORS 头可行吗
可以，但不推荐作为首选。phpEnv 自带的 Apache 配置位于 phpEnv\Apache\conf\httpd.conf 或站点对应的 vhost 文件中，你可以用 add_header 添加 CORS 响应头。
问题在于：add_header 不支持条件逻辑（比如动态匹配 Origin），也无法处理 OPTIONS 请求的响应体控制。一旦加了，所有响应都带这些头，包括图片、CSS、404 页面——既冗余又可能干扰缓存。
- 若坚持用 Apache 配置，至少加上
always参数：Header always set Access-Control-Allow-Origin "*"（需启用headers_module） - 必须配合
LocationMatch限定路径，例如只对/api/开放：<locationmatch></locationmatch> - 仍需在 PHP 里保留
OPTIONS处理逻辑——因为 Apache 只能加头，不能终止请求；而预检请求需要快速返回 204，PHP 层不干预就会继续往下执行业务代码
用框架时别重复手动设 CORS 头
如果你在 phpEnv 上跑的是 Laravel、ThinkPHP 或 CodeIgniter，框架自身有中间件或事件机制处理 CORS，手动在每个控制器里写 header() 容易遗漏、冲突，还难维护。
例如 Laravel 的 CorsMiddleware 会自动补全 Vary: Origin、处理凭证、缓存预检结果；ThinkPHP 6 的 response_send 事件可统一注入头。这些比手写更健壮。
- 检查框架是否已内置 CORS 支持（如 Laravel 7+ 默认带
fruitcake/laravel-cors） - 禁用自己写的全局
header()，否则可能和中间件叠加，出现重复头（浏览器通常取第一个，但行为不可靠） - 框架中间件无法绕过
OPTIONS处理——仍需确保中间件在请求生命周期早期运行，且对 OPTIONS 方法不跳过
真正容易被忽略的点是：跨域配置生效 ≠ 请求一定能通。你要验证的是整个链路——前端发的请求方法/头、服务端是否收到 OPTIONS、PHP 是否返回 204、真实请求是否带上了正确的 Origin 和凭证。光看响应头有没有 Access-Control-Allow-Origin 是不够的。
