应采用最小权限原则，按需申请明确scope，分场景动态授权，后端严格校验，弹窗提示需直白说明用途。
接口权限过宽，本质是授权粒度太粗，容易引发越权访问或隐私泄露。用 Scope 限制法，就是把“全给”变成“按需给”，只开放当前功能真正需要的最小权限。
明确每个接口对应的最小 Scope
不要笼统申请 scope.userInfo 就去读头像+昵称+手机号+地址。微信生态中，scope.userInfo 只返回脱敏后的公开信息（如昵称、头像），真实手机号、地址等需单独申请更高权限（如通过用户主动填写或企业认证后调用开放平台接口）。实际开发中应：
- 读取模糊位置 → 用 scope.userFuzzyLocation，而非已废弃的 scope.userLocation
- 仅保存图片 → 申请 scope.writePhotosAlbum，不连带请求录音或定位
- 需要步数数据 → 单独申请 scope.werun，不和相册、麦克风混在一次授权里
分场景动态申请，避免一次性弹多权限
用户看到一堆授权请求容易反感甚至直接拒绝。应在具体操作触发时再申请对应 Scope：
- 用户点击「分享到相册」按钮，才调用 wx.authorize({scope: 'scope.writePhotosAlbum'})
- 进入运动打卡页，再请求 scope.werun，而不是冷启动就弹窗
- 调用前先用 wx.getSetting 检查状态，已拒绝的跳过申请，改用引导文案说明用途
后端也要校验 Scope，不能只信前端传来的 token
即使前端拿到了带 SCOPE_read:profile 的 JWT，后端资源服务器仍需验证该 token 是否真含此 Scope，且与当前请求路径匹配：
- /api/user/basic 接口要求 SCOPE_read:profile
- /api/user/phone 接口必须校验更严格的 SCOPE_phone:read（需额外白名单或企业资质）
- Spring Security 中用 .hasAuthority("SCOPE_read:profile") 显式约束，不依赖角色名或硬编码判断
命名清晰，让用户看得懂为什么需要这个权限
Scope 值本身是技术标识，但授权弹窗里展示的描述必须直白。比如：
- 不要只写 scope.record，而要说明“开启麦克风，用于语音输入和实时通话”
- scope.userFuzzyLocation 对应提示：“获取大致位置，用于推荐附近活动（不记录精确坐标）”
- 避免使用 all、full、admin 等模糊词，它们既违反最小权限原则，也违反工信部关于权限用途明示的要求
