如果你正在为网站配置Nginx FastCGI缓存，并且发现移动端用户总是看到错误的页面布局或内容，那么问题很可能就出在缓存键的设计上。一个被遗忘或错误实现的$is_mobile标识，足以让整个响应式缓存策略功亏一篑。
缓存键：不只是URL的映射
很多开发者容易陷入一个误区，认为缓存键就是URL的简单哈希。在单一设备访问的理想世界里，这或许成立。但现实是，同一个URL背后，可能对应着完全不同的渲染逻辑。想象一下，你的首页在PC上显示一个宽屏轮播图，而在手机上却需要展示一个垂直堆叠的卡片列表。如果缓存系统无法区分这两种请求，那么第一个访问首页的设备类型，就决定了此后所有用户（无论他们用什么设备）看到的内容。
这就是$is_mobile标识存在的根本原因。它的作用，是将“设备上下文”这个维度，硬编码到缓存键的生成逻辑中。本质上，缓存键从一个简单的$scheme$request_method$host$request_uri，升级为了$scheme$request_method$host$is_mobile$request_uri。这一个小小的追加，意味着https://example.com/这个地址，在缓存系统中会分裂成两个独立的实体：一个键值对应PC版缓存文件，另一个则对应移动版。
实现的陷阱与细节
然而，仅仅是添加变量还不够，关键在于如何定义“移动端”。最常见的做法是通过Nginx的map指令，基于$http_user_agent（用户代理字符串）来判断。这里就藏着第一个坑：用户代理的匹配规则。
map $http_user_agent $is_mobile {
default 0;
~*mobile 1;
}上面这个简单的规则匹配所有包含“mobile”字串的UA，覆盖了大部分情况。但如果你需要更精确，比如区分平板电脑和手机，或者排除某些伪装成移动端的爬虫，规则就会变得复杂。一个过于宽泛的规则可能导致平板电脑错误地吃到手机版缓存，而一个过于严格的规则又可能让某些新款手机被识别为PC。
第二个陷阱在于缓存区的隔离。仅仅在缓存键上做文章是治标不治本。你必须为PC和移动端配置独立的fastcgi_cache_path和keys_zone。比如分别定义pc_cache和mobile_cache两个缓存区。这样做的目的不仅是逻辑上的清晰，更重要的是在缓存清理时能做到精准打击。否则，当你清理一个页面的缓存时，可能会不分青红皂白地把PC和移动端的缓存都删掉，或者更糟，只删掉了其中一个。
清理机制：被忽略的关键一环
说到缓存清理，这是$is_mobile策略中最容易被忽视，也最容易出错的部分。很多流行的WordPress缓存插件（或其Nginx助手）在设计时，默认都只针对单一缓存区。当你引入双缓存区后，原有的清理机制会完全失效。
你必须修改插件的核心代码，使其在触发清理时，能同时向两个不同的清理接口发起请求。例如，将原来的清理请求/purge/path/to/post，拆分成/purge_pc/path/to/post和/purge_mobile/path/to/post两个独立的请求。这通常意味着要直接编辑插件文件，这是一个脆弱的操作，因为每次插件更新都可能导致修改被覆盖。
不仅仅是PC与移动
更进一步思考，$is_mobile标识背后的思想，可以推广到任何需要基于请求上下文提供不同响应的场景。例如：
- AB测试：为不同用户群组提供不同的页面版本，缓存键可以包含用户分桶标识。
- 多语言网站：缓存键需要包含
$http_accept_language或URL中的语言前缀。 - 登录态与访客态：虽然动态内容通常不缓存，但对于一些登录后也只看到公共内容的场景，可以用cookie值作为缓存键的一部分。
判断是否需要在缓存键中添加一个标识符，核心标准是：同一个URL，是否会因为请求的某些特征（如设备、语言、登录状态）而返回本质上不同的HTML内容？如果答案是肯定的，那么缓存键就必须包含这些特征。
