确保当前请求绑定真实、已认证且有权限的用户id，必须从securitycontext或tokenstorage获取用户对象，禁止依赖路由或get参数；专属路径应通过命名路由动态生成；关联查询须在where中严格限定用户id。
查用户专属路径，关键不是“怎么拼URL”，而是“怎么确保当前请求绑定的是真实、已认证、且有权限的用户ID”。硬编码路径或手动传 id 参数极易绕过权限校验，导致越权访问。
关联用户ID必须从 SecurityContext 或 TokenStorage 中取
不能依赖路由参数（如 {id}）或 GET 参数来判定“当前用户”。Symfony 的安全体系默认把认证用户对象挂载在 TokenStorage 里：
-
$user = $this->getUser()是最简方式，但仅在控制器中可用，且要求用户已登录（否则返回null） - 在服务类、Repository 或事件监听器中，需注入
TokenStorageInterface，再调用$tokenStorage->getToken()->getUser() - 务必先判空：
if (!$user instanceof User)，避免未登录时调用getId()报错
专属访问路径应由路由生成，而非字符串拼接
路径逻辑分散在模板、JS、邮件链接中时，硬拼 /user/123/dashboard 会导致一处改、多处漏。正确做法是定义带占位符的命名路由，并用 generateUrl() 动态填充：
- 在
routing.yml中定义：user_dashboard: path: /user/{id}/dashboard defaults: { _controller: 'App\Controller\UserController::dashboard' } - 控制器内生成：
$this->generateUrl('user_dashboard', ['id' => $user->getId()]) - 模板中用：
{{ path('user_dashboard', {'id': app.user.id}) }} - 注意：若
app.user为null，Twig 会报错，需加app.user and app.user.id判断
关联查询时，别名和条件必须严格对应用户上下文
当需要查“当前用户拥有的资源”（比如用户文章、订单），JOIN 本身不解决权限问题，WHERE 条件才是关键防线：
- 错误写法：
$qb->join('u.posts', 'p')->where('p.status = :status')—— 没限定用户，查的是全站文章 - 正确写法：
$qb->where('u.id = :userId')->setParameter('userId', $user->getId())，主表别名u必须指向用户实体 - 如果用
leftJoin()查用户及关联数据（如头像、设置），仍需在WHERE中锁定u.id，否则左联后结果集可能混入其他用户记录 - 别名冲突常见于多次 JOIN 同一关系（如用户有多角色），此时必须用不同别名：
join('u.roles', 'r0')和join('u.roles', 'r1')，并分别加条件
最容易被忽略的是：路由参数 {id} 和认证用户 $user 完全是两套机制。哪怕 URL 是 /user/999/dashboard，也绝不意味当前操作的就是 ID=999 的用户——除非你显式做了 if ($user->getId() !== (int) $request->get('id')) { throw $this->createAccessDeniedException(); }。权限校验永远要落在业务逻辑层，不能靠路径“看起来像”。
