环境： 自托管 Discourse，托管在 AWS EC2 上，使用 Ubuntu 24.04 AMI。主机为 r7g.large，配备 2 个 vCPU 和 16GB RAM。Discourse 版本为 3.6.0.beta1-dev (db974047e4)，并定期更新。WordPress 版本为 6.8.2，wp-discourse 插件版本为 2.5.9。WordPress 和 Discourse 都通过 Cloudflare 进行代理（“橙色云”）。
当前 wp-discourse 设置： 我为所有主题显示 Discourse 评论，并且勾选了“使用 Ajax 加载评论”。（读者和 WordPress 网站所有者都希望新评论尽快显示在 WP 帖子下方，因此根据所有者的要求，我希望保持启用“使用 Ajax 加载评论”。）
我看到的情况： 总的来说，wp-discourse 工作得很好。当读者访问 WP 帖子时，他们的浏览器会请求 /wp-json/wp-discourse/v1/discourse-comments?post_id=XXXXX，其中 XXXXX 是预期的帖子 ID，评论会正常加载。新评论会在发布到 Discourse 的几秒钟内显示在 WordPress 端。
然而，当访问该网站上的任何 WordPress 地址时，访问者的浏览器也会发出一个对同一个 discourse-comments URI 的调用。网站首页、评论存档、关于页面、联系页面、作者简介页面、静态页面、搜索页面，等等。这些请求都是针对 /wp-json/wp-discourse/v1/discourse-comments?post_id=undefined 的，并且我在 24 小内收到了约 20,000 个此类请求（大致对应于我服务的总页面数）。
我不太在意，但处理如此多的额外请求给我的 WP 源服务器带来了明显的负载。现在还可以承受，但该网站是一个墨西哥湾沿岸天气预报网站，在天气事件（尤其是飓风）期间，我们的每日浏览量会从正常的约 20,000 飙升到 150-200 万，而一天处理数百万个 post_id=undefined 请求将是一个挑战。
我在 meta 上找到的唯一似乎与此问题相关的帖子是2019 年的这个帖子，其中给出的答案是“关闭使用 Ajax 加载评论”。如上所述，考虑到我所处的环境，我宁愿不这样做。
这是对一个代表性的 undefined 请求的描述。当我访问网站首页时，就生成了这个请求：
解决方法： 由于这些请求似乎并没有真正做任何事情，我已经实施了一个 Cloudflare WAF 规则，用一个空的响应体在 CF 层面响应它们。这完全消除了问题行为的影响——我的源服务器不再看到 undefined 请求，我也不会浪费 CPU 来生成响应。
问题： wp-discourse 插件是否打算为每一个 WordPress 页面发送 discourse-comments?post_id=undefined 的 Ajax 请求？似乎只有在实际加载 WP 帖子（或者如果 wp-discourse 选项中启用了页面，也加载页面）时才发送这些请求，会更安全（或者至少更具确定性）。
正如我所说，我已经有了一个似乎能解决问题的解决方法，并且消除了处理数万个无效请求的额外负载，所以我现在很稳定，处于良好状态。但我想知道我看到的行为是否是设计使然。
