用户第一次进入扫码页面，屏幕弹出相机授权提示，手指一点“拒绝”，页面立刻变成一片空白。很多人会把这种情况当成程序出错，其实它更像权限设计上的一个缺口：开发者只考虑了“用户同意”这一条路，没有为“用户不同意”准备第二条路。扫码功能依赖相机，但扫码任务并不只依赖相机。把这两件事分开看，降级方案就有了落脚点。
先要分清两种拒绝状态。用户点“拒绝一次”时，系统通常仍允许应用在下次调用时再次发起授权询问，页面可以保留重新唤起的入口；而用户选择“永久拒绝”或在系统设置中关闭权限后，应用往往无法再主动弹出授权框，只能引导用户去设置页手动开启。开发者能拿到的是当前授权状态和是否可再次询问，拿不到的是用户拒绝的真实原因，也不应反复弹窗骚扰。把两种情况混为一谈，就会出现“点了没反应”或“反复弹窗”两种极端。
第一条降级路径是手动输入。扫码的本质是把一串编码转换成业务数据，那么编号、订单号、设备码、邀请口令都可以作为等价入口。设计时要写清输入格式，比如长度范围、允许的字符类型、是否区分大小写；校验规则要前置，能在本地判断的先判断，减少无效请求；错误提示要具体，告诉用户是格式不对、编号不存在还是已被使用，而不是笼统地显示“输入有误”。
第二条路径是从相册选择图片识别。用户可能早已拍下二维码或截图保存，允许上传图片进行识别，可以覆盖相当一部分场景。这条路径的边界要说明白：图片模糊、反光、裁切过度都可能导致识别失败，失败后不能只弹一句“识别失败”，而应给出重试建议，比如换一张更清晰的图片，或直接转入手动输入。
第三条路径是引导前往系统设置。提示文案要说明用途，例如“扫码需要使用相机，用于读取二维码信息”，避免用户误以为应用在索取无关权限。按钮点击后尝试跳转系统设置页，用户返回小程序时，页面应主动刷新授权状态，而不是停留在旧提示上。若用户仍未开启，保留手动输入入口作为兜底。
可以按一张清单自查：扫码入口是否在无权限时仍然可见；授权提示是否说清了用途；拒绝之后是否有明确的下一步；识别失败是否有替代方案；关键节点是否留下可追溯的日志，便于后续排查。权限分支不是边角料，它和正常流程一样需要被规划。it数运在小程序规划阶段通常会把权限分支一并纳入需求梳理，让用户在拒绝之后仍然能把任务完成。降级不是功能缩水，而是把选择权交还给用户，同时把任务闭环守住。
