uni.requestSubscribeMessage 必须在带open-type="subscribeMessage"的button点击事件中同步调用，超时5秒或非真实点击均静默失败；授权状态需通过uni.getSetting({withSubscriptions:true})检查itemSettings下各模板ID的accept/reject/ban值，不可依赖mainSwitch或==比较。
uni.requestSubscribeMessage 必须在 button 点击里调用
微信底层强制限制：这个 API 只能在用户真实点击（tap）触发的同步上下文中执行，且必须在点击后 5 秒内发起。超时就静默失败——控制台不报错，fail 回调可能返回 errCode: 20004，也可能根本不触发。
常见错误包括：
- 放在
onLoad、onShow或setTimeout里直接调 → 被拦截，弹窗根本不出 - 用
view或text绑定@click→ 微信不认，必须是原生button - 没加
open-type="subscribeMessage"属性 → 即使是button也无效（uni-app 3.0+ 才支持该属性）
正确写法示例：
<button open-type="subscribeMessage" @click="handleSubscribe">开启物流实时更新</button>
handleSubscribe 函数体要尽量直白，不要嵌套异步等待。如果中间需要查登录态或获取 code，建议提前做，点击时只负责调 uni.requestSubscribeMessage。
怎么判断用户是否已授权，避免重复弹窗
靠 uni.getSetting({ withSubscriptions: true }) 拿 subscriptionsSetting，但字段结构容易踩坑：
- 它不是扁平对象，状态藏在
res.subscriptionsSetting.itemSettings下，每个模板 ID 对应一个键值，值是"accept"/"reject"/"ban"字符串，不是布尔值 - iOS 系统没有“订阅消息”独立开关入口，
mainSwitch始终为true，不能当作授权依据；必须逐个查itemSettings[tmplId] - 不传
withSubscriptions: true，subscriptionsSetting字段为空
建议封装一个工具函数，输入 tmplIds 数组，返回每个模板当前状态，再按需决定是否调用授权。别用 == 判定字符串，统一用 ===，'accept '（带空格）这种脏数据真会出现。
按钮文案和诱导设计直接影响授权率
“授权通知”“同意推送”这类抽象表述点击率极低；微信明确建议用具体业务动因引导，比如“开启发货提醒”比“订阅消息”高 3 倍以上转化。
用户第一次拒绝后，再次调用仍会拉起弹窗（只要没点“不再提示”），但若你没做状态检查，就会让用户反复面对同一弹窗，体验崩坏。
- 按钮文案必须带业务价值，例如：
"开启物流实时更新"、"接收预约成功通知" - 首次拒绝后，下次点击应先展示轻量引导页（如图标+一句话说明用途），再触发授权
- iOS 用户无法从系统设置里单独打开订阅开关，引导时需说明“请返回小程序首页，点击右上角「…」→「设置」→「消息订阅」手动开启”
uni.openSetting 不能精准跳转到订阅页
微信不允许 JS 主动跳转到“订阅消息”子页面。uni.openSetting 只能打开权限总览页，且 iOS 和 Android 展示逻辑不同：
- iOS 不显示订阅消息入口，点了也没用
- Android 才有，但入口位置不固定，有时藏在二级菜单
- 调用时必须传
{ withSubscriptions: true }，否则默认不展示相关项
所以当检测到 itemSettings[tmplId] === 'reject' 时，不要直接跳设置页，先展示解释性引导（比如“您之前关闭了订单提醒，现在可重新开启”），再给按钮，点完再调 uni.openSetting —— 否则用户点进去一脸懵，反而加深反感。
真正难的不是调 API，而是把“用户为什么需要这条通知”说清楚，并在对的状态、对的时机、用对的话术推出来。状态判断漏一层，诱导文案差一点，整个链路就断在第一步。
