Session跨子域失效的主因是SESSION_DOMAIN未设为带点前缀的二级域（如.example.com），导致Cookie无法共享；需同步配置SESSION_SAMESITE=None、SESSION_SECURE=true，并在CORS中启用supports_credentials且禁用通配符origin。
Session 域名必须显式设为带点前缀的二级域
不设或设错 SESSION_DOMAIN，跨子域（如 admin.example.com ←→ api.example.com）就拿不到 Cookie，session_start() 生成的会话根本不同步。Laravel 默认是 null，意味着只对当前完整域名生效，不共享。
正确做法是在 .env 里写成：
SESSION_DOMAIN=.example.com
注意开头那个点 —— 这不是可选格式，而是浏览器识别“允许子域继承 Cookie”的硬性要求。漏掉它，auth:api 中间件会反复重定向登录，Auth::check() 总返回 false。
- 不能写成
example.com（无点）或www.example.com（太具体） - 本地开发用
.test或.localhost时，需确保 hosts 和浏览器都支持（Chrome 120+ 对.localhost已友好，但.test仍需手动配 hosts） - 如果主站跑在
https://example.com，但测试 API 在http://api.example.com，HTTP/HTTPS 混合会导致 Cookie 被拒绝 —— 此时必须全站 HTTPS，且SESSION_SECURE=true
CORS 配置里必须放开 credentials 且 origin 不能为 *
Laravel 自带的 fruitcake/laravel-cors 包默认禁用凭据（credentials），而跨域传 Cookie 必须开启它，否则浏览器直接丢弃 Set-Cookie 头。
在 config/cors.php 中关键配置是：
'supports_credentials' => true, 'allowed_origins' => ['https://admin.example.com', 'https://app.example.com'],
不允许把 allowed_origins 写成 ['*']，否则浏览器报错：A wildcard '*' cannot be used in the 'Access-Control-Allow-Origin' header when the credentials flag is true.
审查 Remix v2 代码中的 v1 形态 meta 导出（v2 中为破坏性变更），cookie 安全漏洞（httpOnly、secure、密钥轮换），认证门位于错误层级，以及其他
-
supports_credentials必须为true，且前端 fetch 要加{ credentials: 'include' } - 如果后端用 Nginx，还得确认没覆盖响应头：检查有没有
add_header Access-Control-Allow-Origin '*';这类粗暴配置，它会和 Laravel 的 CORS 中间件冲突 - 开发时用
localhost:3000访问，allowed_origins就得明确写上它，不能靠通配符蒙混
CSRF token 和 session ID 实际共用同一组 Cookie
很多人以为 XSRF-TOKEN 是独立机制，其实它只是从 laravel_session Cookie 解码出来的值 —— 换句话说，跨域拿不到 laravel_session，X-XSRF-TOKEN 请求头就必然失效，所有 POST/PUT/DELETE 请求 419。
验证方式很简单：打开浏览器 DevTools → Application → Cookies，对比主站和子域下 laravel_session 的 Domain 字段是否一致（都应为 .example.com）。
- 如果子域看不到该 Cookie，先查
SESSION_DOMAIN和协议（HTTP/HTTPS）是否匹配 - Vue/React 前端发请求时，
axios.defaults.withCredentials = true必须设，否则即使后端开了supports_credentials也白搭 -
SameSite=None不是可选项：Laravel 9+ 默认设为Lax，跨域场景必须改回None，并在.env加SESSION_SAMESITE=None，同时确保SESSION_SECURE=true
本地开发时 Chrome 对 localhost 的 SameSite 策略更严格
Chrome 117+ 把 localhost 视为“具有安全上下文的站点”，但仍会按 SameSite=Lax 处理未显式声明的 Cookie —— 这意味着哪怕你写了 SESSION_SAMESITE=None，若没配 SESSION_SECURE=true，Chrome 会静默忽略该设置，并继续用 Lax。
解决方案只有两个：要么切 HTTPS（用 mkcert 本地签证书），要么临时降级 SameSite 行为（仅限开发）：
SESSION_SAMESITE=None SESSION_SECURE=false SESSION_HTTP_ONLY=false
然后在 App/Providers/AppServiceProvider.php 的 boot() 里补一句：
if (app()->environment('local')) {
\Illuminate\Support\Facades\URL::forceScheme('http');
}
- 不要信“Chrome 设置里关掉 SameSite 限制”这种方案，新版已移除该开关
- Safari 对
localhost更保守，建议开发阶段统一用.test域（如app.test），hosts 绑定到127.0.0.1，反而更接近生产行为 - 一旦上线，
SESSION_SECURE必须为true，否则SameSite=None会被浏览器拒绝
SESSION_DOMAIN 开头那个点、SESSION_SAMESITE 和 SESSION_SECURE 的联动关系，以及 CORS 配置里 * 和 credentials 的互斥性 —— 这三处只要错一个，整个跨域 Session 就静默失败，连错误日志都不留。 
