Composer代码质量：在依赖安装时自动运行静态检查-composer-PHP中文网

composer不自动运行静态检查，需通过post-update-cmd事件绑定phpstan等工具；该事件在autoloader重建后触发，确保类可加载，且每次update/require必执行，比post-install-cmd更可靠。

composer代码质量：在依赖安装时自动运行静态检查

Composer 本身不会、也不能在 install 或 update 过程中“自动运行”静态检查——它不执行分析逻辑，只负责依赖调度与文件写入。所谓“安装时自动检查”，本质是把检查命令绑定到 Composer 的生命周期事件上，靠 post-install-cmd 或 post-update-cmd 触发。

为什么不能直接在 install 阶段做静态分析？

Composer 的安装流程分三步：解析依赖 → 下载包 → 写入 vendor。静态分析（如 PHPStan、PHPCS）需要完整的源码和 autoloader，而 post-install-cmd 触发时，vendor/autoload.php 刚生成、但项目自身代码可能尚未被 autoload 机制覆盖（尤其未配置 autoload-dev 时）。此时直接调用 phpstan analyse 很可能报 Class not found 或跳过 src 目录。

PHPStan 默认不加载项目 autoload，除非显式配置 parameters.autoload_files 或 bootstrap
post-install-cmd 在首次 composer install 时才触发；若 vendor/ 已存在且 composer.lock 未变，该事件会被跳过
CI 环境中常加 --no-scripts 避免副作用，这时所有 scripts 都静默失效

应该绑定到哪个事件才真正可靠？

用 post-update-cmd 比 post-install-cmd 更稳，尤其对团队协作和 CI 场景：

post-update-cmd 每次 composer update 或 composer require 后必触发，不依赖 vendor/autoload.php 是否已存在
它天然发生在 autoloader 重建之后（Composer 内部会先跑 post-autoload-dump），确保类能被正确加载
把检查命令放在 post-update-cmd 中，可覆盖本地开发、CI 构建、甚至 Docker 构建阶段

示例配置（composer.json）：

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

"scripts": {
    "post-update-cmd": [
        "@phpstan",
        "@phpcs"
    ],
    "phpstan": "phpstan analyse --no-progress",
    "phpcs": "phpcs --standard=PHPCompatibility --runtime-set testVersion 8.1 src/"
}

如何避免检查失败导致 install/update 中断？

默认情况下，scripts 中任意命令退出码非 0，整个 composer update 就会失败。这在 CI 中是预期行为，但在本地开发中可能过于激进：

加 --no-interaction 不影响 scripts 退出码；真正控制的是脚本自身是否容错
PHPStan 提供 --error-format=raw + grep -v 过滤误报，但不推荐——掩盖问题不如修复问题
更合理的方式：在 CI 中严格校验（失败即阻断），在本地用 composer run phpstan -- --no-progress 手动触发，或设为 post-update-cmd 但不加入主链（避免阻塞）
注意：PHPCS 若配了 --report=checkstyle，需配合 || true 才能忽略错误（不推荐），更好的做法是用 phpcbf 自动修复可修正项

真实部署时最常被忽略的兼容性陷阱

很多人以为装了 PHPStan 就万事大吉，却在线上 PHP 7.4 环境跑崩了——因为 PHPStan 不检查语法兼容性，只做类型推导。真正该拦住 match、str_contains()、??= 的，是 phpcompatibility/php-compatibility 规则集：

必须显式传 --runtime-set testVersion 7.4，否则默认只扫 PHP 5.6 兼容问题
testVersion 是目标最低运行环境，不是你本地 PHP 版本；CI 中应固定该值，而非读取 PHP_VERSION_ID
别把兼容性检查和类型检查混在同一 level：PHPStan level 8 要求完整类型注解，而 PHPCompatibility 只关心语法/函数是否存在——两者维度不同，不可替代

最终要盯住的，从来不是“有没有运行检查”，而是“检查是否在正确的时机、针对正确的目标、以可控的方式发生”。否则，自动化只会变成自动甩锅。