模板消息发送失败需同时满足三条件：服务号已认证、用户已关注、模板id后台审核启用；silenceper/wechat/v2初始化时cache不可为nil，须传memory或redis实例；字段key须严格匹配后台定义。
微信服务号每月仅限群发 4 次，想高频触达用户，必须走模板消息（或订阅通知）通道；但直接调用官方 API 成本高、易出错，silenceper/wechat/v2 是目前 Go 生态中最稳定、维护活跃的封装库，能省掉 token 自动刷新、签名拼接、重试逻辑等重复劳动。
为什么模板消息总发不出去？先查这三处硬性条件
模板消息不是“调了就发”，必须同时满足：公众号为服务号且已认证、用户已关注且未取关、模板 ID 已在后台通过审核并启用。测试阶段最容易栽在第三点——测试号里的 template_id 和正式号不通用，且正式号模板必须先在「模板库」中选用再手动提交审核，不能直接在测试号里“新增测试模板”后上线使用。
- 正式环境务必用正式公众号后台申请的模板 ID，测试号模板仅限调试
- 用户
openid必须是该公众号下的真实关注者，网页授权获取的unionid不能直接用于模板消息 - 发送时若返回
invalid openid或template_id not exist，优先检查上述两点，而非代码逻辑
silenceper/wechat/v2 初始化时 cache 参数不能传 nil
该库在初始化 OfficialAccount 时，若 Config.Cache 为 nil，会导致后续 access_token 无法缓存，每次发送都重新请求，极大概率触发微信频控（错误码 45009）。必须显式传入一个缓存实例，哪怕只是本地内存：
memory := cache.NewMemory()
cfg := &offConfig.Config{
AppID: "your-appid",
AppSecret: "your-appsecret",
Token: "your-token",
Cache: memory, // ← 这行不能少，也不能为 nil
}
生产环境建议换 redis 实例，避免多进程部署时 token 不一致；但开发阶段用 cache.NewMemory() 完全够用。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
模板字段 key 名必须和后台定义完全一致
微信模板消息的 Data 是 map 结构，key 必须严格匹配你在公众号后台配置模板时定义的“关键词编号”，比如后台设的是 thing1、time2、phrase3，代码里就必须写成：
msgData["thing1"] = &message.TemplateDataItem{Value: "订单已创建"}
msgData["time2"] = &message.TemplateDataItem{Value: "2026-04-07 15:30:00"}
msgData["phrase3"] = &message.TemplateDataItem{Value: "请尽快处理"}
常见错误是把 keyword1 当通用名硬编码进去，或者大小写/下划线写错（如 Thing1 或 thing_1），结果消息能发出去但字段为空。后台模板详情页会明确列出每个字段的 key，复制粘贴最安全。
URL 和 color 字段不是必填，但漏掉 color 会影响渲染一致性
TemplateMessage.URL 是点击跳转地址，可为空字符串（""），但留空时微信客户端可能默认跳转公众号主页；TemplateDataItem.Color 同样可空，但若部分字段设了颜色（如红色）、部分没设，iOS 和 Android 渲染效果会不一致——Android 默认黑色，iOS 可能继承上一字段颜色。统一设为空或统一指定（如 "#173177"）更可控。
真正容易被忽略的是并发场景：同一个 OfficialAccount 实例可复用，但不要在 goroutine 里反复 new 它；token 刷新是全局共享的，高频发送时若每个请求都 new 一个 client，反而会因 cache 隔离导致 token 请求爆炸。复用单例 + 正确传参才是稳定关键。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
