必须用--dev安装，否则PHPStan会污染生产环境并引发类冲突；因其非运行时依赖，默认require安装会导致其autoloader和测试依赖被加载进生产环境，应确认其位于composer.json的require-dev字段下。
必须用 --dev 安装，否则 PHPStan、PHP_CodeSniffer 等工具会污染生产环境，甚至引发类名冲突或运行时报错。
为什么 composer require phpstan/phpstan 是错的
这条命令默认写入 require 字段，导致 PHPStan 的 autoloader 和分析器类被加载进生产环境。它不是运行时依赖，却会偷偷引入 phpunit、symfony/test-pack 等测试相关依赖——CI 构建可能成功，但线上容器启动时可能因类重复定义或 static 类名冲突直接失败。
- 确认已安装在
require-dev：打开composer.json，检查"phpstan/phpstan"是否出现在"require-dev"下，而非"require" - 避免
autoload-dev误包含工具路径：PHPStan 自身无需被自动加载，不要在autoload-dev.files中添加它的 bootstrap 文件 - 若已误装，执行
composer remove phpstan/phpstan后重装：composer require --dev phpstan/phpstan
phpstan analyse 找不到你的类怎么办
PHPStan 默认只扫描 src/ 和 tests/，如果你的代码在 app/、lib/ 或使用了非 PSR-4 的加载方式（比如 include_once 'Helpers/Util.php'），就会报 Class not found 或静默跳过。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 在
phpstan.neon中显式声明路径：paths: - app - lib - 对全局函数或
include类型文件，用autoload_files加载引导文件：autoload_files: [app/bootstrap_for_phpstan.php]，该文件只做include，不执行逻辑 - 检查
composer.json的autoload是否覆盖全部源码目录；若用classmap，确保已运行composer dump-autoload
phpcs 和 php-cs-fixer 到底该全局装还是局部装
全局安装（composer global require）看似方便，但会导致团队成员版本不一致、CI 环境缺失、PHP 版本兼容性问题频发。现代 PHP 项目应统一走局部安装路线。
- 执行
composer require --dev squizlabs/php_codesniffer friendsofphp/php-cs-fixer - 校验标准是否生效：
./vendor/bin/phpcs --standard=PSR12 src/，不是phpcs命令本身 - 修复代码用
./vendor/bin/php-cs-fixer fix src/ --rules=@PSR12，注意--rules参数不能省，否则默认规则极宽松 - 把常用命令写进
composer.json的scripts，例如："cs:fix": "php-cs-fixer fix src/ --rules=@PSR12"，之后只需composer cs:fix
level 8 报一堆错误，能跳过吗
可以临时忽略，但别用 excludes_analyse 排除整个文件——那等于放弃对该文件所有类型检查。真正该做的是生成基线（baseline），让 PHPStan 只报告“新增”问题。
- 首次运行：
./vendor/bin/phpstan analyse src/ --generate-baseline=phpstan-baseline.neon - 后续 CI 中改用：
./vendor/bin/phpstan analyse --configuration=phpstan-baseline.neon - 基线文件要提交进 Git，每次有人修改它，都意味着主动接受新问题——这是团队对质量边界的共识锚点
最常被忽略的一点：PHPStan 的 bootstrapFiles 和 scanDirectories 不是可选项，而是解决“找不到类”的第一响应项；很多人卡在报错上，其实只是没告诉它去哪找你的代码。
