选择 Shopify 捆绑销售方案时，先定义组合模型和履约要求，再看应用列表。对固定套装或 multipack，Shopify Bundles 是官方第一方免费应用且当前可用于所有订阅套餐；但“客户自选组合”、订阅、复杂折扣、POS、ERP 拆单或特殊库存可能需要其他方案。工具数量不是评估质量。
先写清楚组合模型
| 模型 | 客户体验 | 核心数据问题 |
|---|---|---|
| 固定套装 | 预先确定组件 | 组件库存、价格分摊 |
| multipack | 同一商品多件 | 数量与单位价格 |
| 自选组合 | 客户选择组件 | 选择规则、最低数量、缺货 |
| 虚拟组合 | 前台成套、后台拆行 | 订单与仓库映射 |
| 订阅组合 | 周期性履约 | 合约、替换、续费库存 |
然后确认：组件是否单独销售、套装是否需要独立 SKU、库存以谁为准、折扣如何分摊、退货按套还是按件、市场价格和税如何处理、数据如何进入仓库与财务。没有这些答案，任何插件演示都可能看起来合适。
用测试店比较方案
不要直接在正式主题安装多款应用。复制主题或使用开发环境，建立同一组测试 SKU，对每个候选执行：缺货组件、变体切换、折扣叠加、礼品卡、退款、部分履约、多币种、移动端和快速结账。记录应用对主题文件、app blocks、脚本、订单行和卸载后的影响。
Shopify Bundles 的优势是第一方、固定组合路径清晰；但官方文档也列出销售渠道、订阅、部分操作和组合结构的限制。第三方应用可能覆盖更多模型，却会增加费用、脚本、数据锁定和支持依赖。比较 Shopify 真实成本 时，应包含配置、测试、升级和退出成本。
SEO 与 GEO 不应复制组件描述
套装页面需要说明适合谁、包含什么、各组件如何协同、规格和兼容性、库存/配送/退货边界。不要把几个商品描述拼在一起。结构化事实要与实际订单组件一致，FAQ 应回答能否替换、是否单独包装、缺货如何处理。可结合 产品页内容模型 完成验收。
采购前最后做一次退出演练
在测试店创建套装、下单、部分履约、退一个组件，再停用候选应用。检查商品是否变成普通商品、订单历史能否解释、库存是否恢复、主题是否残留代码、分析事件是否改变。询问供应商数据导出、故障支持、API/权限、更新公告和商店规模限制，并把回答写入决策记录。
最终选择可以是 Shopify Bundles、第三方应用、定制应用或暂不做套装。只有业务模型、数据和履约都被验证，才进入正式店小范围发布；先选工具再强迫运营适配，通常会把限制转化为人工补单。
FAQ
Shopify Bundles 是否免费？
Shopify 当前将其作为第一方免费应用提供；功能与限制应以上线时官方文档为准。
所有套餐都能使用吗？
当前官方文档说明可用于所有 Shopify 订阅套餐，但具体组合能力并不因此相同。
套装缺货由哪个库存决定？
应以组件可售库存和组合规则计算，并通过真实缺货测试确认应用行为。
捆绑应用会提高客单价吗？
不能保证。组合价值、价格、商品相关性、展示和流量共同决定结果。
选择应用最重要的退出问题是什么？
卸载后商品、模板、订单历史和组件映射是否仍可理解，以及能否安全回到普通商品流程。