商城项目过滤条件筛选：从动态SQL到索引优化与状态管理的实践

“商城项目的过滤条件筛选”，这句话说大不大，说小不小，却是电商系统里几乎天天要碰、天天要改的模块。不管是商品列表页左侧那一竖排复选框，还是移动端顶部“筛选”按钮弹出来的半屏面板，背后接的都是一整套字段、接口、状态管理和查询策略。我在维护商城的这几年里，光这个功能就重写过三次，每次重写都能挖出之前埋的雷。今天这篇就用一个后端为主、兼顾前端的视角，把过滤条件筛选中那些设计取舍、动态查询实现、索引优化、交互状态同步，以及我实际踩过的坑，一次说透。适合正在做商城、或者准备做商品/内容筛选功能的朋友参考。

1. 过滤条件筛选的整体设计思路：先想清楚这四件事

1.1 筛选维度不是越多越好，先分清主次

很多产品经理拿到筛选需求时，第一反应就是把能列的维度全列上：品牌、价格、颜色、尺寸、材质、上市年份、销量、评分、是否有货、优惠类型、发货地、是否包邮……等真做出来，前端面板长得像一张调查问卷，后台查询条件堆了二十多个参数，开发效率和用户体验一起完蛋。

我做了几次之后的原则是：主筛选维度控制在 5~8 个，而且要把维度分成三类来对待。

第一类是“类目决定型”维度，比如手机这个类目下的“内存”“屏幕尺寸”“电池容量”，它们不是所有商品通用，而是跟随类目模板走的。第二类是“通用交易型”维度，比如价格区间、品牌、是否有货、包邮，几乎所有类目都有，应该做成公共组件和公共字段。第三类是“运营临时型”维度，比如“秒杀”“满减”“新品首发”，这类条件时效性强，如果直接做成硬查询条件，一旦活动下线，查询逻辑里还要留着兼容代码，非常痛苦。

我建议的做法是把第三类从“过滤条件”挪到“活动打标”里去做，列表页只展示标签，不参与核心过滤。这样既避免了筛选逻辑越来越臃肿，也能让后续加活动不碰主流程。

1.2 条件之间的逻辑关系要统一约定

不同维度的过滤条件默认都是 AND 关系，这个不难理解。真正容易翻车的是同一个维度内部的关系，尤其是“多选”的场景。

品牌选了 A 和 B，意思应该是商品品牌属于 A 或 B，也就是“组内 OR”。但价格区间这种就不能随便 OR，一个商品的价格是确定值，min 和 max 是 AND 关系。到了商品属性这种维度，比如内存选了“8G”和“12G”，颜色选了“黑色”和“白色”，那你既不能把它们全塞进一个 IN 里查，也不能简单地把所有条件都 OR 起来。

这个逻辑如果不提前约定好，后端动态 SQL 拼出来一定千奇百怪：有的接口把同名属性多次出现当成集合处理，有的接口直接取最后一个值覆盖前面的，最后结果要么为空，要么查出来一堆不符合条件的商品。我在项目里会用一套统一的规则来约束：所有筛选参数是一个扁平列表，每个参数有明确的类型标记，数值型用 range，枚举型用 multi，布尔型用 flag，后端按类型走不同的条件构造器，而不是写一堆 if-else 去猜前端传过来的是什么。

1.3 数据模型层面：三套方案怎么选

过滤条件背后依赖的数据模型，直接决定了后面查询好不好写。商城项目里常见的有三种做法，我按实际效果排个序。

第一种是宽表冗余，也就是在商品主表或者商品扩展表里，把常用过滤字段单独列出来：品牌 ID、价格、上下架状态、可售库存、类目 ID、几个高频属性。优点是查询逻辑简单，单表 WHERE 就能完成大部分过滤，配合索引性能非常可控。缺点是扩展性一般，想加新属性就要加列，适合属性相对稳定、场景单一的商城。

