你在手机上打开一个网站，期待看到为小屏优化的布局，结果却加载出一个桌面版的页面，导航栏小得像蚂蚁，图片撑满屏幕，需要双手放大才能操作。这种体验，就像走进一家快餐店，却拿到一份需要自己烹饪的食材。问题的根源，往往不是网站本身没有做响应式设计，而是藏在前端或服务端的缓存层里。
缓存：一把锋利的双刃剑
缓存技术，无论是浏览器缓存、CDN缓存还是服务器端缓存（如Nginx FastCGI、Varnish），其核心目的都是为了提升性能。它们将首次请求生成的HTML或资源文件存储起来，后续请求直接命中缓存，省去了动态生成页面的开销。根据HTTP Archive的数据，一个典型的网页有近40%的资源可以从缓存中加载，这能显著降低服务器负载和用户等待时间。
然而，这把双刃剑的反面，正是我们今天要讨论的问题的起点。缓存系统默认的“键”（Cache Key）设计，通常基于URL。也就是说，对于同一个URL（例如网站的首页“/”），无论请求来自PC的Chrome还是手机的Safari，缓存系统都认为它们是同一个资源。谁先访问，谁生成的页面就会被存下来，并分发给所有后来者。
“未分离”的缓存与用户代理的盲区
当网站采用WordPress等CMS，并通过主题或插件实现PC端与移动端差异化内容输出时（比如移动端隐藏侧边栏、展示不同的广告位或首页模块），问题就暴露了。服务器端逻辑会根据HTTP请求头中的“User-Agent”字段来判断设备类型，并动态生成对应的HTML。
麻烦在于，许多缓存配置在初始阶段并未将“User-Agent”纳入缓存键的考量。假设第一个访问首页的是一个PC用户，服务器生成了完整的PC版页面，Nginx FastCGI缓存将其保存，缓存键是“https://example.com/”。紧接着，一个移动用户访问同一个URL，缓存系统直接返回了刚才存储的PC版HTML，服务器端的设备检测逻辑根本没有机会运行。用户看到的，自然就是错误的页面版本。
不仅仅是Nginx的问题
虽然原文以Nginx FastCGI缓存为例，但这种现象具有普遍性。使用Varnish、Redis进行全页缓存的架构，如果配置不当，同样会“吞掉”设备差异。甚至一些云服务商提供的“智能”CDN，如果其缓存规则设置过于宽泛，也可能导致移动端和桌面端缓存混淆。
更隐蔽的一种情况发生在“服务端渲染”的前端应用里。首屏访问的PC用户和手机用户看到的页面内容可能不同），缓存系统默认的“键”（Cache Key）设计，通常基于URL。也就是说，对于同一个URL（例如网站的首页“/”），无论请求来自PC的Chrome还是手机的Safari，缓存系统都认为它们是同一个资源。谁先访问，谁生成的页面就会被存下来，并分发给所有后来者。
诊断与解决思路
排查这类问题有个很直接的方法：用手机浏览器打开网站，查看页面源代码。如果源码中包含了本应在PC端才出现的特定CSS类名、模块代码或注释，而移动端专属内容缺失，那基本可以断定是缓存未分离导致。
解决的核心逻辑也清晰：让缓存键包含设备标识。具体到Nginx，可以通过map指令将复杂的User-Agent字符串映射为一个简单的变量（如$is_mobile），然后将这个变量加入fastcgi_cache_key。这样，“PC版/”和“移动版/”在缓存系统中就成了两个不同的资源，互不干扰。
更深一层看，这其实是个缓存粒度问题。除了按设备分离，大型电商网站可能还会按登录状态、用户地域、AB测试分组等维度进行缓存隔离。每一次分离，都意味着缓存命中率的潜在下降和存储成本的上升，但这是为了正确性必须付出的代价。架构师的决策，就是在性能、成本和业务正确性之间寻找那个精妙的平衡点。
