PHP CI/CD核心是跑通“提交→验证→上线”链路，关键在于自动化分层测试（单元、集成、端到端）、锁定PHP版本与依赖（提交composer.lock、禁用update）、轻量安全部署（rsync+SSH+备份+Secrets管理）及敏感信息隔离（环境变量注入、.env.local忽略）。
PHP网站搭建CI/CD，核心不是堆工具，而是把“代码提交→验证→上线”这条链路跑通、跑稳、跑快。关键在三件事：测试能自动跑起来、环境版本不打架、部署动作不可逆且可追溯。
自动化测试要分层跑，别只靠 PHPUnit 单打独斗
单元测试验证单个函数或类逻辑，用 vendor/bin/phpunit 执行，每次 push 必跑；集成测试检查数据库连接、API调用是否正常，建议用 SQLite 内存库提速；端到端测试可选 Playwright 或 Laravel Dusk（若用 Laravel），覆盖登录、表单提交等真实路径。测试前必须指定 PHP 版本和必需扩展（如 mbstring、curl），避免本地能过、CI 报错。
- 在 GitHub Actions 中加一行：
php-version: '8.2'，并用ext-mbstring: true显式启用扩展 - 测试失败时输出详细日志，加上
--verbose和--debug参数便于定位 - 用
php-file-iterator自动扫描tests/下所有*Test.php文件，不用手动维护测试列表
PHP版本与依赖必须锁定，环境才不会“今天好、明天崩”
开发用 PHP 8.2，测试用 8.1，生产却跑在 7.4？这种错位是 CI/CD 最常见的隐性故障源。推荐两种方案：一是用 PHPBrew 在 CI 环境中按需安装多版本，配合矩阵策略并行测试；二是直接构建 Docker 镜像，把 PHP + 扩展 + Composer 依赖全打包，镜像 ID 就是环境指纹。
- 务必提交
composer.lock到仓库，否则composer install每次拉的包版本可能不同 - 在
.gitlab-ci.yml或workflow中禁用composer update，只允许install - 用
php -v和php -m | grep mbstring在流水线开头做基础检查，早发现问题
部署动作要轻量、安全、留痕，别让 rsync 成为定时炸弹
中小项目无需 Kubernetes，rsync + SSH 足够可靠。但必须注意三点：密钥不能写进脚本，要存 CI 平台的 Secrets 并 base64 编码后解密使用；目标服务器目录权限要预设好（如 www-data 可读、部署用户可写）；每次部署前备份上一版，出问题秒回滚。
立即学习“PHP免费学习笔记（深入）”；
- 用
rsync -avz --delete同步，--delete确保删掉旧文件，避免残留配置干扰 - 部署命令最后加
&& php artisan migrate --force 2>/dev/null || true（Laravel 示例），迁移失败不中断整体流程 - 打 Tag 触发生产部署时，禁用
git push --tags，改用 Personal Access Token + HTTPS 地址，防止误操作
环境变量和密钥必须隔离，硬编码等于开后门
数据库密码、API Key、JWT 秘钥这些绝不能出现在代码或配置文件里。CI 平台提供环境变量注入能力，PHP 项目通过 getenv() 或 $_ENV 读取；敏感值统一走平台 Secrets，不在日志中回显。本地开发可用 .env.local，但该文件必须加入 .gitignore。
- 在 CI 脚本中加一句
printenv | grep -E 'DB_|API_' | sed 's/=.*/=xxx/'，确认敏感字段已脱敏 - 用
phpdotenv加载环境变量时，确保只加载非生产环境的本地文件，生产环境由系统变量接管 - 所有 config 文件（如
database.php）里禁止出现明文密码，全部替换为env('DB_PASSWORD')形式
