PHPStan必须本地安装，全局安装会导致配置不加载、类找不到、扫描静默失效；正确做法是项目根目录执行composer require --dev phpstan/phpstan，phpstan.neon须置于根目录并含正确parameters块。
PHPStan 必须本地安装，全局安装等于没装——配置不加载、类找不到、扫描静默失效，这不是 bug，是设计使然。
为什么 phpstan analyse 没报错却什么都没扫到
最常见原因是配置文件未被识别，而 PHPStan 不会主动提示“配置没读到”，它只会安静地 fallback 到默认行为（只扫 src/、level 0、跳过所有 autoload 映射）。
-
phpstan.neon必须放在项目根目录，不能叫phpstan.yaml、.neon或phpstan.neon.dist（除非显式用--configuration指定） -
parameters:块必须存在，且level和paths必须在其下正确缩进（YAML 对空格敏感，推荐用 2 空格） - 若代码不在
src/下（比如 Laravel 的app/、Symfony 的src/+tests/），必须手动写进paths，否则直接跳过 - 执行
vendor/bin/phpstan analyse --debug可看到实际加载的配置路径和扫描的文件列表，这是验证配置是否生效的最快方式
composer require --dev phpstan/phpstan 后仍报 “Command not defined”
说明 PHPStan 主体根本没装进 vendor/bin/，或 Composer 没生成可执行脚本。
- 确认命令是在项目根目录（含
composer.json）下执行的，不是在子目录或全局环境 - 检查
composer.json的require-dev是否真写了"phpstan/phpstan": "^1.10"（别留^0.12这种老版本） - 运行
composer dump-autoload -o，否则新类可能无法被 PHPStan 的自动加载器识别 - 如果之前误用过
composer global require，删掉全局安装（composer global remove phpstan/phpstan），再重装本地版
paths 和 level 配合不好，第一次运行就失败或漏报
错误组合会让 PHPStan 在解析阶段崩溃，或掩盖真实类型问题。
立即学习“PHP免费学习笔记（深入）”；
-
level: 9要求所有类都有完整类型声明，若项目里大量用array或无返回类型的函数，先从level: 5开始更稳妥 -
paths别盲目加多：比如把vendor/加进去，会导致分析卡死或内存溢出；把tests/fixtures/加进去但没配autoload-dev，就会报Class XXX not found - 纯函数文件（如
src/helpers.php）无命名空间，PHPStan 默认不加载，必须在phpstan.neon中显式声明：parameters: { autoload_files: ["src/helpers.php"] } - 排除路径用
excludePaths，不是注释掉paths条目——后者会导致整个目录不参与扫描
CI 环境（GitLab CI / GitHub Actions）里 phpstan analyse 报错
90% 不是 PHPStan 本身的问题，而是环境链路断裂：自动加载没触发、配置路径不对、或扩展缺失。
- CI 脚本中必须包含
composer install --no-interaction --prefer-dist，确保vendor/autoload.php存在且可读 - 不要依赖
phpstan全局命令，始终用./vendor/bin/phpstan analyse - 若项目用了 Larastan、Symplify 或其他扩展，
includes:必须写全路径，例如：- vendor/nunomaduro/larastan/extension.neon - PHP 版本需匹配：PHPStan 1.x 要求 PHP 7.4+，2.x 要求 PHP 8.1+；CI 镜像若用的是 PHP 7.3，装了也跑不起来
最容易被忽略的一点：PHPStan 的类型推导严重依赖 Composer 的 autoload 配置。哪怕 phpstan.neon 写得再全，只要 composer.json 里 autoload 或 autoload-dev 缺失映射，它就认不出你写的类——这不是配置问题，是底层机制决定的。
