uni.requestSubscribeMessage必须在用户点击后5秒内调用，且仅限tap事件同步执行；需通过uni.getSetting(withSubscriptions:true)检查itemSettings中各模板ID状态（accept/reject/ban），避免依赖mainSwitch；按钮文案须具业务价值，如“开启物流实时更新”，并做好iOS无系统开关的引导；tmplIds须为合法数组，仅微信小程序支持，需平台判断兜底。
uni.requestSubscribeMessage 必须在用户点击后 5 秒内调用
微信底层强制限制：这个 API 只能在用户真实点击（tap）触发的同步上下文中执行，且必须在点击后 5 秒内发起调用，超时就静默失败——控制台不报错，fail 回调可能返回 errCode: 20004，也可能根本不触发。
常见错误现象包括：放在 onLoad、onShow、setTimeout、异步请求（如 uni.login 成功回调）里直接调，结果用户完全看不到弹窗。
- 必须绑定到按钮的
@click或bindtap事件处理器中，且函数体要尽量直白，不要嵌套异步等待 - 如果中间需要查登录态或获取 code，建议提前做，点击时只负责调
uni.requestSubscribeMessage - 避免在弹窗前加 loading 或节流逻辑，这些都可能拖过 5 秒窗口
怎么判断用户是否已授权，避免重复弹窗
靠 uni.getSetting({ withSubscriptions: true }) 拿 subscriptionsSetting，但这个字段结构容易踩坑：它不是扁平对象，而是嵌套在 res.subscriptionsSetting.itemSettings 下，且每个模板 ID 对应一个键值，值是 "accept" / "reject" / "ban" 字符串，不是布尔值。
更麻烦的是，iOS 系统没有“订阅消息”独立开关入口，mainSwitch 始终为 true，不能当作授权依据；必须逐个查 itemSettings[tmplId]。
- 检查前先确保传了
withSubscriptions: true，否则subscriptionsSetting字段为空 - 不要只看
mainSwitch，尤其不要在 iOS 上依赖它做判断 - 建议封装一个工具函数，输入
tmplIds数组，返回每个模板当前状态，再按需决定是否调用授权
按钮文案和诱导设计直接影响授权率
“授权通知”“同意推送”这类抽象表述点击率极低；微信也明确建议用具体业务动因引导，比如“开启发货提醒”比“订阅消息”高 3 倍以上转化。
用户第一次拒绝后，再次调用仍会拉起弹窗（只要没点“不再提示”），但若你没做状态检查，就会让用户反复面对同一弹窗，体验崩坏。
- 按钮文案必须带业务价值，例如：“开启物流实时更新”“接收预约成功通知”
- 首次拒绝后，下次点击应先展示轻量引导页（如图标+一句话说明用途），再触发授权
- iOS 用户无法从系统设置里单独打开订阅开关，引导时需明确告知“请返回小程序页面点击按钮重新开启”
tmplIds 传参和跨端兼容必须手动兜底
tmplIds 是必填数组，类型为 Array<string></string>，每个字符串必须是微信公众平台申请通过的合法模板 ID。传错格式（如传成逗号分隔字符串）、少传、多传（超过 3 个）都会导致失败，且错误信息不明确。
该 API 仅在微信小程序有效，H5、App、支付宝等环境调用会直接报错，不能假设 uni-app 自动降级。
- 上线前务必用真机扫码测试，开发者工具模拟有时不准确
- 务必用
uni.getSystemInfoSync().platform === 'mp-weixin'包一层判断再调用 - 模板 ID 不要硬编码在组件里，建议统一收口到配置文件，方便多环境切换
实际中最容易被忽略的一点：**用户点了“拒绝”之后，前端拿不到任何可用于区分“拒绝”和“未操作”的可靠信号——fail 回调在用户点拒绝和调用超时时行为高度相似，只能靠前置的状态检查 + 后续业务逻辑兜底来应对。**
