079、缓存机制减少API调用昨晚上线了一个小服务，日志里疯狂刷第三方天气API的调用记录，一分钟几百次，全是同一个城市的查询。客户那边没投诉，但我的钱包在滴血——按次计费，一个月免费额度五千次，照这速度一天就烧完了。更尴尬的是，代码里明明写了个cache字典，结果每次请求都绕过它直接打远程接口，查了半天才发现，缓存键拼错了——城市名带了个前后空格，跟查询参数里的city.strip()对不上。修完之后，调用量直接掉到原来的百分之一。这个坑不深，但很典型，很多“缓存没生效”压根不是缓存库的问题，是你根本没让缓存命中。今天借这个事，把API调用侧的缓存设计掰开揉碎聊一遍。我们不谈高深分布式缓存，就聊单机进程里怎么用最简单的方式把重复的外部请求挡在门外。你省掉的不是一次HTTP请求，是上下游一整条链路先想清楚一个事：每次调用第三方API，背后的成本不止是那几分钱。你的服务器要发DNS解析、建立TCP连接、走TLS握手、发送HTTP头、等对方处理、接收响应、解析JSON、再释放连接。如果对方接口慢，你还要挂起一个线程或协程在那里等。更不用说，如果对方有QPS限制，你频繁打过去可能会触发限流，对方直接返回429，你还要写重试逻辑，重试又造成更多请求，恶性循环。缓存的本质是拿内存换时间，拿“可能过期”换“确定性”。对于读多写少、数据实时性要求不高的接口，缓存是性价比最高的优化。怎么判断一个API适不适合缓存？看两个指标：一是数据变化频率，二是调用方对时延的容忍度。比如天气数据每小时更新一次，你五分钟内调十次，拿到的东西一模一样，这就是典型浪费。又比如股