composer install本身不执行代码审查，仅按composer.lock精确还原依赖；必须通过配置post-install-cmd钩子显式调用phpstan、phpcs等工具，并确保dev依赖已安装、lock文件合法且审查工具版本锁定。
composer install 本身不执行代码审查，它只还原依赖快照
很多人误以为 composer install 会自动触发静态分析或规范检查——它不会。这个命令唯一职责是按 composer.lock 精确安装包，不做任何扫描、不加载分析器类、也不读取 phpstan.neon 或 phpcs.xml。如果你没在 CI 或脚本里显式调用 phpstan analyse 或 phpcs，那代码审查就等于没发生。
必须把审查命令绑定到 install 后的生命周期钩子
靠人工记着“装完再跑一遍 phpstan”不可靠，得让 Composer 自动调度：
- 在
composer.json的"scripts"中定义："post-install-cmd": ["phpstan analyse", "phpcs"] - 若需区分环境，用
"post-install-cmd": ["@phpstan", "@phpcs"]并单独声明"phpstan": "phpstan analyse --no-progress" - 注意：这些命令只在
composer install完成后执行，不适用于composer update（后者应走 PR + 差异审查流程） - CI 中必须确保
vendor/bin/phpstan和vendor/bin/phpcs可执行，否则钩子静默失败
install 时跳过 dev 依赖会导致审查工具不可用
composer install --no-dev 是上线常用参数，但它会跳过 require-dev 下所有包——包括 phpstan/phpstan、squizlabs/php_codesniffer。结果就是 post-install-cmd 里的审查命令直接报错 “Command not found”。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
解决方案只有两个：
- CI 流程分两阶段：先
composer install（带 dev），跑完审查；再composer install --no-dev打包上线 - 或者改用
composer install --with-dependencies=phpstan/phpstan,squizlabs/php_codesniffer显式拉入关键 dev 工具（需 Composer ≥2.5）
锁文件被篡改时，install 仍会执行但审查可能失效
composer.lock 被手动编辑或 Git 冲突未解决干净，会导致 composer install 安装的包与预期不符。比如某行版本号从 "2.12.0" 错写成 "2.12.0a"，Composer 会静默降级安装旧版 phpstan，而新版规则（如 level 9）可能不生效。
预防方式很实际：
- CI 中加一步：
composer validate --strict && composer install --dry-run，验证 lock 文件合法性并预检依赖树 - 禁止直接提交
composer.lock修改，所有变更必须由composer update生成，并附带outdated差异摘要 - 审查工具自身也要锁定版本，例如在
phpstan.neon里写死level: 7，避免因低版本 phpstan 导致漏报
composer install 这个动作本身，而是你如何把它和审查工具的执行时机、环境约束、锁文件完整性绑在一起。漏掉其中任一环，所谓“规范性”就只剩个空壳。 
