React电商实践：品类页应选独立endpoint还是统一接口过滤？

别选你提到的两种纯方案，最优解是做带品类筛选参数的统一商品查询接口，两种原生方案的问题都很明显：

为什么不建议「单接口返全量、前端自行过滤」 #

这是只适合本地极简demo的写法，完全不具备工程合理性：

• 性能浪费极其严重：练习阶段你可能只加几十上百个测试商品，感知不到问题；一旦商品量涨到上千上万，用户打开分类页要先等全量商品数据传输完成才能看到内容，加载速度会慢到无法接受，平白浪费用户流量和服务器带宽
• 扩展性为0：后续你要加分页、价格排序、库存筛选、关键词搜索功能的时候，总不能把几十万条商品全丢给前端做计算吧？逻辑全堆前端根本跑不起来
• 有数据泄露风险：全量返回相当于把所有商品的定价、库存、甚至未上架的内部测试商品数据全暴露给前端，没有任何安全边界

为什么不建议「每个品类做独立endpoint」 #

这个方案比全量返给前端靠谱，但长期维护成本极高：

• 重复代码太多：加一个新品类就要新写一个接口，比如做食品区要加/food-products、做服饰区要加/clothes-products，哪天要调整商品返回字段（比如加个商品标签字段），你得挨个改所有品类的接口，很容易出漏子
• 适配场景太死板：碰到跨品类的活动页（比如同时展示PC和家居类的折扣商品），前端得调两个接口自己拼数据，平白多一层冗余逻辑

推荐的实现方式 #

就做一个统一的商品列表接口，路径比如/api/products，通过查询参数控制返回内容：

• 传参category=pc时返回PC类商品，传category=home时返回家居类商品，不传category参数时返回全量商品（注意全量也要加分页，绝对不要一次性返回所有数据）
• 后续要加价格区间筛选、销量排序、仅显示在售商品这类需求，直接给这个接口加对应参数就行，逻辑全收敛在后端一处，维护成本极低
• 前端调用也灵活，不管是分类页、搜索页、活动专区页，要什么规则的商品传对应参数就可以，不用记一堆不同的接口路径

要是你刚搭项目想快速跑通流程，临时用前端过滤的方案凑数也没关系，但从一开始按统一带参接口的思路写，也就多写几行参数判断的代码，还能练到正规的接口设计逻辑，比后面写一半再重构省事多了。

内容的提问来源于stack exchange，提问作者Alexandra