模板ID需要先在微信公众平台手动申请，再复制粘贴到 uni-app 代码里，系统不会自动生成，也不会帮你同步。这里有几个前提一定要满足：这个 ID 必须真实存在、已经审核通过，而且归属于当前小程序；只要其中任何一项不成立，调用 uni.requestSubscribeMessage 时，要么直接报 invalid template_id，要么更麻烦，表面上看没报错，实际上静默失败。
模板ID必须在微信公众平台申请后手动填入代码
uni-app 本身不生成也不管理模板 ID，它只是调用微信原生能力。所有模板 ID 都来自微信公众平台后台的「订阅消息」模块，且必须人工复制粘贴到 uni-app 项目里——不存在自动生成、自动同步或配置文件自动拉取这回事。
一个很常见的误区是：不少开发者觉得在 uni-app 里改一下 config 就该立刻生效，可真到调用 uni.requestSubscribeMessage 时，却要么直接报 invalid template_id，要么干脆没有任何反应、静默失败。问题其实不在 config，本质上还是传入的 tmplIds 数组有问题——里面写入了不存在的模板 ID、尚未审核通过的 ID，或者压根就不属于当前小程序的 ID。
- 登录微信公众平台 → 左侧菜单「功能」→「订阅消息」→ 进入「公共模板库」搜索关键词（如“订单状态”）
- 点开匹配模板 → 确认字段是否满足业务需求（比如是否含
thing1、time2等实际要用的 key）→ 点「选用」 - 跳转到「我的模板」列表 → 找到刚选用的条目 → 点「详情」→ 复制顶部显示的
templateId（一串含字母数字的长字符串） - 把这个 ID 直接写进代码，例如：
tmplIds: ['GAcYabm1vG_YJwl75R_vXntgqe5q2Li3N-0XTCOEehE']
一个页面只传一个模板 ID 最稳妥
虽然微信允许 tmplIds 传最多 10 个 ID，但 uni-app 实际调用时，用户面对多个模板授权弹窗极易疲劳，点「拒绝」概率陡增；而且只要有一个 ID 被拒，整个回调里的 res 对象就可能缺失该字段，逻辑判断反而更复杂。
使用场景很明确：下单页只推「订单支付成功」，预约页只推「服务开始提醒」，没必要一次拉多个授权。后端发消息也只用一个 ID，多传纯属增加出错面。
- 前端调用时固定只传 1 个 ID：
tmplIds: [config.orderSuccessTmplId] - 不同业务场景用不同模板 ID，各自独立申请、独立判断授权状态
- 避免把多个 ID 塞进同一个
uni.requestSubscribeMessage调用里
模板 ID 写错或未审核通过的典型报错
微信对模板 ID 的校验非常严格，哪怕多一个空格、少一位字符、或用了其他小程序的 ID，都会直接失败，且错误信息极其简陋——常表现为 fail: {} 或控制台无任何输出，让人误以为是 JS 逻辑问题。
性能与兼容性影响不大，但调试成本极高。很多开发者花半天查 uni.getSetting 返回值，其实根本没走到那一步：请求压根没发出去。
- 错误信息可能是：
err: {errMsg: "requestSubscribeMessage:fail invalid template_id"} - 也可能完全不触发 success/fail 回调（尤其在真机上，模拟器有时表现异常）
- 检查项：确认该
templateId确实出现在你当前小程序的「我的模板」列表中，且状态为「审核通过」 - 注意：刚选用的模板要等微信审核（通常几分钟到几小时），未过审时调用必失败
别把模板 ID 和 access_token 混在一起配置
模板 ID 是静态字符串，access_token 是动态令牌，两者生命周期、获取方式、存储位置完全不同。但新手常把它们都塞进同一个 config 对象，甚至试图用同一套缓存逻辑管理，导致后续发消息时传错参数。
容易踩的坑在于：后端发消息需要 template_id + access_token + touser + data，而前端只负责提供 template_id 和用户是否授权的结果。如果前端 config 里混了 token 字段，很容易误导自己以为“配置全了”，其实后端根本没拿到有效 token。
- 前端只管存和传
templateId，例如：const ORDER_TPL_ID = 'xxx...' - access_token 必须由后端单独请求微信接口获取，并缓存（有效期 2 小时），前端不参与
- 不要在
uni.requestSubscribeMessage的参数里塞access_token—— 它根本不认这个字段
