在企业代码库中采用严格的 PHPStan 基线的理由
Source: Dev.to
Problem
对一个遗留的 PHP 应用进行现代化改造时会出现一个悖论：你迫切需要严格的静态分析来防止未来的 bug，但一打开 PHPStan 之类的工具就会立刻抛出成千上万的错误，导致 CI 流水线彻底崩溃。
在最近一次对企业平台（rlh‑core）的稳定性项目中，代码库的业务逻辑非常优秀，但却充斥着缺失返回类型、松散的数组定义以及使用 empty($message) 而不是严格的 null 检查等问题。
一种天真的做法是暂停一个月的功能开发，强迫团队修复所有现有错误，直到 PHPStan 变绿——这种做法在财务上不可持续。
然而如果关闭 PHPStan，技术债务就会在无人监管的情况下继续累积。
Solution: PHPStan Baseline Pattern
-
将 PHPStan 配置为最高严格度（Level 8）。
-
对整个代码库运行它，并将输出写入基线文件：
vendor/bin/phpstan analyse -c phpstan.neon --error-format=raw > phpstan-baseline.neon生成的
phpstan-baseline.neon充当现有技术债务的加密签名，告诉 CI 流水线在标识的行上忽略这些特定错误。 -
提交基线文件。此后 CI 流水线在严格的 Level 8 规则仍然开启的情况下能够通过（绿灯），而所有新代码都受到同样的约束。
-
强制基线规则：当文件因新功能被修改时，必须解决该文件中基线记录的错误。
-
自动清理：当工程师修复了某个问题（例如将
empty()替换为严格的 null 检查），PHPStan 会检测到错误已不存在，并提示从基线中移除相应条目（reportUnmatched: true）。
Results
- 在六个月内，基线错误从 约 5,000 条缩减到不足 300 条，且没有专门的重构冲刺。
- 任何违反严格规则的新代码（缺失返回类型、未检查的数组键等）都会导致构建失败，防止新的债务被引入。
- 通过对新代码强制严格边界并逐步消除遗留问题，应用变得高度确定且类型安全。
Takeaway
在处理企业级技术债务时，策略不是“把房子烧掉”，而是 通过对所有新开发强制严格的静态分析来阻止继续添柴，同时系统性地消除已有的问题。
Originally published at VictorStack AI — Drupal & WordPress Reference.