在Shopify主题开发中，集合页面（collection page）通常承担产品筛选与分页的职责。当顾客使用侧边栏或顶部工具栏筛选出特定价格区间、产品类型或自定义标签后，点击某个商品进入详情页，再试图通过浏览器返回或页面内前后导航回到列表时，经常会发现之前选好的筛选条件全部清空，分页也跳回了第一页。这种现象的根源在于多数主题仅把筛选状态保存在前端DOM或临时会话中，而集合分页链接默认只携带page参数，没有把filter参数带回URL。要实现基于筛选结果的产品前后导航，核心思路是让筛选状态成为URL的一部分，并在详情页与集合页之间双向同步。
理解Shopify筛选参数的URL结构
Shopify自Online Store 2.0之后，筛选功能主要由官方Search and Discovery应用提供，其生成的筛选链接遵循一套固定的query参数规则。例如颜色筛选会表现为filter.p.product_type=Shirt或者filter.v.option.color=Blue，价格区间则形如filter.v.price.gte=10&filter.v.price.lte=50。这些参数与分页参数page=2可以共存于同一个集合URL中。问题在于，很多老旧主题或自定义分页器在渲染上一页下一页链接时，只使用了paginate.next.url，而这个地址在Liquid中不一定自动包含当前的filter参数，尤其是当筛选是由JavaScript动态改写地址栏而非服务端渲染时。
我们需要先在集合模板中确认分页对象的行为。在Liquid里，paginate标签生成的next和previous属性所带的url，默认会保留当前请求的所有query参数，包括filter类参数，前提是这些参数确实出现在初始服务端请求的URL上。如果筛选完全由前端JS通过history API变更，而服务端并未感知，那么分页链接就不会带筛选。因此，保证筛选参数从第一次请求就存在于URL，是实现后续前后导航的基础。可以通过在筛选表单提交时做整页跳转，或者使用fetch配合pushState但要同步让分页器重新渲染。
另一个容易忽略的点是参数顺序和编码。Shopify对多值筛选使用重复key，例如filter.p.tag=Red&filter.p.tag=Blue，在Liquid中通过request.query_string可以拿到原始串。手动拼装分页地址时，不要对参数做不当urldecode再encode，否则像filter.v.option.size=XS里的等号与斜杠可能被破坏。建议直接基于request.query_string做字符串替换或正则提取page段，保留其余部分。
在商品详情页生成保留筛选的上下页链接
顾客从筛选列表进入商品页后，详情页本身并不知道顾客来自哪一页、用了什么筛选。常见做法是把来源集合URL（含筛选与page）作为ref或from参数带进商品页，例如在集合页的产品卡片链接上追加?return_to=当前完整路径。这样在详情页底部，我们就能渲染出“返回筛选列表”以及基于该列表推算的“上一个商品”“下一个商品”导航。不过更优雅的方案是：不在详情页存全量列表，而是仅提供返回链接，真正的前后商品切换仍回到集合页用其分页器完成。
如果确实需要在详情页内做产品级前后导航（比如服饰品类顾客习惯一件件看），可以通过在集合页把当前筛选结果的所有product handle按分页顺序写入一个隐藏的JSON到localStorage，或以meta形式注入。详情页读取该序列，找到当前handle的位置，生成prev/next handle链接，并把这些链接也带上return_to参数。注意，当顾客改动筛选后，localStorage里的序列就失效了，必须加一个筛选签名（如query_string的hash）来做校验。
下面给出一段集合页注入导航上下文的Liquid与JS协作示例，它把带筛选的当前页URL和下一页URL暂存，供详情页读取：
// 在collection.liquid底部输出
const filterNav = {
query: "{{ request.query_string }}",
currentPage: {{ paginate.current_page }},
nextUrl: "{{ paginate.next.url }}",
prevUrl: "{{ paginate.previous.url }}"
};
localStorage.setItem('shopify_filter_nav', JSON.stringify(filterNav));
这段代码中，Liquid变量在服务端被替换为真实地址，由于paginate.next.url已含filter参数，存入localStorage后，详情页即可构造“继续浏览”链接。但注意request.query_string在Liquid中输出时，如果含双引号会破坏JS字符串，实际项目应改用escape滤镜或输出到data-属性再用dataset读取。
自定义分页器与官方筛选的兼容处理
不少团队为了UI统一会自己写分页组件，而不是用默认paginate标签。此时必须手动从collection.products结合collection.all_products_count计算页数，并拼接URL。关键函数是保留filter参数：先解析location.search，删除其中的page项，再设置新的page值。如下方片段所示，用URLSearchParams处理最稳妥，它能自动处理多值filter。
function buildPageUrl(pageNum) {
const params = new URLSearchParams(window.location.search);
params.delete('page');
if (pageNum > 1) {
params.set('page', pageNum);
}
const base = window.location.pathname;
return base + (params.toString() ? '?' + params.toString() : '');
}
// 绑定到上一页按钮
document.querySelector('.prev-btn').addEventListener('click', () => {
const curr = parseInt(new URLSearchParams(window.location.search).get('page') || '1', 10);
if (curr > 1) window.location.href = buildPageUrl(curr - 1);
});
上述做法保证了点击分页时，颜色、价格等filter参数原样保留。但如果在Shopify后台启用了Search and Discovery的AJAX筛选（即不刷新页面而用JS拉取结果），分页器也必须改用AJAX，否则点分页会整页刷新丢掉前端状态。此时应该监听应用的history变化事件，或者利用官方提供的window.Shopify.theme.js钩子，在筛选回调里重绘分页器而非跳转。
最后要提醒，产品详情页的“前一个后一个”若指向其他集合，需要判断来源集合类型。从/collections/all带筛选进来的，返回时也应是/collections/all加参数，而不是默认集合。我们可以在详情页用document.referrer配合正则提取集合handle，再拼回filter参数，这样就能在顾客心智中形成一条连续的“筛选-翻页-看商品-返回原筛选翻页”的闭环，显著提升留存与下单概率。
Shopifyproduct_filteringcollection_pagination修改时间：2026-08-17 11:00:40