Laravel CLI环境下Session与跨域中间件冲突处理

CLI环境下真的存在Session和跨域问题吗？答案是否定的——命令行本身不发起HTTP请求，没有浏览器，没有Origin头，也没有Cookie上下文。所谓“Session与跨域中间件冲突”，说白了，多半是把运行环境搞混了。

先掰扯清楚一个核心点：CLI环境下根本不存在Session和跨域问题——因为命令行不发起HTTP请求，没有浏览器、没有Origin头、没有Cookie上下文。所谓“Session与跨域中间件冲突”，本质是混淆了运行环境。

为什么CLI里压根不走CORS中间件

HandleCors中间件只在HTTP请求生命周期中执行，它依赖的是Request对象的headers->get('Origin')这些字段。而Artisan命令呢，比如php artisan schedule:run或者你写的一个自定义命令，启动时是纯PHP CLI进程，$request要么是空的，要么由ConsoleKernel模拟生成。它不会触发预检（OPTIONS），不携带Origin，中间件链压根儿就不会加载它。

这里有几个常见的误判场景：

• 在命令中调用Http::post()访问自己的API，日志里却看到CORS报错。这其实不是当前命令触发了CORS中间件，而是你调的那个API接口返回了错误。
• 运行php artisan tinker时，Auth::check()返回false。这和CORS一毛钱关系都没有，纯粹是Session没初始化。CLI无会话机制，StartSession中间件完全不生效。
• 执行完迁移后，前端突然跨域失败。一个巧合罢了，很可能是部署时config/cors.php被覆盖，或者SESSION_DOMAIN在.env中被误改了。

Session在CLI中如何“模拟”可用

Session设计之初就是为了服务HTTP的有状态交互，CLI天然是无状态的。如果非要在命令中使用用户数据，比如批量发消息，那就应该绕过Session，改走别的路子：

• 通过模型直接查用户：User::where('id', $userId)->first()
• 用Cache::store('redis')->get('user_token:'.$token)替代session_id查找
• 如果实在要沿用Web端登录态的逻辑，可以临时构造一个IlluminateHttpRequest实例传入认证门面，不过这仅限调试用，不推荐。

强行在命令里调用session_start()或试图读写session()，只会静默失败，搞不好还会污染后续Web请求的会话存储。

跨域配置只影响HTTP入口，和CLI完全解耦

config/cors.php、SESSION_DOMAIN、HandleCors::class注册位置这些配置，统统只对public/index.php入口的HTTP请求生效。CLI命令走的是artisan入口，中间件栈由ConsoleKernel定义，两边的配置互不感知。

怎么验证？简单，在app/Http/Middleware/HandleCors.php的handle()开头加一句Log::debug('CORS running');，然后分别执行：

• curl -H "Origin: http://localhost:3000" http://your.app/api/test → 日志会出现
• php artisan your:command → 日志绝不会出现

真正在CLI中要警惕的“伪冲突”

有些问题表面看起来像是跨域或Session失效在捣鬼，但实际上是其他机制在背后“做手脚”：

• 队列任务中Auth失效：Job序列化时没包含Guard实例，应该在handle()中重新Auth::loginUsingId($userId)。
• Sanctum token在命令中无效：因为Sanctum::authenticateMachine()依赖Request中的Authorization头，CLI里需要手动传入['Authorization' => 'Bearer xxx']。
• 配置缓存导致env变更不生效：试试跑一下php artisan config:clear再测试，别让旧的SESSION_DOMAIN或CORS配置误导了判断。

听起来不复杂，但恰恰是这些细节最容易在排查时被忽略。