FacetWP 是 WordPress 中非常流行的筛选插件，它能够基于自定义字段和分类法快速构建前端过滤界面。在默认配置下，当结果数量超过每页设定值时，FacetWP 会渲染一个“加载更多”按钮，用户必须主动点击才能追加后续内容。对于内容密集型站点，例如电商商品列表或教程索引，这种手动触发方式会打断阅读节奏。将“加载更多”改为无限滚动，可以让用户在滑到列表底部时自动拉取新数据，既保留了 FacetWP 的筛选能力，又显著降低操作成本。
理解 FacetWP 的刷新机制与扩展点
要实现无限滚动，第一步是弄清 FacetWP 在什么时机向服务端请求数据。插件在前端维护了一个 FWP 全局对象，每次筛选条件变化或点击“加载更多”时，都会调用内部的刷新流程，并通过 facetwp_refresh 这一事件对外广播。我们的自动加载逻辑不应该直接重写按钮事件，而是监听这个统一事件，这样无论用户改变筛选项还是系统自动触发，都能被同一套逻辑捕获。
另一个关键点是分页状态的管理。FacetWP 在 FWP.settings.pager 中记录了当前页码与总页数，当 current_page 达到 total_pages 时，按钮会被自动隐藏。我们在滚动监听中需要先读取该状态，确认还有剩余页才发起加载，否则会请求空数据。下面的代码展示了如何安全地读取分页信息：
// 读取 FacetWP 分页状态
function hasMorePages() {
if (!window.FWP || !FWP.settings.pager) {
return false;
}
var pager = FWP.settings.pager;
return pager.current_page < pager.total_pages;
}
除了分页状态，还要注意 FacetWP 的加载锁。插件在请求过程中会把 FWP.loaded 标记为 false，完成后才置回 true。如果我们不加判断地连续触发，可能造成多次叠加请求。因此自定义逻辑里必须复用这一标记，或自行维护一个 isLoading 变量做互斥。
编写滚动监听与自动加载逻辑
滚动监听本身并不复杂，但要把它和 FacetWP 结合起来就需要一点技巧。我们采用节流方式绑定 scroll 事件，当视口底部距离文档底部小于一定阈值（例如 400 像素）且仍有更多页时，模拟点击“加载更多”按钮或调用 FWP.load_more()。直接调用内部方法比触发 DOM 点击更可靠，因为某些主题会对按钮做样式隐藏但功能仍在。
下面给出一个完整的实现示例，包含节流函数、边界判断以及移动端兼容处理。我们把脚本放在 jQuery(document).ready 中，确保 FacetWP 脚本已就绪。同时保留原按钮，当 JavaScript 被禁用或滚动事件失效时，用户依旧可以手动加载。
jQuery(function($) {
var loading = false;
var threshold = 400;
// 简单节流，避免 scroll 频繁执行
function throttle(fn, delay) {
var timer = null;
return function() {
var context = this, args = arguments;
if (!timer) {
timer = setTimeout(function() {
fn.apply(context, args);
timer = null;
}, delay);
}
};
}
function tryLoadMore() {
if (loading) return;
if (!window.FWP || !FWP.settings.pager) return;
if (FWP.settings.pager.current_page >= FWP.settings.pager.total_pages) return;
var scrollTop = $(window).scrollTop();
var docHeight = $(document).height();
var winHeight = $(window).height();
if (docHeight - (scrollTop + winHeight) < threshold) {
loading = true;
// 调用 FacetWP 内置加载更多
if (typeof FWP.load_more === 'function') {
FWP.load_more();
}
// 加载完成后解锁
$(document).on('facetwp-refresh', function() {
loading = false;
});
}
}
$(window).on('scroll', throttle(tryLoadMore, 200));
});
上述代码在桌面端与移动端均可工作，因为 scroll 事件在两种环境都会触发。若你的站点使用了平滑滚动库或虚拟列表，需要把阈值调大一些，防止动画未完成就提前请求。此外，facetwp-refresh 事件在每次刷新结束都会抛出，我们把解锁逻辑绑定在这里，能保证上一批数据渲染完毕后再允许下一次滚动加载。
常见问题排查与性能优化建议
实际部署中，最常遇到的问题是“重复加载同一页”。这通常是因为 facetwp-refresh 被多次绑定，或者 loading 变量在异步队列里没有及时复位。推荐把加载锁改为基于 FWP.loaded 的判断，例如 if (FWP.loaded === false) return;，这样能与插件内部状态完全同步，避免自管变量遗漏释放。
另一个隐患是筛选条件切换时旧滚动监听未清理。当用户修改分类或搜索词，FacetWP 会重置页码，如果此时刚好在页面底部，可能瞬间拉取多页。解决办法是在 facetwp-refresh 开始时把 loading 强制设为 false，并重新计算位置。以下片段展示了如何安全地重置：
$(document).on('facetwp-refresh', function() {
loading = false;
// 若筛选后内容较短，可主动补一次加载
setTimeout(function() {
tryLoadMore();
}, 300);
});
从性能角度看，无限滚动虽好，但也可能让单次会话的请求量翻倍。建议配合浏览器缓存与 FacetWP 的缓存插件（如 Redis 或对象缓存）使用，并对列表图片启用懒加载。若站点流量较大，还可以在滚动逻辑中加入请求间隔下限，例如两次自动加载至少间隔 800 毫秒，减轻服务端压力。通过这些细节调整，就能在几乎不改主题结构的前提下，把 FacetWP 的“加载更多”平稳演进为流畅的无限滚动体验。