PHPStan必须用composer require --dev安装，否则会污染生产环境、引发类冲突或意外加载测试依赖；需在phpstan.neon中显式配置paths和autoload_files，并避免误入require字段。
PHPStan 必须用 composer require --dev 安装，否则会污染生产环境、引发类冲突或意外加载测试依赖——这不是可选项，是必须遵守的边界。
为什么 composer require phpstan/phpstan 是危险操作
这条命令默认写入 require 字段，导致 PHPStan 的 autoloader 和分析器类在生产环境被加载。它不是运行时库，却会和项目中同名类（比如 Static）发生命名冲突；更隐蔽的是，像 phpstan-phpunit 这类插件会悄悄拉入 phpunit 依赖，破坏生产环境纯净性。
- 检查
composer.json：确认phpstan/phpstan出现在require-dev下，而非require - 运行
composer show phpstan/phpstan，输出中应含dev-master或类似标记，而非列为“required package” - 若已误装，执行
composer remove phpstan/phpstan后重装：composer require --dev phpstan/phpstan
phpstan analyse 报 “Class not found” 怎么定位路径配置
PHPStan 默认只扫描 src/ 和 tests/，如果你的代码在 app/、lib/ 或通过 include_once 加载，就会跳过或报错。它不读取 autoload 配置里的 PSR-4 映射，必须显式声明。
- 在
phpstan.neon中补全paths：paths: [app, lib, src] - 若类靠全局函数注册（如 Laravel 的
helpers.php），加autoload_files: [app/helpers_for_phpstan.php]，该文件只做include，不执行逻辑 - 避免用
excludes_analyse掩盖问题——那等于放弃整块代码的静态检查
composer validate --strict 不是语法检查，是 Schema 合规性校验
它不会帮你找 JSON 少逗号或中文引号，而是查字段是否缺失、类型是否错、拼写是否对（比如 autoloader 应为 autoload）。默认 warning 不中断 CI，需额外参数才能让流水线失败。
- 本地快速验证 JSON 语法：用
php -r "$j=file_get_contents('composer.json'); json_decode($j) or die(json_last_error_msg());" - CI 中固定用：
composer validate --strict --no-check-publish，后者防因网络或权限中断流程 - 典型
--strict报错：Property authors is not defined（应为复数）、"type": "libary"（拼写错误）
真正难的不是跑通命令，而是让 phpstan.neon 的 level 和 paths 贴合项目真实结构，同时不把 autoload_files 变成运行时入口——这两处配错，静态分析就只剩形式主义。
