AllowCrossDomain中间件需在app/middleware.php全局注册，置于数组开头并带完整命名空间think\middleware\AllowCrossDomain::class；它不处理OPTIONS预检，需配合自定义中间件或Web服务器配置。
ThinkPHP 6 的 AllowCrossDomain 中间件在哪注册才生效
中间件必须在全局中间件栈里注册，而不是只在某个路由或控制器里调用。ThinkPHP 6 默认不启用跨域中间件，AllowCrossDomain 是框架内置但未默认加载的中间件，名字也容易误导——它其实叫 think\middleware\AllowCrossDomain，不是你自定义的类。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 打开
app/middleware.php，把think\middleware\AllowCrossDomain::class加到数组开头（顺序重要，需早于业务中间件） - 别写成
'AllowCrossDomain'或AllowCrossDomain::class（少命名空间会报Class "AllowCrossDomain" not found） - 如果用了多应用模式，确认改的是当前应用的
middleware.php，不是根目录下的
为什么加了中间件还是被浏览器拦截 OPTIONS 预检请求
因为 AllowCrossDomain 默认只处理 Access-Control-Allow-Origin 和基础头，不自动响应 OPTIONS 方法。浏览器发预检时，若后端没返回 204 或 200，就会卡住。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在
app/middleware.php中，把它放在think\middleware\Cors::class后面更稳妥（但注意：TP6.0.x 官方Cors中间件并不存在，那是 TP6.1+ 才引入的；低版本只能自己补） - 更可靠的做法是：删掉
AllowCrossDomain，改用自定义中间件，在handle()里显式判断$request->isOptions()并返回空响应 + 全部 CORS 头 - 检查 Nginx/Apache 是否拦截了
OPTIONS请求（常见于未配置add_header Access-Control-Allow-Methods或未透传）
AllowCrossDomain 的参数怎么控制允许的域名和方法
这个中间件本身不接受构造参数，它的行为由配置驱动。硬编码改源码不可取，正确方式是通过 config/cors.php 控制（需手动创建），或者直接在中间件里覆盖逻辑。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 新建
config/cors.php，返回数组：['origin' => ['https://a.com', 'https://b.com'], 'methods' => ['GET', 'POST', 'PUT'], 'headers' => ['Authorization', 'X-Requested-With']] - 但注意：
AllowCrossDomain内部只读origin配置项，其他字段（如methods）它根本不看——所以别指望配了就自动生效 - 真正要精细控制，得自己写中间件，在
handle()里调用$response->header()显式设Access-Control-Allow-Origin、Access-Control-Allow-Methods等
开发环境能过，生产环境跨域失败的典型原因
往往不是中间件问题，而是反向代理层吃掉了 CORS 头，或者 HTTPS 配置导致混合内容被浏览器拒绝。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- Nginx 配置里漏了
add_header Access-Control-Allow-Origin $http_origin;（注意不能写死域名，否则带 cookie 时失效） - CDN（如阿里云、Cloudflare）默认过滤自定义 Header，需在 CDN 控制台手动开启 CORS 支持或放行
Access-Control-*头 - HTTPS 站点里引用了 HTTP 接口，浏览器直接阻止（Mixed Content），此时控制台报错是
Blocked loading mixed active content，跟中间件无关
跨域真正难的从来不是加一行中间件，而是厘清请求链路上每一层——PHP、Web 服务器、CDN、浏览器——谁该加头、谁该放行、谁又悄悄删了头。漏掉任意一环，AllowCrossDomain 就只是个摆设。
