微信access_token生命周期管理：两级缓存与自动续期实战

你们有没有遇到过这种诡异情况：线上服务白天好好的，一到凌晨跑批或者活动开始前，日志里突然冒出一堆微信接口40001报错，重启以后又能撑一阵，过几小时再次发作？我遇到过，而且不止一次。后来把日志按时间线拉通，才发现问题根本不是微信接口不稳定，而是我们自己没有管理好微信API接口的access_token生命周期。今天就把我这两年基于Java后端落地的一套token生命周期管理方案完整拆给你看，包括缓存策略、自动续期设计、调用层兜底重试，以及几次让我差点通宵的事故复盘。

如果你也在维护公众号、小程序或者企业微信相关的后端服务，并且被access_token偶发失效、多实例互相顶号、定时刷新把配额打爆这类问题困扰过，这篇文章应该能帮你省掉不少弯路。

1. 微信access_token的三条硬约束，决定了我们不能“现用现取”

很多同学第一次对接微信接口时，对token的理解就是“先调一次gettoken，拿到一个字符串，然后塞进请求头或者URL参数里”。这个思路在联调时候完全没问题，但放到生产环境就很容易埋雷。因为微信侧对access_token的管理，有非常明确的三条硬约束，可以说是专门用来逼你做生命周期管理的。

1.1 官方规则里最容易被忽略的细节

先看三条约束和它们对系统设计的影响：

这里最容易忽略的就是“5分钟重叠期”。很多人以为调用gettoken拿到新token的那一刻，旧token就立刻作废了。实际上微信给了大约5分钟的宽限期，让业务方在切换过程中不至于瞬间断流。这个宽限期，直接决定了我们后续的“提前300秒自动续期”策略可以做得很安全，而不是只能临到过期前一秒去刷新。

1.2 “现用现取”为什么在这个场景下会出事

我最早犯过的错误就是写了一个静态工具方法：

java复制public static String getToken() {
    if (token == null) {
        token = httpClient.getTokenFromWx();
    }
    return token;
}

单机、低并发的情况下，这玩意跑几个月都不会出问题。但一旦出现下面两种情况，就会连环爆雷：

• 并发击穿：token刚好过期的一瞬间，如果有几百个请求同时进来，它们都会发现本地token为空，然后同时去调微信gettoken接口。微信侧频控一旦触发，后续所有业务请求都会收到“API频控超限”之类的错误。
• 多实例各自为政：服务从1台扩容到2台之后，每台机器各自维护一份token。A机器先刷新拿到了新token，B机器由于还没到自己的过期时间，继续用旧token。等到微信侧把旧token作废之后，B机器上的所有请求就会开始报40001。

所以我说，这里需要管理的是token的“生命周期”：什么时候取、放在哪一层、什么时候换新、换新失败怎么办、运行时突然失效了怎么兜底。把这一整套流程想清楚，才算真正把微信API接口接入做稳了。

2. 两级缓存设计：为什么是本地Caffeine + Redis，而不是只放Redis

解决多实例共享问题的第一反应往往是：把token放进Redis，所有实例从Redis读不就行了？思路没错，但我后来在实践中发现，只放Redis并不够优雅。原因有两个：

• 每次业务请求都要多一次Redis网络IO。对公众号后台这种高频API调用场景来说，这是一个完全不必要的开销。
• 一旦Redis出现瞬时抖动或者网络分区，连token都拿不到，故障面会被扩大。

于是我把整个读取链路设计成了三层：本地Caffeine缓存扛读流量，Redis缓存做全局状态源，微信API只负责签发token。

2.1 三层各司其职，过期时间怎么设很关键

直接看参数设计：

为什么本地缓存选120秒而不是600秒？这其实是在效率和一致性之间取平衡。120秒意味着：如果某个实例因为缓存重建或者网络问题导致本地token落后于全局状态，最坏情况下只需要120秒就能自动纠正。对你Redis里的最新token来说，这就是“最大不一致窗口”。窗口越小，出现局部请求使用旧token的窗口就越短，代价是本地缓存命中率稍微降一点。实测下来，对token这种单个字符串的读取，Caffeine的120秒命中率已经能覆盖绝大多数QPS。

Redis的TTL我直接设置为 expires_in - 300。举个例子，微信返回 expires_in=7200，那我在Redis里设置的过期时间就是6900秒。这样一来，Redis里的key会在微信侧真正过期前300秒自动消失。这个自动消失动作本身不是事故，而是通知后续读取方“该准备换新了”。

很多教程喜欢在Redis里额外存一个expireAt字段，然后启动一个定时器做比较。这样也行，但有一个隐藏风险：如果服务器本地时钟漂移了，判断就会出错。我更推荐直接依赖Redis TTL来判断剩余时间，因为TTL的计时由Redis服务端统一控制，比每个业务实例各自用本地时间戳靠谱得多。

2.2 读取链路的并发控制：缓存穿透必须堵死

核心读取逻辑大概长这样：

java复制public String getAccessToken() {
    // 1. 先读本地Caffeine
    String cachedToken = localCache.getIfPresent(TOKEN_KEY);
    if (StringUtils.hasText(cachedToken)) {
        return cachedToken;
    }

    // 2. 本地miss，去Redis读
    String globalToken = redis.opsForValue().get(globalKey());
    if (StringUtils.hasText(globalToken)) {
        localCache.put(TOKEN_KEY, globalToken);
        return globalToken;
    }

    // 3. Redis也miss，才允许走刷新逻辑
    return refreshTokenByGlobalLock();
}

这里最关键的是第3步：Redis miss之后，不能每次都直接调微信接口。否则一旦Redis key因为TTL到期被删除，一瞬间所有请求都会同时冲进第3步。必须用分布式锁把真正调微信gettoken的请求收敛到一个。

我当时就在这个环节吃过亏。后面会专门聊那次事故。

2.3 一个容易踩的坑：不要把Caffeine的refreshAfterWrite用在token上

这个坑非常隐蔽。Caffeine里有两种刷新机制：expireAfterWrite和refreshAfterWrite。前者是硬过期，key到期后下次访问会阻塞并且重新load；后者是软刷新，到期后先返回旧值，同时在后台异步加载新值。

听起来refreshAfterWrite很完美对不对？旧值还能用，后台又换了新值，体验无缝。但对token这种凭据来说，它有一个致命缺陷：微信侧如果已经把这批token吊销了，旧值就属于“实际上已经失效”的数据，你还把它返回给业务方，拿旧token去调微信接口照样报40001。

所以我最后选择的是expireAfterWrite(120秒)硬过期，而不是refreshAfterWrite(120秒)。本地缓存过期后的首次访问可能会阻塞个几十毫秒，但换来的是不会