composer本身不是静态分析工具，仅负责安装和管理phpstan、psalm、phpcs等真正执行分析的库；选phpstan适合快速落地且内存占用低，psalm类型检查更激进但易误报，phpcs只查风格不分析控制流或类型。
Composer 本身不是静态分析工具，它只是依赖管理器；想用 Composer 库实现高性能 PHP 静态分析，核心得靠 phpstan、psalm 或 phpcs 这类真正做分析的库，Composer 只负责装它们、配 autoloader、跑命令——别指望 composer install 自己“看懂代码”。
怎么选底层分析引擎：phpstan vs psalm vs phpcs
三者定位不同，混用反而拖慢 CI 流程。选错会白调参数、白写配置：
-
phpstan适合快速落地，对类型推导保守但稳定，--level=5已覆盖多数空指针/未定义变量问题，内存占用低，适合大项目增量接入 -
psalm类型检查更激进，支持assert和自定义 stub，但默认开启所有检查项后容易报一堆 false positive，需手动关掉InvalidArgument等非关键项 -
phpcs（+squizlabs/php_codesniffer）只查风格和基础语法，不分析控制流或类型，phpcbf能自动修复，但和“静态分析”本质不在一个维度
让 phpstan 启动快的关键：配置文件 + 内存预热
默认 phpstan analyse 每次都重建 AST，大项目卡在 30 秒以上很常见。不是代码问题，是配置没压对：
- 必须用
phpstan.neon（不是.phpstan.php），YAML 格式解析更快，且支持includes:复用规则集 - 禁用实时扫描：
scanDirectories:改成只列src/和tests/，别加vendor/或node_modules/ - 加
memory_limit: 512M到phpstan.neon，PHP 默认内存不够，会反复 GC 导致 CPU 占满但进度不动 - CI 中先跑
phpstan clear-result-cache，避免旧缓存污染新分支的分析结果
如何用 Composer 插件接管分析流程（而非硬编码命令）
直接写 composer run phpstan 容易失控，尤其多人协作时版本/参数不一致。用 composer.json 的 scripts 和 require-dev 锁死行为：
- 在
require-dev里明确指定"phpstan/phpstan": "^1.10.3"，别用^1.10——小版本升级可能改默认 level 或禁用某个 check -
scripts里拆开命令："phpstan:base": "phpstan analyse --no-progress --configuration=phpstan.neon src"，把路径和配置固化，不依赖环境变量 - 加个
"phpstan:ci": "phpstan:base --xdebug --fail-on-error"，CI 专用，启用 Xdebug 兼容模式（某些 CI 环境强制开 Xdebug）且失败立即退出 - 别在
post-autoload-dump里触发分析——Composer 自身 autoload 机制和静态分析器的 class loader 冲突，会导致Class not found错误
真正难的不是装库或写配置，是判断哪一行警告该修、哪一行该 suppress——比如 PHPDoc type 'array' is not subtype of 'string'，可能是注解写错，也可能是函数确实返回 mixed 但文档没更新。这时候得打开 phpstan 的 --debug 看具体 AST 节点，而不是盲目加 @phpstan-ignore-line。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
