必须在登录前检查agree变量是否为true，否则流程绕过勾选直接提交；登录按钮需用:disabled="!agree"绑定，多入口均须单独校验；uni.getprivacysetting不能替代显式勾选，因其返回微信授权状态而非业务协议同意；拒绝后须提示明确文案、协议链接可返回且agree状态不重置。
必须在用户点击登录或触发敏感操作前，主动检查 agree 变量是否为 true，否则流程会绕过勾选直接提交——这是审核被拒最常见的逻辑漏洞。
如何绑定勾选框与登录按钮的联动逻辑
uni-app 里不能只靠 UI 层面加个 <checkbox></checkbox> 就完事。关键是要让登录按钮的 disabled 状态严格受控于勾选变量。
- 用
v-model或@change显式绑定 checkbox 的值到 data 中的agree字段，不要依赖 DOM 查询或事件冒泡 - 登录按钮的
disabled属性必须写成:disabled="!agree"，而不是:disabled="agree === false"—— 后者在初始值为undefined时会失效 - 如果页面有多个入口（比如“微信一键登录”和“手机号登录”两个按钮），每个都要单独加
disabled判断，不能只绑一个
为什么 uni.getPrivacySetting 不能替代前端勾选校验
uni.getPrivacySetting 返回的是微信侧的全局授权状态，它和你在页面上做的“同意隐私协议”勾选是两件事：前者是微信系统级授权（如获取手机号），后者是你自己业务流程里的法律确认动作。平台审核只认你页面上的显式勾选行为。
-
uni.getPrivacySetting调用成功只说明用户没拒绝过微信的隐私弹窗，不代表他同意了你的《隐私政策》文本 - 即使
res.needAuthorization为false，你仍需强制用户勾选才能继续登录——这是合规底线，不是技术可绕过项 - 该接口在基础库低于 3.0.0 时会直接报错，但勾选校验不依赖它，所以更稳定、更可控
容易忽略的交互细节：拒绝后的提示与重试路径
用户没勾选就点登录，不能只禁用按钮或静默失败。必须给出明确反馈，并保持操作路径畅通。
- 提示文案不能写“请同意协议”，而要写“请先阅读并勾选《隐私政策》，以继续登录”——强调动作+依据
- 协议链接必须可点击，且跳转后能返回原页（用
uni.navigateBack或保留页面栈） - 如果用户点了协议链接又返回，
agree状态不能被重置为false，否则他会陷入“点链接→回页面→再点登录→又被拦”的死循环
最常被忽略的是：勾选状态必须和页面生命周期对齐。比如用户从协议页返回后，页面 onShow 里没做任何处理，agree 还是旧值，但视觉上 checkbox 已被清空——这种不一致会直接导致体验断裂和审核驳回。
