uni-app中不存在真正的“长效授权”，所谓长效实为前端缓存+后端反复调用+用户多次点击的组合策略；微信强制要求uni.requestsubscribemessage必须由用户主动点击触发，禁止在onload、onshow等生命周期中预加载，且每次授权仅对应单条消息发送。
uni-app里“长效授权”根本不存在，别被这个词带偏
微信小程序没有真正意义上的“长效授权”，所谓长效，只是前端缓存状态 + 后端反复调用 + 用户多次点击的组合策略。一次性模板发完即失效，每次推送都得重新走授权链路。你看到的“长期可用”，全是靠业务节奏兜住的——不是技术上支持，是设计上绕开限制。
为什么uni.requestSubscribeMessage不能自动重试
微信强制拦截所有非用户主动点击（@click）触发的调用，哪怕只加一个await或setTimeout(0)都会报错fail can only be invoked by user TAP gesture。这意味着：
- 不能在
onLoad、onShow里预加载授权 - 不能在登录成功回调里顺手调一次
- 不能用
uni.showToast提示后自动弹窗 - 按钮必须带
open-type="subscribeMessage"（uni-app 3.0+），否则部分机型静默失败
怎么让“每次都要点”不显得烦人
核心思路是把授权动作嵌入高频、合理、不可跳过的业务节点，而不是单独弹个“请开启通知”框：
- 下单成功页的“查看物流”按钮，绑定
uni.requestSubscribeMessage，模板ID传ORDER_UPDATE - 支付完成页的“返回首页”按钮，同时请求
PAYMENT_NOTICE模板 - 用户点击“预约成功”后，立刻触发对应服务类模板，而非等第二天再推
- 避免一次传多个
tmplIds——用户点一个“拒绝”，整组全废；单次只传1个最相关的
前端可缓存itemSettings[templateId]状态（比如用uni.setStorageSync存7天），但仅用于UI判断是否显示引导文案，**不能跳过实际调用**。
后端怎么配合才能“看起来像长效”
关键不是存授权结果，而是把每次accept当作一次独立许可去用：
- 前端拿到
res[templateId] === 'accept'，立刻把openid和该模板ID发给后端，记作“本次可用” - 后端收到后立即调用
https://api.weixin.qq.com/cgi-bin/message/subscribe/send，data字段严格按模板定义填，比如thing1不能写成keyword1 - 不要攒着“等三次一起发”——每条授权只换一条消息，超时未发自动作废
- 如果返回
{"errcode":43101,"errmsg":"user refuse to accept the msg"}，说明用户点了拒绝，此时前端应调uni.openSetting({ withSubscriptions: true })引导手动开启
真正容易被忽略的是：模板字段名大小写敏感、value必须是对象、touser必须是openid而非unionid——这些细节错一点，invalid template_id报错就来了，但其实根本不是ID问题。
