Cl4多级缓存是可落地的WordPress性能分层防御体系，涵盖浏览器缓存、CDN边缘缓存、服务器端对象缓存和页面静态缓存四层，旨在高并发下稳住LCP≤1.2秒、INP≤100ms。

Cl4多级缓存不是概念，是可落地的WordPress性能分层防御体系：浏览器缓存 → CDN边缘缓存 → 服务器端对象缓存 → 页面静态缓存。它解决的不是“能不能快”，而是“在高并发、动态内容、第三方依赖共存下，如何稳住LCP不破1.2秒、INP压进100ms内”。很多团队卡在“装了WP Rocket还是慢”，问题不在插件，而在缓存层级之间互相覆盖、失效策略打架、动静资源混发——Cl4重构的核心，是让每一层只干它该干的事。

浏览器缓存：控制权必须收回来

默认情况下，WordPress常把JS/CSS版本号写死或用时间戳，导致每次更新都绕过本地缓存。这不是安全，是浪费。

• 用filemtime()动态生成资源版本号，比如：wp_enqueue_style('main', get_stylesheet_uri(), [], filemtime(get_stylesheet_directory() . '/style.css'));
• 在Nginx配置中强制静态资源长期缓存（1年），但HTML设为no-cache或max-age=0，避免页面过期；
• 禁用主题/插件自带的“自动刷新缓存”按钮逻辑，这类JS常在页面加载后发起二次请求，直接拖垮INP。

CDN边缘缓存：别只配“缓存全部静态文件”

CDN不是保险箱，是带策略的前置网关。多数人只开“缓存静态资源”，结果关键LCP图片被缓存在远端节点，首屏反而更慢。

• 对WebP图片、关键CSS、字体文件启用Cache-Control: public, max-age=31536000，并开启Brotli压缩；
• 对/wp-admin/、/wp-json/、含utm_或fbclid参数的URL，强制cache-control: private, no-store；
• 设置Origin Pull规则：当CDN回源时，只携带必要Header（如Accept），去掉User-Agent等干扰字段，避免触发WordPress的移动端重定向逻辑。

对象缓存：Redis不是装上就有效

WP Object Cache插件只是桥梁，真正起效的是键命名规范与失效粒度。常见错误是全站用同一个prefix，一删全崩；或缓存整个WP_Query结果，连分页参数都不区分。

• 用wp_cache_set()时带明确group，如wp_cache_set('post_123_meta', $data, 'post_meta')；
• 禁用wp_suspend_cache_invalidation(true)类全局开关，改用细粒度钩子清理，例如在save_post里只清除对应文章的post_meta和related_posts组；
• Redis内存分配建议≥256MB，淘汰策略设为allkeys-lru，避免因内存满导致缓存雪崩。

页面级静态缓存：WP Rocket只是起点

WP Rocket默认缓存所有公开页面，但电商类站点的商品页、会员中心页、搜索结果页，必须做差异化处理。否则用户看到的是别人刚加购的商品列表。

• 在WP Rocket「高级规则」中，对/product/.*路径启用「缓存排除」，但对/product/[^/]+/（即商品详情页）启用「缓存但排除Cookie」；
• 用rocket_clean_files()配合transition_post_status钩子，在文章发布/更新时精准清除对应URL缓存，不扫全站；
• 关闭「延迟JavaScript执行」对关键交互组件（如Add to Cart按钮、筛选器）的影响，改用data-no-optimize属性白名单控制。