定位功能在微信小程序里的接入成本不高，但隐私合规检查往往比功能实现更容易出错。常见的尴尬是：功能已经在开发版跑通，提交审核却因未配置地理位置隐私说明被退回，或者线上版本被用户投诉后触发平台警告。要做的不是简单加一句弹窗文案，而是把接口权限声明、隐私保护指引、用户授权时机和拒绝后的降级逻辑串成一条完整链路来核对。
先核对基础配置：app.json 与隐私保护指引
微信小程序里凡是调用 wx.getLocation、wx.chooseLocation 等地理位置相关接口，都必须在 app.json 中完成两层声明。第一层是 permission 字段下 scope.userLocation 的用途说明，第二层是 requiredPrivateInfos 数组。很多审核驳回问题就出在只写了其中一层，或者字段拼写不完整。
下面是一个基础配置示例，核心不是照抄，而是确认每个实际用到的接口都出现在 requiredPrivateInfos 中。比如只写 chooseLocation 却遗漏 getLocation，真机上会直接返回接口不可用错误。
{
"permission": {
"scope.userLocation": {
"desc": "你的位置信息将用于查找附近门店和计算配送距离"
}
},
"requiredPrivateInfos": [
"getLocation",
"chooseLocation"
]
}
另一处必须同步检查的是小程序管理后台的用户隐私保护指引。后台需要勾选收集位置信息的选项，并补充具体场景说明。若隐私保护指引中没有位置信息，但 app.json 里声明了定位接口，审核时会被判定为声明不一致；反过来，后台写了收集位置信息，前端却没有走任何定位逻辑，也可能被要求说明用途。因此每次改动定位能力后，建议重新核对后台配置和前端声明是否保持同步。
处理隐私弹窗与位置授权的先后顺序
微信隐私弹窗和 scope.userLocation 授权是两个不同机制，不能混为一谈。隐私弹窗解决的是平台对隐私保护指引的确认，位置授权才是用户对系统定位权限的授权。实际开发中会出现这样的现象：用户已经点了同意隐私政策，但调用 wx.getLocation 仍然失败，原因是用户还没有在微信客户端中授予位置权限。反过来，如果隐私政策未确认就直接调用定位接口，也可能会触发 errno 相关错误。
正确做法是先通过 wx.requirePrivacyAuthorize 处理隐私政策确认，再在成功回调中发起定位请求。这样能避免在隐私政策未同意时过早调用地理接口，也能让拒绝路径更加清晰。下面是一个可以直接放进工具函数里的示例。
function getLocationWithPrivacy() {
wx.requirePrivacyAuthorize({
success: function () {
wx.getLocation({
type: 'wgs84',
success: function (res) {
console.log('经度:', res.longitude, '纬度:', res.latitude);
},
fail: function () {
wx.showToast({
title: '未获得位置权限',
icon: 'none'
});
}
});
},
fail: function () {
wx.showModal({
title: '提示',
content: '需要同意隐私政策后才能使用定位功能',
showCancel: false
});
}
});
}
如果使用自定义隐私弹窗，还需要监听 wx.onNeedPrivacyAuthorization，当用户触发隐私接口时挂起请求，等用户同意后再执行原逻辑。这个监听器在每次涉及隐私接口调用前都会触发，需要在页面加载时就注册好，避免出现弹窗不展示或接口被静默拦截的情况。
Page({
onLoad: function () {
var that = this;
if (wx.onNeedPrivacyAuthorization) {
wx.onNeedPrivacyAuthorization(function (resolve) {
that.resolvePrivacyAuthorization = resolve;
that.setData({ showPrivacyPopup: true });
});
}
},
agreePrivacy: function () {
if (this.resolvePrivacyAuthorization) {
this.resolvePrivacyAuthorization({ event: 'agree' });
this.setData({ showPrivacyPopup: false });
}
}
});
拒绝授权后的降级处理同样重要。用户拒绝位置权限后，不能再次强制弹窗，更不能在用户不知情的情况下通过其他方式继续获取位置。比较稳妥的方案是检测到 scope.userLocation 为 false 时，提示用户前往设置页手动开启，同时保留继续浏览其他内容的能力。
检查隐私政策文本与第三方数据流向
隐私政策文本不能只写一句“收集您的位置信息”，需要把收集类型、使用场景、保存期限、是否共享等关键信息写清楚。对于小程序定位场景，至少应区分是精确位置还是模糊位置，是当前所处位置还是历史轨迹。如果位置信息只在前端用于计算附近门店，不上传到服务器，也应当明确说明，避免用户误以为数据被长期存储。
如果项目里接入了地图相关的第三方 SDK 或插件，还要检查这些组件是否会自行调用定位能力。有些插件会在自身逻辑中请求 wx.getLocation，即便主包未直接声明，也会因为插件内部的接口调用而要求补齐隐私配置。此时除了增加隐私保护指引说明，还要确认插件提供方是否具备独立的隐私政策，并在小程序的隐私政策中予以披露。
数据回传环节同样需要检查。可以全局搜索项目中是否把 latitude、longitude 等字段通过 wx.request 或 wx.uploadFile 发送到服务端。如果存在回传，就要在隐私政策中明确数据接收方、用途和存储策略。若回传域名还涉及第三方数据分析服务，更要注意不能只写“用于改善服务”这类模糊表述。
真机验证与常见驳回原因排查
开发者工具里的模拟环境不一定能完全还原隐私拦截和系统授权弹窗，因此涉及地理位置的合规验证要在真机上进行。清缓存后重新进入小程序，重点观察首次隐私弹窗是否正常出现、位置授权弹窗是否紧随其后、拒绝授权后再次触发定位是否被合理拦截。如果这三步有一条不符合预期，上线后的投诉和审核风险都会明显上升。
常见驳回原因可以归为几类：requiredPrivateInfos 未声明或声明不全；后台隐私保护指引未勾选位置信息；隐私政策中未说明位置信息的具体使用目的；调用 wx.getLocation 前未处理隐私授权；用户拒绝位置权限后仍然强制获取位置。逐项对照自己项目，基本能覆盖大多数因地理位置引起的隐私合规问题。
下面这段代码可以用来检查当前用户的位置授权状态，并在已经拒绝时引导用户去设置页开启。建议放在需要定位功能的页面初始化阶段，而不是每次点击定位按钮时都重复询问。
function checkLocationAuth(callback) {
wx.getSetting({
success: function (res) {
var auth = res.authSetting['scope.userLocation'];
if (auth === true) {
callback(true);
} else if (auth === false) {
wx.showModal({
title: '位置权限已关闭',
content: '请在设置中开启位置权限后再使用附近门店功能',
confirmText: '去设置',
success: function (modalRes) {
if (modalRes.confirm) {
wx.openSetting({
success: function (settingRes) {
callback(!!settingRes.authSetting['scope.userLocation']);
}
});
}
}
});
} else {
callback(false);
}
}
});
}
地理位置隐私合规不是一次配置就能永久解决的问题，每次新增定位入口、替换地图服务或调整数据回传逻辑后，都需要重新走一遍检查清单。把前端权限声明、后台隐私保护指引、用户授权交互和隐私政策文本四项对齐，才能既保证功能可用，也避免被驳回或触发平台处置。