4月6日起，所有新建Vercel项目将默认读取外部源的缓存头。这个改动看似技术细节，实则让一批依赖"零缓存代理"的架构设计直接失效。
过去三年，开发者用Vercel做反向代理时有个隐形约定：外部接口默认不缓存，想开缓存得手动在vercel.json里塞x-vercel-enable-rewrite-caching头。现在规则反转——新用户开箱即缓存，老项目想跟进得手动点按钮。
缓存策略的"默认选项"战争
Vercel的CDN（内容分发网络）这次把决策权交给了上游服务器。如果你的外部源没配好Cache-Control头，Vercel会按上游指示缓存，最长可能拖到你下次部署才刷新。
这对两类人是暴击：一是把Vercel当纯转发层用的团队，他们的外部API可能根本没设计缓存策略；二是做多源聚合的开发者，某个子服务的缓存头会污染整体响应。
新规则下，Vercel-CDN-Cache-Control、CDN-Cache-Control、普通Cache-Control三层头并存，优先级由内到外递减。 你可以在外部源里用Vercel-Cache-Tag给内容打标签，后续通过Vercel后台或API精准清除缓存，不用干等TTL过期。
老项目的"选择性失忆"
现有项目不会自动升级。想切新行为得进Dashboard手动开启，想保持现状什么都不用做。Vercel留了条后路：把x-vercel-enable-rewrite-caching设为0，可强制关闭特定路径的缓存。
这种"新用户新规则、老用户老规则"的切割，在平台升级里算温和派。但隐患在于——团队里如果有人4月6日后新建项目，缓存行为会和存量项目不一致，排查问题时容易踩坑。
一个需要检查的细节
官方文档里埋了句话：「Review your upstream cache headers before April 6th」。翻译成人话：如果你的外部源之前乱写Cache-Control，现在它真的要生效了。
典型陷阱包括上游返回了max-age=31536000（一年）但内容其实天天变，或者CDN-Cache-Control和Cache-Control冲突导致缓存层行为诡异。Vercel的缓存标签系统能缓解，但前提是外部源得主动吐Vercel-Cache-Tag头。
这次改动把Vercel从"代理工具"重新定位为"缓存协作方"。对认真配过头部的团队是减负，对随手接API的开发者可能是凌晨告警的伏笔。你的外部源缓存头，上次检查是什么时候？
热门跟贴