微信小程序登录态校验必须通过code2Session获取openid并比对，session_key仅用于解密且会轮换；权限需分三层：网关级验证token和openid、路由级校验角色、方法级做数据归属校验。
微信小程序登录态校验必须走 code2Session 且不能省略 openid 比对
很多开发者误以为只要拿到 code 后调用一次微信接口，缓存返回的 session_key 就能长期校验，这是危险的。微信不返回永久 session，session_key 本身无业务意义，也不能直接用于权限判断；真正具备身份唯一性的只有 openid（或 unionid）。权限校验的第一步，永远是确认当前请求携带的 token（或自定义凭证）是否能映射到一个有效的、未过期的 openid。
实操建议：
- 用户首次登录时，用
code调用微信https://api.weixin.qq.com/sns/jscode2session，拿到openid+session_key，生成服务端 token（如 JWT），payload 中必须包含openid和过期时间，不要存session_key - 后续所有接口都校验该 token，并从中解析出
openid，再查数据库确认该用户是否存在、是否被禁用 - 禁止在前端 localStorage 存
session_key或用它拼接签名——微信明确说明session_key会轮换，且不可跨设备复用
权限分层：从「登录态」到「角色/菜单/数据级」要拆成三道关卡
把“有没有登录”和“能不能看这个页面”混在一个中间件里判断，后期维护成本高、易绕过。推荐按粒度分三层，每层只做一件事：
第一层（网关级）：AuthMiddleware —— 验证 token 有效性、解析 openid、写入 $request->user
立即学习“PHP免费学习笔记（深入）”；
第二层（路由级）：RoleMiddleware —— 查数据库获取该 openid 对应的 role_id，比对当前接口所需角色（如 admin、editor），不匹配直接 403
第三层（方法级）：dataScope() —— 在具体 service 方法里，根据用户所属部门、创建人 ID、数据状态等动态拼接 where 条件，例如：where('dept_id', $user->dept_id)->where('status', 'active')
常见错误现象：管理员能看到全部数据，但某个编辑只能看自己提交的订单 → 如果只靠第二层角色控制，就会漏掉数据隔离逻辑，导致越权读取。
getAccessToken 不等于权限校验，别把它塞进鉴权中间件
有些团队把获取微信后台 access_token 的逻辑（调用 https://api.weixin.qq.com/cgi-bin/token）和用户登录态校验耦合在一起，结果一上线就发现接口响应变慢、token 频繁刷新失败。这是典型职责错位。
access_token 是公众号/小程序后端调用微信 API 的凭证，有效期 2 小时，需全局缓存（Redis），和小程序用户完全无关。而用户登录态校验依赖的是 jscode2session 返回的 openid，两者生命周期、作用域、存储方式全都不一样。
实操建议：
- 用独立命令或定时任务刷新
access_token并写入 Redis，key 命名为wechat:access_token，设置过期时间 7000 秒（预留缓冲） - 任何需要调用微信消息推送、模板消息的业务代码，直接从 Redis 读
access_token，失败才触发刷新 - 鉴权中间件里只处理用户凭证，绝不出现
curl_setopt($ch, CURLOPT_URL, 'https://api.weixin.qq.com/cgi-bin/token')这类调用
敏感操作必须二次校验，比如删除订单前再查一遍 openid === order.user_id
前端传来的 order_id 是不可信的。即使你已在路由层做了角色判断（比如“编辑”角色允许访问 /api/order/delete），也不能跳过数据归属校验。攻击者可手动构造请求，把别人订单的 ID 发过来。
这一步不是“多此一举”，而是最后一道防线。尤其当你的系统存在多角色共存、数据软删除、状态流转等复杂逻辑时，仅靠角色无法覆盖所有边界情况。
示例场景：
- 用户 A 提交了订单 #1001，用户 B 是同部门编辑，有编辑权限
- 若只校验“B 属于该部门”，B 就能删掉 #1001 —— 但业务要求只能删自己提交的
- 必须在删除逻辑内显式查库：
Order::where('id', $id)->where('user_id', $request->user->openid)->delete() - 如果用 Laravel，推荐在 Model 的
deleting事件里加钩子，统一拦截非本人操作
容易被忽略的是：这种校验必须发生在事务内，且不能被缓存绕过。一旦用了 Eloquent 的 find() 再判断，就可能因并发导致条件竞争 —— 直接用带条件的 delete() 或 update() 更安全。
