Larastan必须配合Laravel运行时上下文才能正确识别“魔法”行为，否则会大量误报或静默跳过检查；paths配置错误导致模型属性检查失效，level
直接上结论：Larastan 不是“装了就能用”的通用静态分析器，它必须配合 Laravel 运行时上下文才能正确识别模型属性、容器绑定、门面调用等“魔法”行为；跳过 bootstrap 或路径配置错误，phpstan analyse 会大量误报甚至静默跳过关键检查。
phpstan.neon 中 paths 配置错会导致模型属性检查失效
Larastan 依赖扫描 app/ 目录下的模型类来推断数据库字段类型。如果 paths 漏掉 app/Models（比如只写了 app 但项目实际用的是 app/Models 子目录），或误加了 vendor，就会：
- 找不到模型类 → 无法推导
$user->name是string还是null - 把合法的 Eloquent 属性访问当成 “Access to an undefined property” 错误
- 关系方法如
user()的返回类型注解被忽略
✅ 正确写法（适配 Laravel 11+ 默认结构）：
parameters:
paths:
- app/Models
- app/Providers
- app/Http/Controllers
level: 5 是起点，但 level: 7 才能捕获服务容器绑定类型错误
Larastan 的 level 决定是否启用对容器绑定的深度分析。低于 level 6 时，AppServiceProvider::register() 中的 $this->app->bind(Interface::class, Concrete::class) 不会被校验接口与实现类的契约一致性。
常见问题场景：
- 绑定了一个返回
array的闭包，但接口声明返回Collection - 用
singleton()绑定可变参数构造函数，但未标注@param -
resolve()调用时传入错误类型的参数
⚠️ 注意：level: 7 会强制要求所有服务提供者中的 bind/singleton 调用有明确类型提示，否则报 Parameter #1 $abstract of method Illuminate\Container\Container::bind() expects class-string, string given。
bootstrap.php 启动失败时，Larastan 会静默降级为普通 PHPStan
Larastan 的核心能力——理解门面、解析模型关系、读取迁移字段——全靠 bootstrap: vendor/nunomaduro/larastan/bootstrap.php 启动一个轻量 Laravel 应用实例。一旦这个启动失败：
- 不会报错退出，而是退回到基础 PHPStan 模式
-
Auth::user()、config('app.name')全部被当作文本字符串处理 - 模型上的
@property注解被忽略，$post->author->email直接标红
排查方法：
- 运行
./vendor/bin/phpstan analyse --debug，看是否卡在Bootstrap file executed - 检查
bootstrap/app.php是否被自定义修改，导致Application构造失败 - 确认
.env中数据库配置不触发连接（Larastan 启动时不连 DB，但某些自定义服务提供者会）
@phpstan-ignore-line 不是万能的，高阶消息和动态方法要慎用
像 $users->each->delete() 或 Cache::store('redis')->get('key') 这类链式调用，Larastan 在 level ≥ 6 下会报 Call to an undefined method。此时加 // @phpstan-ignore-line 确实能过，但掩盖了真实风险：
- 如果
$users实际是空集合，each->delete()不执行，逻辑可能漏掉 -
Cache::store()返回类型在不同驱动下不一致，get()可能返回mixed而非预期string - 后续升级 Laravel 版本后，该语法可能被弃用（如 Laravel 12 移除部分高阶消息）
更稳妥的做法是显式展开：
$users->each(function ($user) {
$user->delete();
});
或者补全类型注解：
/** @var \Illuminate\Support\Collection<int> $users */ $users->each->delete();</int>
