需手动安装缺失扩展并初始化环境：用apt-get安装系统依赖后，执行docker-php-ext-install启用zip、mbstring、xml、pdo、pdo_sqlite；复制.env.example并运行php artisan key:generate；确保composer install完成且用vendor/bin/phpunit -c phpunit.xml执行测试。
GitLab CI 里用 php:8.2-cli 镜像但扩展缺失怎么办
直接写 image: php:8.2-cli 很容易在 composer install 或 phpunit 运行时炸，报错类似 Class 'ZipArchive' not found 或 extension "mbstring" is not loaded。PHP 官方镜像默认只带最精简的扩展，zip、mbstring、pdo_sqlite、xml 这些 Composer 和测试框架实际依赖的扩展全得手动装。
- 用
apt-get update && apt-get install -y zip unzip libzip-dev装 zip 支持，再用docker-php-ext-install zip编译启用（注意顺序：先装系统包，再编译 PHP 扩展） - 对
mbstring、xml等常用扩展，统一用docker-php-ext-install mbstring xml pdo pdo_sqlite一次性启用 - 如果项目用 Laravel + SQLite 测试，
pdo_sqlite必须启用，否则phpunit启动就失败 - 别信
php -m | grep zip输出——它可能显示已加载，但实际ZipArchive类不可用，最终得靠php -r "new ZipArchive();"实测
为什么 vendor/bin/phpunit 总报错找不到 APP_KEY
Laravel 项目在 CI 中跑测试前没生成密钥，phpunit 加载配置时会因 APP_KEY 为空或未定义而中止。这不是环境变量没传，而是 .env 文件压根不存在或没初始化。
- 必须在
before_script里加cp .env.example .env，再立刻执行php artisan key:generate --no-interaction -
--no-interaction不能省，否则命令卡住等待 stdin 输入，CI job 直接超时 - 如果
.env.example里已有DB_CONNECTION=sqlite，确保database/database.sqlite文件存在且可写，否则测试启动阶段就报 PDO 异常 - 别把
APP_KEY写死在.env里传到仓库——CI 中生成一次就够了，密钥值本身不敏感，但硬编码进版本库是反模式
GitLab CI 里怎么让 PHP 8.2 测试真正跑起来
光有镜像和扩展还不够，phpunit 命令调用路径、工作目录、自动加载器初始化这三步错一个，测试就静默失败或报 Class not found。
- 始终用
vendor/bin/phpunit，不是全局phpunit—— CI 环境没装全局命令，且版本易冲突 - 确保
composer install --no-dev --prefer-dist已执行，否则vendor/autoload.php不完整，phpunit找不到测试基类 - 加
-c phpunit.xml显式指定配置文件，避免因当前目录不对导致读取错误的phpunit.xml.dist - 测试脚本开头加
php -v和php -m | grep -E "(mbstring|zip|pdo)"，出问题时一眼看穿是 PHP 版本还是扩展层挂了
测试失败时不中断 pipeline？别这么干
GitLab 默认遇到非零退出码就终止 job，但有人为省事在 script 里写 || true 或设 allow_failure: true，结果测试红了也发版，等于废掉 CI。
立即学习“PHP免费学习笔记（深入）”；
- 明确写
continue-on-error: false（虽然默认就是 false，但显式声明能防误读） - 单元测试失败必须阻断后续
deploy阶段，这是 CI 的底线逻辑 - 真要跳过某类测试（比如慢速集成测试），单独拆成新 job 并设
allow_failure: true，别污染核心unit-testjob - 最容易被忽略的是：Laravel 的
phpunit在无数据库连接时默认静默跳过所有测试——得加--verbose或检查输出里有没有Tests: X, Assertions: Y行来确认是否真跑了
