AccessToken获取失败主因是appid/secret未URL编码，需分别调用Uri.EscapeDataString()；缓存应预留60秒缓冲并用分布式缓存避免多实例冲突。
AccessToken 获取失败：HttpClient 调用微信接口返回 {"errcode":40013,"errmsg":"invalid appid"}
不是 appid 写错了，而是微信要求 appid 和 secret 必须 url 编码后拼在请求地址里——但很多人直接拼接字符串，没做 uri.escapedatastring()。微信校验时把含下划线、大小写混用的原始 appid 当成非法值。
实操建议：
- 构造请求 URL 时，对
appid和secret分别调用Uri.EscapeDataString()，不要只对整个 URL 做一次编码 - 微信文档里给的示例 URL 是解码后的可读形式，实际发请求必须是编码后的
- 用
HttpClient时，推荐用FormUrlEncodedContent发 POST（获取 token 接口支持 GET 和 POST，但 POST 更可控） - 检查 AppID 是否来自「公众号后台 → 开发 → 基本配置」，不是小程序或开放平台的 AppID
缓存失效时间不准：expires_in 返回 7200，但缓存 2 小时后仍报 invalid credential
微信返回的 expires_in 是秒数，但它从「微信服务器发出响应那一刻」开始倒计时；而你本地解析 JSON、反序列化、写入内存缓存，可能已过去几十毫秒。更关键的是：多个服务实例或 IIS 应用池回收后，各自缓存独立，没有统一过期协调。
实操建议：
- 拿到
expires_in后，立刻用DateTimeOffset.UtcNow.AddSeconds(expires_in - 60)作为过期时间，预留 60 秒缓冲 - 别用
MemoryCache的绝对过期策略直接设 2 小时，改用滑动过期 + 主动刷新逻辑 - 如果部署多实例，必须用分布式缓存（如 Redis），且 key 设为
wechat:access_token:{appid}，避免不同实例反复刷 token - 每次取 token 前先检查是否剩余
并发刷新导致重复请求：高并发下多个线程同时发现 token 过期，都去调微信接口
微信对 /cgi-bin/token 接口有频率限制（虽然不严），更严重的是多个线程拿到不同 token，互相覆盖缓存，造成后续请求一半成功一半失败。
实操建议：
- 用
AsyncLazy或Task+LazyThreadSafetyMode.ExecutionAndPublication包裹 token 获取逻辑，确保同一时刻只有一个线程真正发起 HTTP 请求 - Redis 场景下，用
SET key value EX 7200 NX命令争抢刷新权，抢到的才调微信，其余等待 100ms 后重查缓存 - 不要在
get属性里写刷新逻辑，C# 属性访问无锁保障，极易触发竞态 - 记录日志时带上
threadId和isRefreshTriggered标志，方便排查是否真有并发刷新
本地调试时 token 总是过期：System.Net.Http.HttpRequestException 或证书错误
开发机没装根证书、或用了 Fiddler/Charles 抓包导致 HTTPS 证书链异常，HttpClient 直接拒绝连接微信域名；还有一种情况是开发者误把测试号的 appid/secret 配到正式环境配置节，本地读取错配置。
实操建议：
- 运行前加一句
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;，.NET Framework 4.5 默认不启用 TLS 1.2 - 禁用 Fiddler 代理，或在代码中显式设置
HttpClientHandler.UseProxy = false - 用
dotnet user-secrets管理本地密钥，避免appsettings.json里硬编码，防止提交到 Git - 在 token 获取方法开头加断点，检查
Configuration["WeChat:AppId"]的值是否为空或含空格
微信 AccessToken 的有效期边界很脆，不是“能用两小时”，而是“从它出生起严格倒数 7200 秒”；缓存层一旦漏掉时间偏移、并发控制或环境差异，问题就会在凌晨三点突然爆发，而且只影响部分请求。
