phpstan在thinkphp 8.0中必须显式配置phpversion（如80100）、引入think-stubs.php补全魔术方法、且所有php文件首行声明declare(strict_types=1)，否则db::table()等调用被误判、param()返回类型为mixed、类型断言失效。
上线后一堆 Bug，不是测试没做够，而是静态分析根本没跑起来——ThinkPHP 8.0 项目里，PHPStan 默认连 Db::table() 都不认识，request()->param('id') 的返回类型也当 mixed 处理，类型断言全失效。
phpVersion 必须显式设为最低目标版本
PHPStan 在 PHP 8.2 环境下分析 ThinkPHP 8.0（要求 PHP 8.1+）项目时，若不配置 phpVersion，它会默认用 8.2 的函数签名去校验，导致 str_contains()、array_key_first() 这类 8.0+ 才有的函数直接“隐身”，漏掉兼容性风险。
-
phpstan.neon中必须写死：phpVersion: 80100（对应 PHP 8.1.0），不能留空或写成80200 - 数值格式严格为「主版本×10000 + 次版本×100 + 修订号」，例如 PHP 8.1.22 →
80122 - ThinkPHP 8.0 自身大量使用 PHP 8.1 特性（如属性提升），但若你项目还要兼容 PHP 8.0，则按
80000设，否则public function __construct(public string $name)会被当作非法语法跳过检查
ThinkPHP 魔术方法必须用 stub 补全，不能只靠 ignoreErrors
直接在 phpstan.neon 里加 ignoreErrors 匹配 #Call to an undefined method.*Db::.*#，看似省事，实则掩盖了真实问题：比如你写了 Db::table('user')->where('id', 1)->find()，而 ThinkPHP 8.0 官方已弃用 table()，推荐用 name() —— ignore 后这个错误就永远消失了。
- 先通过
composer require --dev topthink/think-ide-helper安装辅助包 - 运行
php think ide:stub生成think-stubs.php，它会补全Db、Request、Model等类的魔术方法签名 - 在
phpstan.neon中声明：bootstrapFiles: [think-stubs.php] - 仅对确实无法重构的动态调用加
ignoreErrors，且正则要窄，例如：'#Call to an undefined method app\model\User::getProfileData()#'
strict_types=1 是类型检查生效的前提
ThinkPHP 8.0 所有控制器、模型、服务类文件顶部没加 declare(strict_types=1);，PHPStan 再准也没用——因为运行时连 int 和 string 混传都不报错，静态分析看到的只是“可能合法”的模糊契约。
- 该语句必须是文件中第一个可执行语句，
<?php后立刻写，前面不能有任何空格、BOM 或注释 - 框架配置里的
'strict_mode' => true是无效字段，PHPStan 不识别，也不影响运行时 - 验证是否生效：写一个带类型声明的方法，比如
public function detail(int $id): array，传入'123'字符串，应立即抛出Fatal error: Uncaught TypeError
联合类型参数必须配合空值防护，否则 PHPStan 也救不了
PHPStan 能指出 string|null 类型参数被传入 strtoupper()，但它不会帮你加 if ($x === null)。线上崩溃常发生在 $user->getName()?->toUpperCase() 这种链式调用里——PHP 8.0+ 支持空安全操作符，但 ThinkPHP 8.0 默认不启用，且很多老代码仍用 strtoupper($user->getName())。
-
string|null和?string风险等级为“中”，必须手动判空，PHPStan 只提示，不代劳 - 避免在路由变量或请求参数上直接用
int|null，ThinkPHP 的input('id/d')返回int，但若前端传空字符串，实际得0，不是null，类型契约容易错位 - 联合类型（如
string|int）虽不允null，但运行时仍需防非预期类型，PHPStan 不检查运行时值来源，只校验调用链
最易被忽略的点：PHPStan 分析结果依赖于 php -l 先过一遍——如果语法本身非法（比如 PHP 7.4 项目里用了 PHP 8.0 的 match 表达式），PHPStan 根本加载不了文件，直接退出。所以 CI 流程里，php -l 必须在 phpstan analyse 之前执行，且失败即中断。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
