商品页只增加了一个“欢迎回来”Block，Varnish 命中率却骤降。Magento 布局树中出现不可缓存 Block，往往会让整个页面响应绕过 Full Page Cache；一个很小的个性化组件，代价可能是每个请求都运行完整 PHP 页面。
确认页面是否真的不可缓存
比较响应中的 Cache-Control、X-Magento-Cache-Debug、Age，并连续请求同一匿名 URL。开发环境可检查布局合并与 profiler，搜索自定义 XML 的 cacheable="false"。不要只看 block_html cache，它与 FPC 是不同层。
什么内容不该进公共 HTML
客户姓名、购物车、愿望单、专属余额和一次性 Token 不能被共享缓存。标准做法是公共页面保留占位，通过 customer-data/private content 或受保护 AJAX 在浏览器端加载。CDN/FPC 页面本身必须不包含敏感值。
公共但频繁变化的内容
库存提示、倒计时或汇率未必需要关闭整页。可以用短 TTL、缓存标签精确失效、边缘 include 或异步接口，选择取决于一致性要求。不要把每秒变化的时间直接渲染进服务器 HTML。
Block 缓存键也要完整
移除 cacheable=false 后，如果 Block 自己缓存但 key 没有包含 store、currency、customer group 等维度，会返回错误内容。私有身份绝不能仅靠把 customer_id 放进公共缓存键，因为对象数量与泄露风险都很高。
修复后测试匿名、登录、两个客户组、不同币种与 Store；公共 HTML 应 HIT，私有组件正确更新，退出登录后旧客户数据立即清除。性能和隔离必须同时通过。
定位是哪一个 Handle 加入
同一 Block 可能只在某个 layout handle 或客户组条件下出现，导致部分 URL MISS。记录页面完整 handle 集和合并来源，搜索模块/主题 XML；第三方模块更新后新增的 cacheable=false 也要纳入版本对比。
表单与 CSRF 不应嵌入缓存页状态
包含 form key 的表单可以用 Magento 支持的占位/JS机制获取当前值，不能为了 form key 把整页设不可缓存。登录状态判断同理，应使用 HTTP context/private content，而不是模板直接读 session。
量化收益
修复前后比较 FPC hit rate、TTFB、PHP 请求数和后端 CPU，分别观察首页/分类/商品。若命中率恢复但私有 AJAX 数量暴增，首屏仍可能慢；可合并 section 请求和延迟非关键组件。
不要把 ESI 当作默认答案
Varnish ESI 可以单独刷新片段，但增加回源、Cookie 与失效复杂度，而且私有内容配置错误仍可能泄露。对小型客户组件，customer-data 往往更符合 Magento 机制；只有服务器端片段确有 SEO 或首屏要求时，再评估 ESI 与访问控制。
缓存失效标签不要无限膨胀
即使页面可缓存，Block 返回过多 identity tag 也会增加缓存对象头和 purge 成本。只声明真正影响输出的实体，避免把整个目录标签挂到一个小组件。商品更新后检查需要失效的页面被清除，其他热门页仍保持命中。
