thinkphp中空指针错误主因是未校验变量类型与存在性，须在使用前明确判断对象、数组、键值等是否合法，而非依赖isset()或盲目默认，模板、模型、中间件均需统一兜底。
ThinkPHP 项目里出现 Trying to get property 'xxx' of non-object 或 Illegal string offset，八成不是 PHP 版本问题，而是变量在进入使用前没校验类型或存在性。防不住空指针，不是因为语法难，是习惯没养成——尤其在处理接口返回、数据库查询结果、用户输入时。
用 isset() 和 is_object() 前先想清楚「它该是什么」
直接写 $user->name 前，得确认 $user 是对象；写 $data['id'] 前，得确认 $data 是数组且含 id 键。但别无脑套 isset()：它对 null、false、0、'' 都返回 false，而这些可能是合法值。
- 查库返回可能为
null（比如UserModel::find(999)），此时用if ($user instanceof User)比isset($user->name)更准 - 接口返回 JSON，解码后可能是
null（JSON 解析失败）或[]（空数组），得先is_array($res) && !empty($res) -
input('page', 1, 'intval')这种带默认值和过滤的写法，比$_GET['page'] ?? 1更可靠——后者不防字符串"abc"
foreach 前必须过 is_array()
报错 Invalid argument supplied for foreach() 的根因永远是：你把 null、string、object 当成了数组传给了 foreach。ThinkPHP 的 select()、paginate()、collection->toArray() 都可能返回非数组值。
- 永远在
foreach前加守门：if (is_array($list)) { foreach($list as $item) { ... } } - 别依赖模型自动转数组：
UserModel::where(...)->select()在查不到时返回空集合对象，->toArray()才是[]；但->find()查不到就是null - 模板里用
{volist name="list" id="item"}比手写foreach安全，因为 Volist 标签内部已做数组判断
模板中嵌套变量取值必须带默认值或判空
TP6 默认关闭调试模式，{$user.profile.avatar} 取不到时静默忽略，看着页面空白却没报错，排查成本翻倍。
- 强制用默认值语法：
{$user.profile.avatar|default='//default.png'}，|default是安全底线 - 深层结构建议拆开判断：
{if !empty($user) && !empty($user['profile']) && !empty($user['profile']['avatar'])}{$user['profile']['avatar']}{/if} - 控制器传参时就做兜底：
$this->assign('user', $user ?: ['profile' => []])，别把脏活全丢给模板
模型字段读写要分清「存在性」和「可写性」
空指针常藏在「以为字段一定存在」的假设里。比如 $model->status 在新增时未设值，save() 后仍是 null，后续代码直接调 $model->status->name 就崩。
- 模型定义里用
protected $type = ['status' => 'integer']，让 TP 自动转类型，避免null写进 int 字段再读出变0导致逻辑错乱 - 虚拟字段（如
$append = ['full_name']）必须在getFullNameAttr()里自己判空：return $this->name . ($this->last_name ?: '') - 不要在
beforeWrite钩子里 unset 字段来“防写入”，那只是跳过赋值；真正要防的是后续代码拿这个字段做对象操作——得在 getter 里兜底
最易被忽略的一点：空指针错误往往不发生在你写的主逻辑里，而是在异常分支、回调函数、中间件响应处理中。比如日志中间件里记录 $request->user()->name，但未登录时 $request->user() 返回 null，整个请求就 500 了。防空指针，本质是每一步都明确「这个变量此刻是否可信」。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
