ThinkPHP 的 validate 方法不能替代权限控制，它仅校验数据格式和业务规则，不检查资源归属；权限控制必须在控制器或中间件中显式校验用户与资源的关系。
ThinkPHP 的 validate 方法不能替代权限控制
很多人以为在控制器里调用 $this->validate($data, $rule) 就能防越权，其实它只校验数据格式和业务规则（比如“用户名必须是邮箱”），完全不检查当前用户是否有权操作该资源。例如：用户 A 请求修改 ID 为 100 的订单，validate 只会看 order_id 是不是数字、是否非空，但不会判断“这个订单是不是属于用户 A”。
常见错误现象：ValidateException 被抛出但越权请求仍成功执行（因为校验通过了，而权限没做）。
- 参数差异：
validate的$rule是字段级规则，不是资源归属判断逻辑 - 使用场景：适合用于注册表单、搜索条件过滤等，不适合用于“编辑他人文章”“删除非本人评论”类操作
- 性能影响：过度依赖 validate 做权限判断会导致规则臃肿、难以维护，且无法复用 RBAC 或策略类逻辑
必须在控制器中显式校验资源归属或角色权限
ThinkPHP 没有自动拦截“URL 越权”的机制，所有资源访问都得靠开发者自己加一层判断。最直接的做法是在操作方法开头，查数据库确认当前用户是否拥有该资源的操作权。
示例：用户编辑文章时，需确认 $article->user_id === $this->auth->id：
立即学习“PHP免费学习笔记（深入）”；
// 控制器方法内
$article = Article::find($id);
if (!$article || $article->user_id !== $this->auth->id) {
throw new HttpException(403, '无权访问该资源');
}
- 容易踩的坑：用
where('id', $id)->find()直接取数据却没校验归属，导致越权 - 更安全写法：把用户 ID 直接作为查询条件，避免先查再判断，如
Article::where('id', $id)->where('user_id', $this->auth->id)->find() - 兼容性注意：如果项目用了多租户或团队协作模型，
user_id可能要换成team_id或配合策略类判断
结合 Auth 组件与中间件统一拦截高危操作
ThinkPHP 的 think-auth 或自定义 Auth 类可以封装权限检查逻辑，但关键在于——这些检查必须被强制执行，不能靠开发人员“自觉调用”。中间件是最可靠的方式。
比如为 /admin/article/edit/:id 路由配置权限中间件：
// route.php
Route::get('admin/article/edit/:id', 'Admin/Article/edit')
->middleware('checkOwnArticle');
中间件内做归属校验：
// app/middleware/CheckOwnArticle.php
public function handle($request, \Closure $next)
{
$id = $request->param('id');
$article = Article::where('id', $id)->where('user_id', session('user.id'))->find();
if (!$article) {
throw new HttpException(403, '越权访问');
}
return $next($request);
}
- 为什么这样做：避免每个控制器方法重复写校验，也防止遗漏
- 注意点：中间件获取用户信息要稳定（推荐用
session或Token解析后的user.id，别依赖未初始化的$this->auth） - 性能提醒：如果
Article表很大，建议给(id, user_id)加联合索引
URL 参数不能信，所有关键 ID 都要重查+重校验
有人觉得“前端隐藏了 ID，或者用了 UUID 就安全”，这是典型误区。URL 参数、Query 字符串、POST Body 里的任何 ID，都是客户端可控的，必须当作不可信输入处理。
尤其注意以下几种情况：
- 批量操作接口（如
POST /article/delete接收数组['1','2','100']）：必须逐个校验每个 ID 归属，不能只校验第一个 - 关联资源（如评论属于某文章）：不仅要查评论是否存在，还要确认其所属文章是否属于当前用户（防止“绕过文章层直接删评论”）
- 软删除场景：
delete_time IS NULL必须加入所有资源归属查询条件，否则可能误删已软删的数据 - 缓存穿透风险：如果用 Redis 缓存了文章信息但没缓存归属关系，直接读缓存跳过 DB 查询，就可能漏掉权限判断
复杂点往往不在“怎么写”，而在于“在哪写”——权限校验的位置一旦错位（比如放在视图渲染后、事务提交前），就等于没做。
