结论：GitHub Actions 做 PHP 代码质量检查须严格按语法校验→风格统一→静态分析→单元测试四层顺序执行，任一层失败即中断；cs-check 必须在 cs-fix 前用于 CI 门禁，PHPStan 需显式指定 autoload-file 和 level:5–6，PHPUnit 必须覆盖 composer.json 声明的全 PHP 版本矩阵，并配置扩展与完整日志捕获。
直接上结论：用 GitHub Actions 做 PHP 代码质量检查，核心不是堆工具，而是分层拦截——语法校验、风格统一、静态分析、单元测试这四层必须按顺序执行，且任一层失败都应中断后续流程。否则容易出现“CS-Fixer 修了格式，但 PHPStan 报出的类型错误被忽略”这类漏检。
phpcs 和 php-cs-fixer 的执行顺序不能颠倒
很多项目在 composer.json 里同时定义了 cs-check 和 cs-fix，但在 GitHub Actions 中误把 cs-fix 放在 cs-check 前面运行，导致检查永远“通过”，实际代码却没被验证。
-
cs-check是只读扫描，适合 CI 环境做门禁；cs-fix是写入操作，只应在本地或 PR 预提交钩子中使用 - 若需自动修复并提交，必须显式启用
git config --global user.name和user.email，否则cs-fix会因 Git 用户未配置而静默失败 - WordPress 项目要特别注意：
phpcs.xml.dist中若引用WordPress-Docs规则，需额外安装squizlabs/php_codesniffer≥ 3.7.2，低版本会跳过文档块检查
PHPStan 分析级别要匹配 PHP 版本和 Composer autoload
PHPStan 默认不加载 autoload-dev，导致测试辅助类（如 TestCase）报 Class not found；同时，level: 8 在 PHP 8.2+ 下可能触发 Call to an undefined method 误报，因为部分反射行为已变更。
使用约定式提交（Conventional Commits）从 Git 历史记录中生成结构化变更日志，支持多种格式、AI 增强型描述以及可自定义的范围……
- 必须在 GitHub Actions 步骤中显式传参：
vendor/bin/phpstan analyse --configuration=phpstan.neon --autoload-file=vendor/autoload.php - CI 中推荐固定使用
level: 5或6，兼顾覆盖率与稳定性；level: 7+应仅限本地开发环境启用 - 若项目含
psr-4映射到src/外路径（如tests/Support），需在phpstan.neon中补全paths:列表，否则这些文件不会被扫描
PHPUnit 测试必须声明 PHP 版本矩阵，不能只跑一个版本
单版本测试（比如只跑 PHP 8.1）会让 #[ReturnTypeWillChange]、enum 枚举兼容性、mixed 类型推导等差异点完全暴露不出，上线后在目标环境中突然崩溃。
立即学习“PHP免费学习笔记（深入）”；
- GitHub Actions 的
strategy.matrix.php-version必须覆盖项目composer.json中require.php声明的最小和最大版本 - 每个 PHP 版本下，需单独执行
composer install --no-interaction --prefer-dist，避免因缓存导致依赖解析错乱 - 若测试中用到
ext-sqlite3或ext-pdo_mysql，需在shivammathur/setup-php@v2步骤中显式开启：extensions: ['sqlite3', 'pdo_mysql']
最容易被忽略的是错误日志的捕获方式：GitHub Actions 默认截断超长输出，PHPStan 或 PHPUnit 的详细错误堆栈常被砍掉关键行。务必在对应步骤加 continue-on-error: false 并配合 if: always() 的日志归档步骤，否则你看到的只是 “The process '/usr/bin/sh' failed with exit code 1” 这种无效信息。
