ThinkPHP 8.0 代码审计必须先确认四点基线：1. 所有PHP文件首行含declare(strict_types=1)；2. 模型中$pk与$pkType必须成对显式声明；3. 路由注册须用数组语法如[User::class, 'read']；4. ORM空值判断需改为null===或instanceof，不可用!$data。
ThinkPHP 8.0 代码审计不能靠“猜漏洞”，得先稳住框架行为基线——declare(strict_types=1) 没开，类型绕过就成常态；模型没声明 $pkType，主键比较逻辑直接失效；路由用字符串写法（如 'index/User/read'），连请求都进不了控制器。这些不是“可能出问题”，而是审计时一碰就塌的底层地基。
strict_types=1 是审计前提，不是可选项
TP8 的类型约束只在 PHP 语言层生效，框架不干预。没加 declare(strict_types=1)，哪怕方法签名写 public function detail(int $id)，传入 "1" 也会静默转成 int，后续所有基于类型判断的逻辑（比如是否为合法 ID、是否触发缓存 key 分支）全不可信。
- 必须检查每个控制器、模型、服务类文件的
<?php后第一行，确认紧贴着有declare(strict_types=1); - 别信配置文件里加
'strict_mode' => true，该键根本不存在，框架完全忽略 - 审计时发现某处
int参数被字符串绕过，第一反应不是看框架，而是翻源文件顶部——90% 是这里漏了声明
模型主键类型必须显式声明 $pkType
TP8 中 $model->find(1) 返回 null 不报错，很可能是因为框架无法推断主键是 int 还是 string，导致 SQL 生成时用了错误的引号包裹或类型转换，查不到数据却无提示。
- 在模型类中，
protected $pk = 'id';和protected $pkType = 'int';必须成对出现，且$pkType行不能被注释隔开 - 若主键是 UUID 或短链 ID（如
"abc123"），必须写protected $pkType = 'string';，写成'int'会导致 WHERE id = 0 永远查不到 - 审计 ORM 查询逻辑时，看到
find()、where()或关联查询结果异常，优先 grep$pkType—— 没声明就是硬伤
路由注册必须用数组语法，否则请求根本进不来
旧式字符串路由 Route::get('user/:id', 'index/User/read') 在 TP8 中直接 404，因为底层路由解析器已废弃字符串控制器映射，改用反射调用。审计时如果发现某个 URL 路由定义存在但始终不进控制器，大概率是语法没升级。
立即学习“PHP免费学习笔记（深入）”；
- 正确写法是
Route::get('user/:id', [app\controller\User::class, 'read']); - 若路由文件里混用两种写法，需逐行替换，不能只改一部分——混合写法会导致部分路由失效且无日志提示
- 审计中间件或前置逻辑时，先确认请求是否真抵达了目标控制器：在控制器方法开头加
exit('hit');，若没输出，说明路由没走通，回头查语法
ORM 返回 null 的行为变更影响所有空值判断
TP8 的 find()、select() 等方法在查不到数据时统一返回 null 或空集合，不再返回 false。旧代码里写 if (false === $data) 或 if (!$data) 判断失败，会在 TP8 中误判非空数据为失败。
- 所有模型查询后判断逻辑，必须改为显式比较：
if (null === $user)或if ($user instanceof Model) - 特别注意关联查询：
$user->posts若 posts 表无数据，在 TP8 中返回空集合而非null，用empty($user->posts)是安全的，但!$user->posts可能因对象存在而恒为 false - 审计业务逻辑时，看到用户登录、权限校验等关键路径返回异常（如未登录却跳转成功），重点检查这类空值判断是否还沿用 TP6 或更早的习惯
真正卡住审计进度的，往往不是多复杂的漏洞链，而是这些框架级约定没对齐——类型开关、主键类型、路由语法、空值语义，四者任一错位，整个调用链就跑偏。动手前花五分钟扫一遍这些点，比后面花两小时追错强得多。