第二种是EAV（实体-属性-值）表，属性存在行里而不是列里。优点是灵活，想加什么属性就加什么属性，缺点是筛选性能一塌糊涂：你要查“8G 内存 + 黑色 + 128G 存储”的时候，得 JOIN 好几次甚至写一堆 EXISTS 子查询，数据量一上去基本没法看。我现在只有在做后台属性维护功能时才用 EAV，前台筛选绝不直接查它。

第三种是搜索引擎/倒排索引存储，比如 Elasticsearch 或者一些云上的搜索服务。商品数据同步到一个索引里，过滤、排序、聚合都由搜素引擎完成，性能好、扩展性也强，属性随便挂。缺点是需要额外的数据同步、索引维护的基建工作，团队如果没人熟悉这些组件，排查问题也会比较吃力。

从我接触的项目来看，商品量在十万级以下，用宽表冗余加 MySQL 完全够用；商品量到了百万级，或者筛选项特别复杂，再考虑搜索引擎。不要一上来就上重武器，一套 MySQL 方案做到位，前面能撑好几年。

1.4 方案选型背后的“为什么”

“宽表 + MySQL”这个方案的核心思路是：把最常用的过滤字段全部摊平到一张表里，让数据库用索引去快速缩小扫描范围。很多时候慢不是因为数据库不行，而是因为你让数据库做的事太多：一张订单表 JOIN 三张库存表、再 JOIN 两张属性表，过滤条件分散在五张表里，数据库只能先做笛卡尔积再过滤，索引根本用不上。宽表的本质是“空间换时间”，现在磁盘和内存都不贵，但用户的等待时间很贵。

我遇到过一个项目，一开始商品表、SKU 表、属性表都是标准的第三范式设计，列表页查一次要 2 秒多，偶尔还会超时。后来把 filter 字段冗余到主表里，查询降到 30 毫秒以内。之后又有一个新需求要按“发货地”筛选，我们就在主表加了一个 region_code 字段，同步脚本在商品上下架的时候一并更新。这个思路说白了就是：频繁用于筛选的字段，必须放在离查询入口最近的地方。

2. 后端核心实现：动态条件构造与查询模型

2.1 查询参数模型，照这个写不容易错

后端接口在接收过滤条件时，不要用一堆散落的参数名 talk 来 talk 去，最好建一个明确的请求对象。我习惯写成下面这种结构，字段收敛、类型清晰，前端和后端也好对齐。

