WooCommerce 订阅试用消失之谜

很多时候，当你发现一个 Bug 表现为「登录用户正常，游客用户异常」时，第一反应一定是缓存（Caching）。但这次我踩的坑告诉我：不要太迷信这个经验法则。

一个健身会员网站开启了 7 天免费试用，逻辑很简单：用户注册 → 免费体验一周 → 自动扣费。结果上线后发现，游客在产品页完全看不到试用信息，直接显示月费，且结账时被直接扣款，试用期凭空消失。而登录用户一切正常。

排除缓存的实操过程

面对这种典型的「状态差异」，我最初也陷入了缓存的死胡同。该站部署了多层缓存：页面缓存、反向代理缓存以及持久对象缓存。按照常理，游客请求会被激进地缓存，而登录用户获取的是新鲜页面。

为了彻底排除缓存干扰，我做了以下实测：
1. 清空所有页面缓存和反向代理缓存。
2. 使用 WP-CLI 直接强制刷新对象缓存：

   wp cache flush

3. 在 URL 后面随机加 query string 强制刷新，并检查响应头（Response Headers）。

结果显示请求状态是明确的 MISS，意味着页面是实时由 PHP 生成的，但试用信息依然没出现。这直接证明了：这不是缓存问题，而是应用层逻辑在针对游客做「截断」。

逐步排除法：定位故障点

既然缓存是烟雾弹，我开始在代码和配置层面对整个技术栈进行地毯式搜索。

• 产品配置检查：确认所有订阅产品的试用期都正确设置为 7 天，排除单一产品配置错误。
• 全局搜索：用 grep 在主题、Must-Use 插件和代码片段中搜索所有涉及 trial、price_display 和登录状态判断的关键字。
• 插件冲突排查：

- WooCommerce Dynamic Pricing：怀疑是基于角色的定价规则。但实测发现普通 Customer 账户（非管理员）能看到试用，说明不是角色权限问题，而是「是否登录」的二元对立。
- 订阅增强插件：通过单步跟踪发现，该插件仅在处理重复试用时介入，对游客请求完全透明。
- 核心代码追踪：我顺着 WooCommerce Subscriptions 的核心函数 → 试用时长读取 → 价格 HTML 组装这一链路跑了一遍，确认核心代码里没有任何针对登录状态的硬编码拦截。

核心排查逻辑总结

这次排查过程中，我记录的分析路径如下（这也是建议大家在遇到类似 Bug 时采用的逻辑）：

• 维度一：数据源验证 → 数据库/后台设置是否正确？（结论：正确）
• 维度二：环境干扰验证 → 是否为缓存/CDN 导致？（结论：通过 Cache-Control 验证排除）
• 维度三：权限/角色验证 → 是特定角色失效还是所有游客失效？（结论：所有游客失效）
• 维度四：代码路径追踪 → 从输出端反向追溯到数据读取端，检查中间是否有 if (is_user_logged_in()) 之类的条件判断。

这种「剥洋葱」式的排查虽然慢，但能确保在进入深层代码调试前，已经清空了所有低级错误的可能性。

经验教训

这次实战最大的启发是：不要让「常见症状」掩盖了「真实原因」。

在 WooCommerce 这种高度插件化的生态里，很多开发者习惯于把 Logged-in vs Guest 的差异归结为缓存。但实际上，很多第三方插件为了实现某种「会员专享」逻辑，会随手写一行 if ( ! is_user_logged_in() ) return;。

如果你在做类似的 AI Agent 自动化部署或工作流开发，建议在日志中记录每个关键判断节点的 Boolean 值，而不是只看最终的输出结果，这样能节省大量在缓存清理上浪费的时间。