我已经提出了一个临时解决方案，该解决方案不是很常见，但与流行的WP缓存解决方案与cookie（在这种情况下为标准WP注释cookie）的交互作用相比，还没有出现前所未有的问题。我的解决方案还涉及在提供缓存文件方面很少定义的“已知用户”例外。无论它是否可用，我都认为对它进行解释并可能了解为什么它不是一个好主意通常具有指导意义。
我已经使用WP Super Cache，W3 Total Cache和Comet Cache测试了我的方法。在研究此问题时，我为自己详细介绍的一个就是WP Super Cache（以下简称“ WPSC”），因此我将其作为主要示例。
背景
如果将WP标准评论线程设置为允许访问者发表评论，则将为非注册用户并登录的任何评论者设置评论cookie，并使用实际的评论特权进行进一步检查。在我认为是最常见的配置中，评论者只需提供姓名和电子邮件地址。它们存储在两个浏览器Cookie中，通常是comment_author_ . COOKIEHASH和comment_author_email_ . COOKIEHASH。COOKIEHASH是根据用户选项定义的。
如果设置为将新生成的文件传递给“已知用户”，则WPSC会基于以下检查来确定是否提供缓存文件：登录的用户会获得新文件，访问者“可以发表评论”也是如此。后者主要由comment_author_cookie 在浏览器中的存在来标识，这些cookie不是由特定用户COOKIEHASH（通常但并非总是记录在站点选项中的“ siteurl”的MD5编码版本）为特定用户而唯一或唯一标识的。
来自wp-cache-phase1.php LL371-383的WPSC代码的关键部分似乎使用RegEx模式来获取字符串，并在cookie中循环：
$regex = "/^wp-postpass|^comment_author_";
if ( defined( 'LOGGED_IN_COOKIE' ) )
$regex .= "|^" . preg_quote( constant( 'LOGGED_IN_COOKIE' ) );
else
$regex .= "|^wordpress_logged_in_";
$regex .= "/";
while ($key = key($_COOKIE)) {
if ( preg_match( $regex, $key ) ) {
wp_cache_debug( "wp_cache_get_cookies_values: $regex Cookie detected: $key", 5 );
$string .= $_COOKIE[ $key ] . ",";
}
next($_COOKIE);
}
现在，如果我严格使用PHP，可以重新生成或挂钩WP核心功能，并comment_author_ . COOKIEHASH通过注释模板获得常规设置，但是我正在使用jQuery Cookie插件在jQuery中工作。但是，如您所见，如果您查看RegEx，则WPSC函数并不在乎COOKIEHASH：如果遇到，它会感到满意comment_author_。
我的解决方案
$.cookie( 'comment_author_proxyhash', 'proxy_author', { path: '/' } );
对于那些不熟悉jQuery Cookie的用户：上面的代码使用key = comment_author_proxyhash和value = 设置了一个简单的会话cookie，proxy_author对整个站点都很有用。（此外，对于那些谁使用jQuery Cookie和WP，除了预代替熟悉的jQuery $的WP jQuery，我也已经设置$.cookie.raw = true;。）
我在jQuery脚本中添加了这一行，瞧！，WPSC，W3 Total Cache和Comet Cache的行为均与我希望的一样。使用脚本并重新加载后，我得到了新的页面。如果我碰巧提出了一个真实的评论，那么就设置了normal comment_author_和comment_author_email_cookie，并且共存似乎没有任何问题。
可能的一个缺陷是，只要用户保持会话打开，“ proxyhash” cookie就会随用户一起旅行，但这并不会给我带来重大问题-甚至不值得警告。我当然从未听说过有人抱怨其中一种常规Cookie发生这种事情。
但是也许有些东西我不见了，如果对我的教育也有潜在的帮助，我会发现很多事情。或者，也许有一种相对简单的最佳实践方法可以让我COOKIEHASH在jQuery中复制，也涵盖替代用例...，或者通过其他方式达到相同的最终效果-其他诱骗缓存插件来对待访问者的其他方式作为评论者...
如果不是，是否有充分的理由不将其或其附近的东西通过插件插入宇宙？
wp_localize_script将cookie哈希传递给Javascript，以便可以使用“本机” cookie代替proxyhash。否则，这是一个非常有趣的问题，并且您的解决方案似乎很可靠，尽管cookie +缓存总是非常复杂，很难说这是“正确的”解决方案还是遗漏了什么。伟大的研究！