用户首次进入小程序时，系统弹窗请求获取位置权限，用户随手一划便点了拒绝。接下来的处理方式，往往直接影响他是否愿意继续使用这个小程序。不少附近门店功能在这一环节直接卡住，页面一片空白，或者反复弹出授权请求，用户只能选择退出。权限被拒绝并不意味着功能必须终止，关键在于开发阶段有没有为这种情形预留退路。
先厘清功能究竟依赖什么
着手设计降级方案之前，需要把依赖关系梳理清楚。附近门店功能对位置的需求并非同一等级。有些场景需要精确到几百米，比如导航到最近一家门店；有些只需要知道用户所在城市，用来筛选该城市的门店列表；还有一些连城市都不需要，用户自行输入关键词就能找到目标门店。把这三层需求拆开来看，降级方案才有依据。如果所有逻辑都写死在“必须拿到经纬度”这一个前提上，后续就没有腾挪余地。
三级降级方案可以这样设计
第一级是手动选择城市与商圈。用户拒绝定位后，页面不应空白，而是展示一个城市列表，默认按拼音或热门城市排序，选完城市再选商圈或区域，系统据此筛出门店。这一级覆盖大多数“找附近店”的真实需求，因为用户心里通常清楚自己要去哪个区。
第二级是保留上次使用位置。如果用户之前授权过定位，本地缓存过城市或坐标，这次拒绝授权时可以继续使用缓存数据，但要在界面上标明“基于上次位置”，并提供手动修改入口。缓存要有有效期，超过一定时间就退回第一级，避免位置信息过期造成误导。
第三级是门店搜索与列表浏览。用户既不给定位也不选城市时，至少让他能搜索门店名称、街道或编号，或者直接浏览全部门店列表，按名称排序。这一级不追求精准，但保证功能可用，用户不会因为一个权限问题被彻底挡在门外。
界面解释要跟上，别让用户以为坏了
降级最容易出的问题不是技术，而是沟通。用户点了拒绝，页面突然变成另一个样子，他会以为是加载失败。所以降级触发时，界面上要有一句清楚的说明，比如“未获取位置权限，已为你切换为手动选择城市”，同时保留一个不打扰的入口，让用户想开权限时可以再开。不要用红色警告，也不要用“功能受限”这类让人紧张的词，平静地说明现状和可选操作就够了。
开发时要盯住的几个检查点
权限状态监听要覆盖首次询问、拒绝、拒绝后再次进入、系统设置里重新开启这几种情况，不能只判断一次。降级触发条件要写明确，是拒绝即降级，还是拒绝两次后降级，规则统一。缓存位置要设有效期，并记录来源，区分精确定位和手动选择。隐私说明文案要如实写清楚收集位置的目的、使用范围和用户可以选择不授权，不能含糊带过。这几项在测试阶段就要专门走一遍拒绝路径，而不是只测授权成功的情况。
权限被拒，本质上是用户在做选择。开发者的任务不是想办法逼他改主意，而是把选择权交还给他，同时让功能在可控范围内继续可用。it数运在小程序开发中处理这类权限降级时，通常会把判断逻辑和界面提示一起设计，避免功能因为一个弹窗就整体失效。把退路留好，用户才有机会留下来。
