tp6跨域必须通过response对象设头且短路处理options预检，否则因header()被覆盖、预检未响应或*与credentials冲突导致前端静默失败；控制器内硬塞header()会触发cannot modify header信息错误或空白页。
ThinkPHP 跨域不能靠 header() 硬塞，必须在响应对象上设头，且 OPTIONS 预检必须短路返回 204 —— 否则前端卡死、控制台静默失败、POST 请求直接 404 或 500。
为什么在控制器里写 header() 会失效或报错
TP6 使用 PSR-7 响应对象模型，header() 是 PHP 原生函数，它只在输出未开始时有效；一旦框架已触发视图渲染或 json() 输出，header() 就会失败，出现 Cannot modify header information 错误，甚至导致空白页 + ERR_INVALID_HTTP_RESPONSE。
- TP5.1 中在
initialize()里写header()，常被View自动输出提前截断 - TP6 中所有响应都走
Response对象，必须用$response->header()或response()->header() - 若你用了
echo、dump()、var_dump()等输出语句，再调response()->header()也无效 —— 它必须在最终return前调用
路由级跨域：用 allowCrossDomain() 最轻量
只对特定 API 路由生效，不污染全局逻辑，适合前后端分离项目中仅开放 /api/ 下接口的场景。
- 必须链式写在路由定义末尾：
Route::get('api/user', 'Api/User')->allowCrossDomain(['https://admin.example.com']) - 要带 Cookie？第二个参数传
true：->allowCrossDomain(['https://a.com'], true)，此时Access-Control-Allow-Origin会自动设为请求头中的Origin值（需在白名单内） - 不支持 console/event 路由，只作用于 HTTP/HTTPS 请求
- 该方法内部已自动处理 OPTIONS 预检，无需额外干预
全局中间件跨域：必须拦截 OPTIONS 并返回 204
这是最常见出问题的地方 —— 很多人加了头但没处理预检，浏览器发完 OPTIONS 就停住，后续请求根本不会发出。
- 在
app/middleware/CorsMiddleware.php的handle()开头判断：if ($request->isOptions()) { return response('', 204); } - 之后统一设置响应头：
$response->header('Access-Control-Allow-Origin', 'https://your-frontend.com')，不能是*+Access-Control-Allow-Credentials: true组合 -
Access-Control-Allow-Headers必须包含前端实际发送的字段，比如Content-Type、Authorization、X-Requested-With - 中间件注册位置很重要：在
app/middleware.php中必须放在首位或至少在其他可能改头的中间件之前
带 Cookie 或 Authorization 时的域名匹配陷阱
浏览器对凭证类跨域极其严格，后端配错一个字符，前端就拿不到 session 或 JWT。
-
Access-Control-Allow-Origin不能为*，必须和请求头Origin完全一致（协议、端口、子域名都不能差） - TP6 中建议动态读取并校验：
$origin = $request->header('origin');，再查白名单数组是否包含它，匹配成功才设头 - 前端 fetch 必须显式写：
credentials: 'include'；jQuery 用xhrFields: { withCredentials: true } - ThinkPHP 的 session cookie 默认不跨子域，需在
config/session.php中设'domain' => '.example.com'（注意开头的点）
真正卡住跨域的，从来不是“怎么加头”，而是谁在删头、谁漏了 OPTIONS、谁把 * 和 withCredentials: true 同时用了 —— 这些地方一错，浏览器连错误提示都不给，只默默丢弃响应。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
