GitHub Actions中Laravel CI失败主因是环境未对齐：PHP版本与platform配置冲突、缺失ext-pdo_mysql等扩展、MySQL服务host误配localhost、.env.testing未正确设置DB_HOST=mysql；须用setup-php显式指定版本和扩展，动态生成.env.testing并轮询mysql健康状态。
GitHub Actions 上 Laravel CI 卡在 composer install 或 phpunit 报数据库连接拒绝，基本是环境没对齐——不是代码问题，是 runner 的 PHP 版本、扩展、服务 host、.env 配置这四点没配对。
为什么 composer install 在 GitHub Actions 里总失败？
Ubuntu runner 默认 PHP 版本（如 8.3）和你 composer.json 里 "platform": {"php": "8.2"} 冲突；更常见的是缺扩展，比如 ext-pdo_mysql、ext-redis、ext-gd 没装，composer install 直接报错退出。
- 必须用
shivammathur/setup-php@v2显式指定php-version和extensions，不能依赖系统默认 - 加
--ignore-platform-req=ext-*只在 CI 临时跳过扩展检查（仅限测试环节，不建议跳过php版本） -
composer install --no-interaction --prefer-dist --optimize-autoloader是安全组合，避免交互卡住
MySQL 服务启动了，但 phpunit 还是连不上？
因为 GitHub Actions 的 services 是 Docker 容器，localhost 指向 runner 主机，不是 MySQL 容器。Laravel 测试默认读 .env.testing，里面如果写 DB_HOST=localhost，就必然 Connection refused。
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
- 在
services块里定义mysql服务后，DB_HOST必须设为mysql（即 service 名） - 用
echo动态生成.env.testing，确保DB_HOST=mysql、DB_PORT=3306、DB_DATABASE=testdb - 加上健康检查或简单轮询（如
while ! mysqladmin ping -hmysql -uroot --silent; do sleep 1; done），等 MySQL 真正 ready 再跑测试
测试跑完报 Class 'Tests\TestCase' not found 怎么办？
这是 autoloader 没生效的典型表现，常见于没运行 php artisan key:generate 或 .env 未正确加载，导致 Laravel 应用启动失败，后续测试类无法被识别。
-
php artisan key:generate必须在composer install之后、phpunit之前执行 - 用
env:块传APP_KEY，别依赖本地生成的.env文件 - 确保
phpunit.xml中bootstrap指向vendor/autoload.php，且<env name="APP_ENV" value="testing"></env>已启用
如何让测试真正覆盖业务逻辑，而不是只跑通？
很多团队把 CI 当成“能跑就行”，结果 phpunit 成了形式主义——它只验证你写的断言，不验证你漏写了哪些场景。关键在分层和数据隔离。
- Unit 测试用内存 SQLite（
DB_CONNECTION=sqlite），快且干净；Feature 测试才用 MySQL service - 每个测试方法开头加
$this->artisan('migrate:fresh --seed');，避免测试间状态污染 - 禁用缓存驱动（
CACHE_DRIVER=array）、队列驱动（QUEUE_CONNECTION=sync），防止异步行为干扰断言
最易被忽略的一点：GitHub Actions 的 services 不会自动暴露端口给外部，但会通过 Docker 内网互通；所以别在 workflow 里尝试用 curl http://localhost:3306 做检测，那永远失败——必须用 mysqladmin -hmysql 这类走内网 DNS 的方式。
