组合商品把多个 SKU 作为套装销售，例如主商品加配件、体验包或固定套餐。它能简化选购，但也带来库存、定价、拆单、退款和售后的复杂性。Telegram 商城组合商品机器人应明确套装结构与库存口径，不能只把多个名称拼成一个商品。
什么是组合商品
组合商品由一个对外展示的套装和多个真实组件 SKU 组成。用户购买一次，系统按配置扣减各组件库存并生成可追踪订单明细。固定套装、可选套装和加价购的规则不同，应分别建模。
组合商品适合哪些场景
适合设备加配件、课程加资料、服务套餐、试用组合和节日礼包。若组件价格、交付方式或退款规则差异很大，强行组合会增加售后成本，产品设计前应先确认业务可行性。
套装数据模型需要哪些字段
保存套装 ID、名称、状态、展示图、组件列表、每项数量、是否可替换、组合价格、有效期和渠道范围。组件引用真实 SKU，不复制库存数量。所有规则应带版本，历史订单保留购买时快照。
固定套装与自选套装怎样区分
固定套装的组件和数量不可修改；自选套装允许在候选组中选择规定数量；加价购则依赖主商品。前端应逐步引导并实时显示已选组件、差价和库存，避免用户在结算时才发现条件不满足。
组合价格如何计算
可以使用固定套装价、组件总价减固定金额或按比例优惠。金额使用整数最小单位或高精度类型。页面要展示总价、优惠和适用条件，不使用虚假原价或保证最低价等误导表述。
库存应该怎样扣减
可售套装数量由所有必选组件的可售数量和每套用量共同决定。下单时在同一事务或可靠库存服务中锁定各组件，任一组件不足则整套失败。不能只维护一个独立“套装库存”而不与组件同步。
购物车校验流程
加入购物车时验证套装有效期、用户资格和初步库存，结算时重新计算价格与库存。若组件变化，要明确提示并让用户确认。客户端传来的价格和组件列表不能作为可信依据。
订单如何拆分与保留关系
订单保存套装主行和组件子行。主行用于展示和优惠，子行用于库存、发货和售后。仓库或供应商不同的组件可拆成履约子单，但必须保留套装关联，避免重复计算优惠。
部分发货怎样通知用户
若允许组件分批发货，订单页显示各组件状态和物流信息。若不允许，需等全部齐备再发货。不要把部分发货显示成整单完成，异常缺货应提供等待、替换或取消选项。
退款和退货如何分摊
整套退款按实际支付金额处理；部分退货需按预先定义的优惠分摊规则计算，防止用户保留优惠组件却退掉主要商品。规则在购买前说明，复杂争议进入人工审核，原订单与退款流水不得覆盖。
优惠券能否与套装叠加
明确优惠券作用于套装主行、指定组件还是整单。系统统一计算顺序并记录每项优惠来源。不能让前端自行叠加，也要防止同一优惠在拆单后重复使用。
组件替换怎样控制
自选套装可在限定候选组中替换，替换后重新校验差价和库存。已支付订单的替换需要审核并记录前后组件。仓库操作人员不能在无授权情况下用其他商品代替。
后台需要哪些功能
后台支持创建套装、组件分组、价格规则、渠道、有效期和上下架，预览可售数量与潜在缺货组件。大批量修改、价格变更和组件替换需权限与审计，历史版本不可随意删除。
性能与缓存如何设计
商品展示可缓存套装配置，但结算和库存扣减必须读取权威数据。组件库存变化后使相关套装缓存失效。一个组件可能属于多个套装，需维护反向关联以准确刷新。
隐私、安全与合规
订单只收集履约所需信息，支付与地址数据按最小权限访问。组合优惠、退款和库存规则应透明，符合消费者保护要求。批量营销需用户同意并提供退订，不能通过机器人私信骚扰。
与商城模块怎样配合
商品与订单基础可参考Telegram商城机器人开发，购物车计算可结合购物车、库存与优惠。盘点差异可接入库存盘点机器人，促销规则可参考优惠码机器人。
开发前需求清单
- 固定、自选或加价购套装类型；
- 组件 SKU、数量与替换规则；
- 组合价格和优惠叠加顺序；
- 库存锁定、拆单和发货方式；
- 部分退货与金额分摊规则；
- 后台权限、版本和审计要求；
- 营销通知与消费者合规要求。
如何评估定制开发
开发量取决于套装类型、SKU 数量、库存系统、优惠规则和售后流程。可整理商品结构、订单接口和退款规则，通过 Telegram 联系 SOSBOT评估。功能和报价应在组件及履约边界确认后确定。
发表回复