public class ProductQuery { // 类目筛选：单选，走类目树的叶子节点 private Long categoryId; // 品牌筛选：多选 private List<Long> brandIds; // 价格区间：单位是“分”，避免 double 丢失精度 private Integer minPriceFen; private Integer maxPriceFen; // 是否只显示有货 private Boolean inStockOnly; // 通用商品属性筛选：key 是属性 ID，value 是属性值 ID private Map<Long, List<Long>> attrFilters; // 关键词搜索 private String keyword; // 排序字段和顺序 private String sortField; private String sortOrder; // 分页 private Integer pageNo; private Integer pageSize; }

这个对象有几点是踩过坑之后才确定的。

价格字段必须用“分”而不是“元”，而且用整型而不是浮点型。你在页面上看到的是 199.00 元，但系统内部如果拿 double 做比较，会出现 199.0 和 198.99 这种边界问题，尤其是经过税率、折扣计算之后，浮点误差会被过滤条件放大。我在项目里定过一条规矩：金额一律用整数分存储、传输、比较，前端展示的时候再除以 100 格式化，这样既快又准。

品牌 ID 用 Long 列表而不是逗号拼接的字符串。字符串解析在接口层很麻烦，还要处理空串、重复值、分隔符不统一的问题，直接传 JSON 数组，框架自动绑定，后端拿到的就是一个干净的 List。

属性筛选用Map<Long, List<Long>>而不是把所有属性值 ID 混在一个列表里。区分属性 ID 是决定性的一点：内存“8G”和颜色“黑色”如果不分 key 地混在一起，后端无法区分哪些值属于同一个属性组，动态 SQL 就拼不对。

2.2 动态 SQL 的正确拼法（含代码示例）

后端拿到 ProductQuery 之后，最关键的一步是把对象转成 SQL 的 WHERE 条件。很多初学的人喜欢在 Java 里手拼字符串：

String sql = "select * from product where 1=1 "; if (query.getBrandIds() != null && !query.getBrandIds().isEmpty()) { sql += " and brand_id in (" + String.join(",", query.getBrandIds()) + ")"; }

这种写法最大的问题不是“1=1”丑，而是 SQL 注入风险和类型处理麻烦。项目里应该用 ORM 的动态查询能力，比如 MyBatis 的<where>和<if>标签，让框架来拼，既安全又清晰。

<select id="pageQuery" resultType="ProductVO"> select id, title, price, cover_url, stock_status from product where <where> <if test="query.categoryId != null"> and category_id = #{query.categoryId} </if> <if test="query.brandIds != null and query.brandIds.size() > 0"> and brand_id in <foreach collection="query.brandIds" item="id" open="(" separator="," close=")"> #{id} </foreach> </if> <if test="query.minPriceFen != null"> and price &gt;= #{query.minPriceFen} </if> <if test="query.maxPriceFen != null"> and price &lt;= #{query.maxPriceFen} </if> <if test="query.inStockOnly != null and query.inStockOnly"> and stock_status = 1 </if> </where> order by <choose> <when test="query.sortField == 'price'"> price </when> <when test="query.sortField == 'sales'"> sales_count </when> <otherwise> create_time </otherwise> </choose> <choose> <when test="query.sortOrder == 'desc'"> desc </when> <otherwise> asc </otherwise> </choose> limit #{query.pageNo}, #{query.pageSize} </select>

这里有一个细节很多人没注意：排序字段不能直接拼前端传过来的字符串，必须做白名单映射。不然前端传一个id;drop table product之类的内容，ORM 的#{}参数占位符不会对排序字段生效，因为排序字段通常被当成 SQL 片段拼进去。我见过不止一个团队因为这个地方偷懒，生产环境差点出事。

2.3 多选属性筛选的 SQL 写法（含代码示例）

前面对attrFilters的约束，到了 SQL 这里就能看出作用了。假如用户选了“内存 8G + 颜色 黑色”，正确逻辑是：商品必须有一个属性是 8G，同时另一个属性是黑色，二者是 AND 关系。

如果直接把属性值全部拼进一个 IN，会变成：

and attr_value_id in (101, 202)

这个条件的意思是“商品的某个属性值等于 101 或者等于 202”，结果可能是只有 8G 没有黑色、或者只有黑色没有 8G 的商品也混进来，完全不对。

正确的写法是对每一个属性分组做 EXISTS 子查询：

select id, title, price from product p where p.status = 1 and exists ( select 1 from product_attr pa where pa.product_id = p.id and pa.attr_id = 1001 -- 内存 and pa.attr_value_id = 101 -- 8G ) and exists ( select 1 from product_attr pa2 where pa2.product_id = p.id and pa2.attr_id = 1002 -- 颜色 and pa2.attr_value_id = 202 -- 黑色 )

用 EXISTS 而不是 JOIN，是为了避免一对多关联导致主表结果集膨胀。如果用 JOIN，一个商品有三个属性值，就会变成三行，后面你还要 DISTINCT 去重，性能浪费在无意义的笛卡尔积上。EXISTS 是“半连接”语义，找到一条就停，效果更好。

如果属性不多，也可以考虑把商品的属性冗余成一个 JSON 字段，比如attrs里存[{"attrId":1001,"valueId":101}, ...]，然后用 JSON 函数做包含判断。MySQL 5.7 之后的 JSON_CONTAINS 可以处理部分场景，但复杂组合查询还是不如 EXISTS 直观，而且 JSON 字段上的索引支持有限。我的建议是：属性筛选走独立属性表 + EXISTS，属性展示走 JOIN 查出来在服务层组装，职责分开。

2.4 排序、分页与过滤条件的联动

过滤条件不是孤立的，用户筛选后往往会跟着排序和分页。这里最常见的坑有三个。

第一个坑是排序字段不在索引里。比如你按price排序，但如果 WHERE 条件里的category_id和status已经确定了一个范围，排序字段不在同一组索引里，数据库就要先过滤出结果集，再在内存里 filesort，数据量大时性能下降非常明显。解决思路是组合索引要覆盖“过滤 + 排序”两个需求，比如(category_id, status, price)这类设计，后文第 4 节详细说。

第二个坑是深分页。用户筛完条件，翻到第 100 页，SQL 变成limit 9000, 20，数据库依然要扫描并丢弃前 9000 条记录。百万级数据下这就是灾难。商品列表场景更合适的做法是用“下一页游标”替代页码，比如记住上一页最后一条记录的(price, id)，下一页用where price = ? and id > ? or price < ?的方式继续取，跳过前 N 条的无谓扫描。

第三个坑是分页和过滤条件不同步。前端发请求时，如果当前页是第 5 页，用户又勾选了一个新品牌，此时再传第 5 页就很不合理，应该回到第 1 页重新查。这个逻辑最好由前端在发起新筛选时统一处理，后端接口则要兼容“页码超过总页数”的情况，直接返回空列表，而不是报异常。

3. 前端状态管理与交互细节：筛选体验的胜负手

3.1 状态模型与 URL 同步

后端把条件接收得再规范，前端如果状态管理一塌糊涂，整个筛选功能一样会出问题。

我的建议是筛选状态不要散落在各个组件的useState里，而是集中到一个对象里，并且把这个对象映射到 URL 的 query 参数上。这样有几个直接好处：页面刷新后筛选条件还在，用户可以复制链接分享给同事，浏览器前进后退也能正确恢复状态。

一个比较典型的映射规则是这样：

// 内部统一使用的筛选状态 const filters = { categoryId: 1001, brandIds: [101, 102], minPrice: 19900, maxPrice: 99900, inStockOnly: true, attrs: { 1001: [101], 1002: [105, 108] } }; // 同步到 URL，作为唯一数据源 // list?categoryId=1001&brandIds=101,102&minPrice=19900&maxPrice=99900&inStockOnly=1&attr_1001=101&attr_1002=105,108

在 React 项目里我习惯用路由的 search 参数作为筛选状态的唯一事实来源，组件挂载时从 URL 初始化 filters，用户操作时更新 filters 并 replace 到 URL。组件内部不再维护一份“私有状态”，防止了“URL 变了但组件没感知”“组件状态变了但 URL 是旧的”这类两套状态不同步的经典问题。

在 Vue 项目里思路一样，用vue-router的 query 或者一个全局的 store 管理筛选状态，组件只负责触发动作。

3.2 请求竞态与防抖处理（含代码示例）

筛选面板上最常见的连续操作就是：用户先勾选品牌 A，马上又勾选品牌 B，然后立刻滑动价格区间。如果不加保护，前端会在几百毫秒内发出七八个请求，而且这些请求的返回顺序不可控。

我实际遇到过的情况是：用户先选了价格 100~200 元，系统发出请求 R1；用户马上改成 100~300 元，发出请求 R2。R1 因为查询更慢、后返回，界面先被 R2 的 300 元结果渲染，再被 R1 的 200 元结果覆盖，最终用户看到的列表和他当前选的条件对不上。

处理办法有两个，都要做。

第一个是防抖。用户在筛选面板停下来 300 毫秒后再发起请求，把连续操作合并成一次请求。价格滑块滑动时尤其需要，不然每移动一像素就发一个请求，后端很容易被打爆。

// 简单防抖实现 function useDebounce(fn, delay = 300) { const timerRef = useRef(null); return useCallback((...args) => { if (timerRef.current) clearTimeout(timerRef.current); timerRef.current = setTimeout(() => fn(...args), delay); }, [fn, delay]); } // 触发筛选请求 const loadList = useDebounce((nextFilters) => { fetchList(nextFilters); }, 300); // 用户操作时只更新状态，loadList 自动合并请求 const handleBrandChange = (brandId) => { const nextFilters = updateFilters(filters, { brandIds: toggle(brandId) }); setFilters(nextFilters); loadList(nextFilters); };

第二个是竞态拦截。在真正发请求时，给每次请求生成一个自增序号或者 requestId，只有最后一次请求的返回值才允许渲染。很多项目用 AbortController 取消过期请求，这个也可以，但对 HTTP 请求取消和恢复的处理要谨慎，我更喜欢用序号判断，逻辑最直观。

let requestSeq = 0; async function fetchList(filters) { const seq = ++requestSeq; const res = await api.get('/products', { params: filters }); if (seq === requestSeq) { setList(res.data.list); setTotal(res.data.total); } }

这个if (seq === requestSeq)的判断虽然简单，但能挡掉九成以上的乱序渲染问题，强烈建议在封装列表请求时默认带上。

3.3 重置、联动与模板切换

筛选面板的“重置”按钮，看起来是把所有条件清空，实际上要区分“全局重置”和“单项清除”。

全局重置是回到这个页面的默认状态，比如回到当前类目的默认排序和默认条件；单项清除则是把某一个维度恢复成未选中状态，但不能影响其他维度。我遇到过一个 bug：用户筛选了品牌 A + 价格 100~200 元，清除品牌后，价格条件也神秘消失了，抓了半天发现是前端把所有 filters 对象用同一个引用，清除品牌时直接把整个对象置空了。正确做法是重置时用不可变数据更新，每次操作都生成新的对象，只修改目标字段。

联动是我特别想强调的一个点。联动有两种：一种是类目联动属性模板，用户选了“手机”这个类目，筛选项里出现内存、屏幕尺寸；切换到“笔记本”后，筛选项变成 CPU 型号、显卡。这个可以通过“类目 ID -> 属性模板”的映射表实现，前端展示的每一个筛选项都来自模板配置，而不是硬编码在组件里。

另一种是选项数量联动，即用户选了品牌 A 之后，价格区间各段的可选数量、其他品牌的商品数量，是否要动态更新。实现这个需要后端聚合统计能力，能做，但成本不小。我的建议是列表页首次加载时把各维度的选项计数一次性返回，用户选择某个维度后，其他维度计数可以选择性刷新或保留原数据。不要为了“看起来动态”就让每个过滤选项都发一次统计请求，移动端非常容易卡。

4. 性能优化：索引设计、缓存与慢查询治理

4.1 组合索引设计，不能只靠单列索引

很多新人给过滤字段各自建了单列索引，会觉得“差不多了”。但在多条件过滤场景下，MySQL 一般只能用到其中一个索引，其余字段只能在结果集里重新过滤，尤其当第一个索引选择性不高时，整个查询就会退化。

举一个我优化过的例子。商品主表有千万级数据，最常用的查询是：

select id, title, price from product where category_id = 123 and status = 1 and stock_status = 1 and price between 10000 and 20000 order by price limit 20

最初表上有idx_category、idx_status、idx_price三个单列索引，EXPLAIN 显示只用了idx_category，然后在 100 万行内存里做范围过滤加 filesort，耗时 800 多毫秒。

改成组合索引(category_id, status, stock_status, price)之后，EXPLAIN 的type从ref变成了range，Extra里的Using filesort也消失了，因为 price 本身就在索引里，可以边走索引边排序。查询耗时降到 20 毫秒左右，优化效果非常明显。

这里要记住最左前缀原则：组合索引(a, b, c)有效的情况是查询条件包含 a，最好 a 和 b 都包含，三列全等值（或范围）时最优。如果跳过了 b 直接查 c，那 c 上的索引就没有意义。另外每个查询只能用一个索引，所以设计组合索引时要拿“最高频的查询语句”来对表设计，而不是为每个条件单独建索引。

4.2 深分页与大结果集的替代方案

商品列表的深分页问题，前面提过一次，这里展开讲。传统分页limit offset, size，offset 越大越慢，因为 MySQL 要把前 offset 行都查出来再丢掉。有些团队直接在 SQL 里限制最大页码，比如超过 100 页就拒绝查询，这算是一种妥协；更实用的方案是改成“键集分页”（keyset pagination）。

假设按price desc, id desc排序，前端每次拿到列表后，把最后一条记录的price和id返回给后端，下一次查询带上这两个值：

select id, title, price from product where category_id = 123 and status = 1 and (price < #{lastPrice} or (price = #{lastPrice} and id < #{lastId})) order by price desc, id desc limit 20

这样每页查询都只扫描 20 行左右，完全不受页码影响，用户体验上“加载更多”也比页码翻页更流畅。缺点是不能直接跳转到第 N 页，但商城列表场景里，用户几乎不会精确跳到第 50 页去，这个取舍很划算。

如果商品量到了几百万、几千万，并且过滤条件特别复杂，我会建议把列表查询迁移到搜索引擎里。先用过滤条件和排序条件查出“符合要求的商品 ID 列表”，再用这些 ID 回 MySQL 查详情组装，筛选本身不再碰大表。搜索方案在聚合计数、多条件组合上的效率确实比 MySQL 高一个量级，代价是增加一套数据同步和一致性保障机制。

4.3 缓存和降级策略

筛选面板上那些“品牌选项”“价格区间分段”“属性取值”，本身是相对低频变化的配置数据，每次列表请求都去数据库里面select distinct一遍，纯属浪费。这些维度选项我建议做短 TTL 缓存，比如 5 分钟或者 10 分钟，由后台的配置变更接口主动失效。

真正难的缓存是“筛选后的商品列表”本身。列表数据高度动态，库存一变、商品一下架，缓存里的列表就过期了。我见过两种折中方案：

一种是只缓存“结果 ID 列表”而不是完整页面，TTL 设置 30 秒到 1 分钟。用户筛完条件即使拿到的是缓存 ID，再回源查详情时也会过滤掉已下架商品，至少页面不会出现“已失效”的尴尬。

另一种是对热门类目做预聚合，比如“全部分类-热门品牌”组合的统计提前算好，用户查询只走内存读取。这种方案适合首页、大促会场这类并发极高、数据相对可控的场景。

降级的思路也要留好。如果聚合统计接口压力太大，可以临时关闭“各选项数量展示”，只保留过滤功能；如果搜索引擎出问题，兜底方案是回退到 MySQL 直接查，虽然慢，但保证功能可用。我在项目中专门准备了一个配置开关，按流量、按模块粒度做降级，比等故障了再改代码靠谱得多。

5. 常见问题排查实录与避坑清单

5.1 全量筛选后出现价格“错误”的商品

有次运营反馈，筛选“100~200 元”的商品，列表里出现了一个 0.01 元的商品。排查下来，问题出在前端价格输入框把“元”和“分”搞混了：页面上用户输入 100，前端传给后端的是minPrice=10000，本来没问题；但有一天改版，有人不小心把单位换算代码删了，100 直接传过去变成“100 分”，也就是 1 元，所以 0.01 元商品自然也被查出来了。

这个问题的根源不是某个环节写错了，而是整个链路对“价格单位”没有统一约束。后来我们做了两个措施：第一，接口文档里明确标注minPrice/maxPrice单位为分，并在入参校验里加上限和下限，比如minPrice >= 0 and maxPrice < 100000000，防止异常单位传入；第二，前端所有价格输入框都走同一个格式化工具函数，禁止在组件里直接写value * 100这种裸逻辑。把单位处理收敛到一个函数后，这类问题基本绝迹。

5.2 品牌多选后结果为空，清掉品牌又正常了

另一个典型问题：用户选了品牌 A，再选品牌 B，结果列表为空。单独查 A 或单独查 B 都有数据，组合起来就空，而且空得非常彻底。

排查 SQL 后发现，品牌条件被拼成了brand_id in (101, 102)，这个本身没问题。问题出在请求参数里品牌 ID 的“类型”，前端传过来的是字符串"101,102"，后端框架把它绑定到List<Long>时，只解析出了第一个值101和第二个空值，空值进入 IN 之后变成brand_id in (101, '')，字符串与数字隐式转换后，自然查不出任何结果。

这个案例提醒我两件事：一是 List 类型的参数后端要用@RequestParam List<Long> brandIds或者 JSON 数组来接收，不要用逗号字符串再手动 split，更不要用“第一个值 + 空值”的拼接方式；二是所有筛选参数都要加参数校验，空值、非法类型、超范围值要在入口直接拦截，不要把脏数据扔给数据库。

5.3 筛选后列表总数和筛选项计数对不上

用户经常发现一个现象：页面顶部显示“共 1200 件商品”，但品牌列表里的某个品牌显示只有 5 件，这 5 件加起来远不到 1200。

原因很简单，列表总数和选项计数是两条独立的查询，它们之间没有事务保证。用户在操作的过程中，可能有商品上下架、库存变动，导致两次查询看到的数据不一样。另外如果筛选条件本身前后端解析不一致，比如前端用了一个“宽松”的条件去聚合，列表用“严格”的条件去过滤，数字必然对不上。

完全做“强一致”很难，也不值得。更务实的做法是接受一定程度的误差，但要把误差控制在合理范围：列表总数以列表查询为准，选项计数以独立聚合查询为准，并对选项计数做短暂缓存，比如 30 秒。这样数字虽然可能不是实时精确的，但不会出现“总数少于选项明细”的明显悖论。如果运营要求非常精准，那就只能每次查询都走同一个统一条件构造器，并让计数和列表共用一套查询参数，再把两次查询放进同一个只读副本里执行。

5.4 过滤条件刷新后消失，分享链接无效

移动端商城经常遇到：用户筛选好商品，切到详情页再返回，筛选条件全没了，重新选一遍；复制链接发给同事，打开后也是空列表。

这类问题基本都出在前端没有做 URL 同步，或者做了但与组件生命周期绑定太紧密。我建议把筛选状态提升到路由层，而不是放在列表组件内部。列表组件每次卸载重挂载，都从 URL 解析初始化状态，这样刷新、返回、分享天然就支持了。

如果不想用 URL 承载太多参数，至少要在全局状态里持久化一份，并在页面返回时恢复。有个细节是：进入商品详情页前，不能把筛选状态清了；从详情页返回列表页时，要恢复之前的筛选条件和滚动位置。这个体验做得好不好，直接影响用户的使用粘性。

5.5 避坑清单速查表

写到最后，分享一点个人体会

商城项目的过滤条件，单看功能点很小，但它横向牵连了数据库设计、查询性能、前端状态管理、接口规范、运营配置好几条线。我见过很多项目一开始只把它当“一个列表筛选接口”来做，等到并发上来、需求复杂化之后，再回头补索引、补状态同步、补竞态控制，每一次都改得痛苦。反正下次再让我从零搭一个商城列表页，我会先把过滤条件的字段模型定死、单位约定写进文档、URL 同步机制搭好、组合索引和分页方案在一开始就排进开发计划，而不是等 feature 上线之后靠用户反馈来发现“原来筛选这么难用”。

如果你正在做类似的功能，希望这篇对你少走弯路有帮助；有其他具体场景，也欢迎拿出来一起讨论。