先确认缓存状态和过期策略

我会先确认当前缓存是否设置了过期时间。这步很关键，因为很多人以为默认就有过期，实际上Flask-Caching的默认值可能是永久缓存。在决定是否设置过期时间时，先看缓存数据的变更频率。如果数据基本不变或允许短暂不一致，可以不设过期；若数据有规律更新（如每5分钟从数据库拉取一次），则需设置与之匹配的超时时间。检查方法很简单：在缓存后端（如Redis）执行TTL命令，观察键是否存在剩余生存时间。若发现大量缓存永久存在，且业务对时效性有要求，就应当配置过期策略。这个判断可以排除很多无用工作，比如数据本身变化慢，设了过期反而增加数据库压力。

容易误判的地方：全局默认与局部覆盖

我见过不少人在配置里写app.config['CACHE_DEFAULT_TIMEOUT'] = 300，然后认为所有缓存点都自动过时了。但装饰器里的timeout参数会覆盖全局值，如果不写，才用全局。而另一个坑是，如果装饰器写在路由装饰器内侧，可能根本不会执行缓存。

设置过期时间最直接的方式是在Flask应用配置中设定全局默认值：app.config['CACHE_DEFAULT_TIMEOUT'] = 300（单位秒）。对个别缓存点，可在装饰器内指定timeout参数：@cache.cached(timeout=120)。自动更新通常借助缓存键设计实现：让缓存键包含数据版本号或最后更新时间戳，当数据变化时主动调用cache.set()更新新键。注意timeout必须在装饰器上正确传递，否则沿用全局值。这里需要特别注意装饰器顺序：@route必须在外层，@cache.cached在内层，否则缓存可能无法正确生成键。

建议的处理顺序：先检查配置，再调整装饰器

我的经验是先检查全局配置是否合理，再逐个确认关键接口的装饰器参数。顺序错了容易重复劳动。比如你怀疑某个接口缓存没过期，应该先看Redis里该键的TTL，如果永久（-1），说明要么没设timeout，要么被全局值覆盖了。此时不要急着改代码，先确认装饰器有没有加timeout。

如果确实需要自动更新缓存，一般通过修改缓存键实现，比如在键中加入last_updated时间戳。每当数据更新时，调用cache.set('key_'+timestamp, data, timeout=X)。这样旧的缓存键会在超时后自动失效，新数据立刻生效。注意这种方式需要你控制数据更新的时机，不适合变化频率不可预知的场景。

配置和命令示例：用Redis TTL验证

验证过期时间是否生效，可先通过浏览器或curl访问接口，首次请求后检查缓存后端。若使用Redis，执行redis-cli TTL <key>，返回值应为正数（剩余秒数）或-2（键不存在）。等待超时后再次请求，观察是否命中后端数据库。若始终返回-1（无过期），说明未正确设置timeout。也可在日志中打印cache.get()的结果，辅助判断更新时机。注意测试时先清除已有缓存，避免旧数据干扰。

用curl快速测试的例子：curl -I http://localhost:5000/api/data，然后去Redis检查TTL。如果TTL刚设了300秒，你观察它递减到接近0时再次请求，应该看到数据库查询日志出现。如果没有，说明缓存没有按预期重建。

风险边界与回滚策略

设置过期时间时需警惕缓存雪崩：如果大量缓存同时过期，瞬间请求会全部穿透到数据库。解决方案是将过期时间分散开，例如对每个键加上随机偏移量：timeout = base_timeout + random.randint(0, 600)。另一个风险是缓存击穿：热点数据过期瞬间的高并发。可考虑使用互斥锁，在更新缓存时只允许一个线程重建。另外注意TinyDB或simple缓存后端不支持精确过期，建议使用Redis或Memcached。修改缓存配置后必须重启Flask进程才能完全生效。

回滚时，先恢复配置文件的默认值，再重启进程。如果只改了个别装饰器的timeout，只需重新部署代码。保险期间，可以在Redis里先删除有问题的键，确保旧配置不再生效。

后续维护要点

建议定期监控缓存命中率和TTL分布。如果发现大量键TTL剩余时间集中，说明随机偏移没有加够。另外，当业务需求变化导致数据更新频率改变时，要同步调整过期时间，否则缓存要么长期不更新，要么频繁重建。还有一个容易被忽略的：Flask-Caching的默认键前缀CACHE_KEY_PREFIX如果与其他系统共用Redis，可能产生冲突，要单独设置。总之，过期时间不是设了就不管了，需要配合数据变更通知或定时任务来维持一致性。