PHP静态分析用PHPStan还是Psalm

wen PHP项目 2026-07-10 1

本文目录导读：

核心结论（极简版）
详细对比
如何选择（决策树）
终极建议：都试一下！
最后的思考

在PHP静态分析工具的选择上,PHPStan 和 Psalm 都是非常优秀且成熟的选择，两者在核心能力上旗鼓相当，但各有侧重，以下是一个详细的对比分析，帮助你根据自身项目需求做出决定：

核心结论（极简版）

追求极致的严格性、深度类型推导、分析大型复杂框架（如 Laravel/Symfony）：首选 PHPStan（尤其是 level 6+）。
追求开箱即用、零配置、更快的初次运行速度、以及与现代 PHP 特性（如泛型）的强兼容性：首选 Psalm。

详细对比

特性维度	PHPStan	Psalm
严格程度	公认更严格，它有 0-9 共 10 个级别，级别 6 以上对标 Psalm 的严格级别，级别 9 可检测最细微的边界问题（如循环中变量类型变更）。	也有 0-8 的级别，但其严格模式（`--strict`）非常强大，在极端严格性上，两者都能达到很高水准，但 PHPStan 的“暗黑风格”级别（6+）更考验代码。
类型推导能力	更强，特别是对框架的魔法方法（如 `__call`、`__get`）和复杂集合操作（如 `collect()->map()->filter()` ）的推导精度更高。	也很强，但对某些复杂动态代码可能不如 PHPStan 准确，需要更多显式注解。
插件生态	更丰富、更活跃，有官方支持的 Laravel、Symfony、WordPress、Doctrine 等插件，社区贡献了大量针对特定库的插件。	插件生态也不错，但不如 PHPStan 那么广泛，官方提供了 Laravel、Symfony 等常见插件的支持。
与IDE集成	通过 PHPStan Pro 或 Laravel IDE Helper 集成，在 PhpStorm/VS Code 中通过 LSP 插件使用，体验良好。	原生支持 LSP，与 IDE 集成更直接、更丝滑，其内部就包含了一个 LSP 服务器。
配置复杂度	配置项较多且灵活，有时需要为特定场景（如框架魔法方法）手动添加 stub 文件或配置，插件安装和管理较简单。	开箱即用，默认配置就能检测绝大多数问题，配置更直观，较少需要复杂的 stub 文件。
性能	对大型项目，第一次运行可能稍慢（因为需要深度分析），但后续运行（利用缓存）速度很快，对于极大型项目（50万+行代码），内存占用可能较高。	通常更快，尤其在初次运行时，其分析引擎设计更注重速度，内存管理也较好。
错误信息清晰度	错误信息非常详细，会明确指出类型推导的路径和冲突点，帮助定位问题，但有时信息量太大，需要习惯。	错误信息简洁清晰，通常一行就能说明问题，并附有代码片段，对新手更友好。
对新特性的支持	对 PHP 8.0+ 新特性（命名参数、枚举、弱映射等）支持非常及时且彻底。	同样对新特性支持极好，且对泛型的支持（`@template`）在理念上更先进，分析更精准。
维护与社区	在 Github Stars（6.8万+ vs 5.4万+）和 Packagist 下载量上明显领先，贡献者和插件生态更活跃。	社区活跃度也很好，更新频率正常，在静态分析领域是可靠的第二选择。

如何选择（决策树）

如果项目使用了以下框架或库之一，并且想获得最佳开箱即用体验：
- Laravel：强烈推荐 PHPStan + phpstan-laravel 插件，它的魔法方法（如 Model::find()、Collection）分析精度无人能及。
- Symfony：两者都可，但 PHPStan 的 symfony-phpstan 插件更成熟。
- 使用大量泛型（如集合、集合框架）：Psalm 对 @template 的处理更优雅，错误信息更易读。
如果团队风格偏好：
- “严格模式信徒”：两者都行，但 PHPStan 的 Level 9 是终极考验，如果你喜欢挑战并迫使团队写出更严谨的代码，选 PHPStan。
- “渐进式引入”：Psalm 从默认级别开始，错误更少更清晰，学习曲线更平滑。
- “IDE 驱动”：如果你极度依赖 IDE 的实时分析，Psalm 的 LSP 集成更原生。
如果项目非常古老（如 PHP 5.6 遗留项目）：
- 两者都支持，但 PHPStan 的配置可能需要更多手动调整来处理 mixed 和 @return 缺失的情况。

终极建议：都试一下！

最科学的做法： 在项目根目录分别运行一次，对比错误数量和类型。

# 安装并运行 PHPStan
composer require --dev phpstan/phpstan
./vendor/bin/phpstan analyse src/ --level=max --memory-limit=2G
# 安装并运行 Psalm
composer require --dev vimeo/psalm
./vendor/bin/psalm --init
./vendor/bin/psalm --show-info=true

看结果：

PHPStan 报的错误比 Psalm 多得多，说明项目代码风格更接近 Psalm 的假设，或者 PHPStan 过于严格，选择 Psalm 对你来说更高效。
Psalm 报的错误比 PHPStan 少很多，但有些明显的问题（如 if ($x = 5) 这种赋值语句）Psalm 没抓到，那 PHPStan 更严谨。
如果两者报错数量相近,则选你更喜欢其错误信息风格的那个。

最后的思考

可以同时使用吗？ 在大型项目中，不少团队同时使用两者，用 PHPStan 跑最高级别（如 Level 8/9）作为“终极代码审计”，用 Psalm 作为 CI 中的“日常快检”和 IDE 实时提示，但这对配置和 CI 时间有额外要求。
未来趋势：目前来看，PHPStan 的社区和生态领先优势在扩大，新出的 PHP 特性（如 8.2 的常量类型、8.3 的 json_validate）PHPStan 通常更早支持，如果你选择一个工具长期使用，PHPStan 的“生存概率”稍高。

最终结论：

如果你是 Laravel 重度用户或追求极致的静态分析严格性 → 选 PHPStan。
如果你看重开发体验、团队新手多、想快速获得一个有价值的工具 → 选 Psalm。
两害相权取其轻：如果非要做选择，目前建议默认选 PHPStan，因为它的生态和严格性能带来更高的代码质量回报。