小程序里点扫码，屏幕一闪就没动静，连点几次还是一样——不少用户都遇到过这种情况。客服通常先怀疑功能出问题了，可查来查去，往往发现是用户之前把相机权限给拒了。这不算故障，而是一个需要提前设计好的正常分支。用户拒绝授权的原因五花八门：有人是不想被频繁打扰，有人是当时手滑点了拒绝，也有人纯粹出于隐私谨慎。不管哪一种，产品都得给出一个体面的下一步，而不是让用户干瞪眼。
三种扫码路径，受权限影响差别很大
在小程序里做扫码，常见有三条路子。第一条是直接调用原生扫码能力，由系统拉起相机界面，这条路径对相机权限的依赖最直接，权限一旦被拒基本就走不通。第二条是内嵌扫码组件，画面在页面内渲染，同样需要相机权限，但开发者可以在组件外层叠加自定义提示和替代入口。第三条是跳转到外部应用完成扫码，再回到小程序接收结果，这条路径受小程序自身权限状态影响较小，但会打断用户操作，体验的连贯性会打折扣。先搞清楚自己用的是哪条路径，才能判断降级空间有多大。
权限被拒后，按四层顺序往下退
第一层是提示引导。用户点扫码时，如果检测到权限没给，别急着弹系统弹窗，先用页面内的说明告诉用户为什么需要相机，以及拒绝之后还能怎么用。第二层是手动输入。很多扫码场景本质就是获取一串编码，比如订单号、设备编号、活动码，给个输入框让用户手动填，功能照样能跑通。第三层是相册选图识别。用户可能早就截图存了二维码，允许从相册选图片来识别，能覆盖相当一部分场景。第四层是联系客服人工处理。当前三层都走不通时，给出明确的人工入口，并附上需要提供的信息，免得用户反复描述。
分清三种权限状态，提示才不会说错话
相机权限被拒，至少分三种情况。首次拒绝，系统通常还允许再次弹窗询问，这时候可以引导用户重新授权。永久拒绝，系统不再弹窗，必须引导用户去设置页手动开启，文案里要把路径写清楚。系统级关闭，比如设备管理策略或隐私设置限制了相机，小程序内怎么引导都没用，这时应该直接转向手动输入或人工处理，别再反复提示授权。把三种状态混为一谈，是很多提示文案让人看得一头雾水的根源。
降级路上容易忽略的体验细节
按钮文案要跟着状态变。权限正常时写“扫码”，权限被拒后可以写“手动输入编号”或“从相册选择”，让用户一眼就知道点下去会发生什么。错误提示别只写“权限不足”，要写清楚下一步该做什么。返回路径要保留，用户从扫码页退出来后，应该回到原来的业务位置，而不是被丢回首页。重试入口要显眼，用户去设置里开了权限再回来，页面应该能自动检测到状态变化，或者至少给个刷新按钮。这些细节不复杂，但缺一个，用户就会觉得这功能“半残”。
功能可用，比功能完整更重要
扫码降级设计的核心原则只有一条：功能可用性优先于功能完整性。能扫码当然最好，扫不了码时，手动输入、相册识别、人工处理都是合法路径。it数运在小程序开发实践中通常会把权限分支当作主流程的一部分来规划，而不是等上线后打补丁。具体权限策略和系统行为可能随版本变化，实际开发时建议以官方文档和真机测试结果为准。把拒绝当成一种正常输入，产品才不会在用户说“不”的时候束手无策。
