商品选型模块：从候选集合到明确选择
商品选型模块帮助顾客把一组候选缩小为一个可以继续了解或购买的选择。它不是单纯的商品卡网格，也不是把全部规格塞进一张表，而是把候选集合、决策维度、当前选择状态和下一步行动连成一条路径。
商品选型 = 候选集合 × 决策维度 × 选择状态 × 下一步行动
先确定顾客在选择什么
选型对象可以是商品、型号、配置、套餐或具体变体。页面必须保持对象层级一致：不能一列比较商品系列，另一列却比较某个颜色变体；价格、库存和媒体随变体变化时，也不能继续显示另一个变体的状态。
开始设计前先回答：
- 候选从哪里来，是否完整并且仍可购买；
- 顾客最先用什么条件排除不合适的选项；
- 哪些维度适用于所有候选，哪些只适用于部分商品；
- 选择之后进入详情、配置还是直接购买；
- 缺少资料、售罄或不可用于当前地区时怎样表达。
筛选、比较和推荐承担不同任务
| 方法 | 回答的问题 | 适用条件 | 不应代替 |
|---|---|---|---|
| 分类或标签 | 候选大致属于哪一组 | 顾客已有明确入口或用途 | 具体差异说明 |
| 筛选 | 哪些候选满足硬条件 | 条件可从可靠数据计算 | 商家的主观推荐 |
| 排序 | 先看哪些候选 | 排序口径对全部候选成立 | 适合度判断 |
| 比较 | 候选在共同维度上有何差异 | 维度、单位和条件一致 | 无限规格罗列 |
| 推荐 | 根据哪些输入建议哪个候选 | 规则、输入和限制可解释 | 隐藏商业偏好 |
同一个选型流程可以先按硬条件筛选，再用少量关键维度比较。推荐标签必须说明依据；如果只是主推商品，应明确写成促销或编辑推荐，不能伪装成计算结果。
一个可复用模块需要的输入
| 输入 | 最低要求 |
|---|---|
| 候选身份 | 稳定名称、链接和可区分的商品或变体标识 |
| 决策维度 | 名称、值、单位、适用条件和未知值处理 |
| 当前状态 | 已选筛选、排序、比较对象和高亮项 |
| 交易状态 | 当前价格、可售性、市场和变体条件 |
| 行动 | 查看详情、加入比较、选择配置或购买 |
营销说明可以帮助理解差异，但价格、库存、变体和购买资格应从当前资源或平台状态读取，不复制成长期维护的静态文字。
数量变化时怎样退化
- 没有候选：说明当前条件没有结果，保留清除或调整条件的入口；
- 一个候选：直接解释适用性和限制，不保留假的比较界面；
- 少量候选：卡片、选项切换或小型比较表通常足够；
- 候选很多：先筛选和分组，再允许选择少量对象进入详细比较；
- 数据缺失：写明未知或不适用，不用空白、破折号或默认值制造相同假象。
在移动端把比较表改成卡片时，每个值仍需携带字段名称。仅靠颜色、列位置或“最佳”徽章传达差异，会让比较结果难以核查。
无障碍与性能
筛选控件使用带可见标签的原生表单元素；已选条件可以逐项移除，移除按钮的名称要说明移除哪一个条件。筛选或排序更新后，以可感知的方式告知结果数量，焦点留在用户正在操作的控件上，不随刷新跳回页首。比较表遵循 Comparison 的表头与小屏要求。
候选较多时分页或按需加载媒体。连续调整筛选条件时取消过期请求，避免较早的结果覆盖较新的条件；价格和库存以最新一次读取为准，不在页面脚本中长期缓存。
与页面和平台实现的关系
选型模块可以出现在首页、集合页、系列页、商品页和活动页。页面只决定模块所处语境；候选身份、判断维度和选择状态仍由模块维护。
映射到 Shopify 时，先确定选择单位是 Product 还是 Variant。商品与变体关系见商品与变体，筛选和比较的界面形式见Comparison。模板、Section、Block 或浏览器脚本只是实现载体，不能反向决定顾客应按哪些维度选择。
验证一次选型流程
用三类任务检查：知道硬条件的顾客能否快速排除不合适选项；只知道用途的顾客能否理解推荐依据；已经锁定两个候选的顾客能否找到决定性差异。随后更换地区、变体和可售状态，确认价格、媒体、行动按钮与当前选择保持一致。
记录顾客输入、候选集合、被排除原因、最终选择和未解决问题。点击率或转化变化只有在比较条件和实际结果完整时才能归因，不能由模块上线本身推断。