artisan命令卡住大概率是xdebug调试等待导致：当xdebug.mode=debug且xdebug.start_with_request=1时，每个cli进程会阻塞在socket connect()，直至调试客户端就绪；临时禁用可执行php -d xdebug.mode=off artisan migrate验证。
Artisan 命令执行后光标静止、无输出、无报错，大概率不是命令本身出错，而是 PHP 进程被外部机制主动挂起。最常见且隐蔽的元凶是 Xdebug 的调试等待行为，尤其在 Docker 或远程开发环境中。
检查 Xdebug 是否强制触发 CLI 调试
当 xdebug.mode=debug 且 xdebug.start_with_request=1 启用时，每个 php artisan 命令（包括 migrate、list、tinker）都会尝试连接调试客户端。若 PHPStorm 未监听、端口不通或 host 配置错误（如 xdebug.client_host=mycomputer 在容器内无法解析），PHP 就会卡在 socket connect() 阻塞，表现为“假死”。
- 临时禁用 CLI 环境下的自动调试：在终端中运行 php -d xdebug.mode=off artisan migrate
- 检查当前生效配置：php -i | grep -i xdebug，确认 xdebug.mode 和 xdebug.start_with_request 的实际值
- 开发时推荐将 xdebug.start_with_request 设为 0，仅通过 XDEBUG_TRIGGER 触发调试
验证队列工作进程是否干扰
artisan horizon、queue:work 等常驻进程本身不会锁住其他 Artisan 命令，但它们和新命令共享同一套 Xdebug 行为。因此“启动 Horizon 后 migrate 卡住”，本质是两个独立进程都被 Xdebug 拦截了。
- 用 ps aux | grep artisan 查看是否有残留进程（如意外中断的 horizon）
- 手动 kill 掉所有 php artisan 进程后重试，可快速验证是否为进程残留导致
- 注意：这不是文件锁或端口占用问题，无需查 storage/framework/cache 或 .env 文件锁
排除环境与权限类基础问题
极少数情况下，卡死源于更底层的环境异常。
- 检查 PHP CLI 是否正常：php -v 和 php -m | grep xdebug
- 确认 .env 文件权限合理（建议 600），避免因读取失败导致配置加载中断
- Docker 用户重点检查 php.ini 中 xdebug.client_host 是否指向宿主机正确 IP（如 host.docker.internal），而非硬编码的 mycomputer
快速定位与临时绕过方案
不需要重启服务或修改全局配置，就能立即判断问题来源。
- 执行 php artisan list --no-ansi —— 若有输出，说明是 ANSI 渲染或终端兼容性问题
- 加 -vvv 参数观察详细日志：php artisan migrate -vvv，看卡在哪个初始化步骤
- 换用不同 PHP 版本测试（如 php8.2 artisan migrate），排除 PHP 扩展冲突
