企业官网建设流程全解析

开头就直接切入主题，讲讲我在做多公司多门店仓储式超市POS收银系统时踩过的坑和最终落地的整体方案。搞这套系统的难点从来不在扫码收银本身，而在于连锁超市业务的复杂性，多公司、多门店、仓储式库存，每一块拆开都好说，合在一起就容易出问题。

我在实际项目中遇到过最典型的场景：某公司旗下有商超、便利店、餐饮三种业态，分布在多个城市，每个门店又有独立的库存和价格策略，但总部需要实时汇总经营数据，统一管理供应商结算。刚开始用的是市面上的通用收银软件，做着做着发现根本撑不住，不同门店不同税率、不同结算方式、生鲜损耗、仓储整箱拆零，各种需求一上来就乱套。后来干脆自己设计了一套完整的多公司多门店POS收银系统方案，这里把方案思路和核心落地细节完整分享出来。

在展开之前，先说清楚这套方案适合谁看。如果你的需求只是单店小卖部，扫码枪加一个简单的收银软件就够了，没必要看这篇文章。如果你面临的是多公司多门店的连锁经营，或者仓储式超市这种大流量、大库存、复杂促销的场景，那这套方案的设计思路和落地细节可以给你省掉大量试错成本。

我按"业务建模 - 架构设计 - 核心流程 - 实操落坑"这条线完整写，全是实际操作中的经验总结，不搞假大空的PPT架构图，所有内容都是可落地、可运行的方案。

1. 多公司多门店的业务建模，是整个系统的地基

很多技术方案一上来就画架构图，我反而建议先从业务建模开始。系统跑不起来或者跑起来天天报错，八成不是代码问题，而是业务模型没理清楚。

1.1 多公司多门店的数据权限模型

所谓多公司多门店，本质上是数据权限的问题。谁能看到什么数据、谁能改什么价格、谁能查什么报表，这些如果不先在数据模型层面定义清楚，后面做权限控制会非常痛苦。

我的做法是建立三层组织架构：集团 - 公司 - 门店。在这个模型里，集团是最顶层，可以看所有公司的数据；公司是中间层，拥有独立的财务核算和供应商体系；门店是最底层，承载实际的销售和库存。

数据库层面用组织架构表实现多租户隔离，每个业务表都必须携带org_id和组织路径。比如商品表里面会有company_id和store_id，商品既可以是公司级的（所有门店共享），也可以是门店级的（只有某个门店能用）。这个概念我把它叫做"数据归属"，是后续所有权限、价格、库存控制的基础。

权限模型用的是用户 - 角色 - 数据范围三层设计。超级管理员拥有全部数据权限，区域经理可以看多个公司多个门店的数据，门店店长只能看本门店数据。

给商品加数据权限会带来一个好处：总部的采购可以维护公司级商品，门店店长可以维护本店的临时商品。比如某个门店试销一款新品，只需要在门店级录入一次，不会影响其他门店，也不会上报到总部报表里。这个灵活度在做连锁零售时是刚需，否则每次门店想上个新品都要走总部流程，效率极低。

1.2 仓储式超市的商品主数据设计

仓储式超市和普通超市最大的区别在于商品主数据的设计。仓储式超市的商品通常是整箱进、整箱出，也会存在拆零销售，还会有大宗团购。

商品主数据字段我自己总结了一套核心清单：商品编码、条码（EAN/UPC）、品名、规格、箱规（一箱多少件）、保质期管理标志、称重标志、允许拆零标志、默认进价、参考售价、最低售价、会员价、积分规则、条码类型（普通码、店内码、电子秤码）。

这里特别注意店里自己打的店内码。仓储式超市的生鲜、熟食区域，经常需要店内码。店内码的编码规则要自己定义，通常以"02"开头加重量或金额信息，这样扫描枪录入后系统能直接解析出重量和价格。我在某个项目里就见过店内码规则没统一导致扫码出来价格对不上的情况，当时排查了好久才发现是货号长度定义错了。

商品清洗和校验规则也必须在录入环节就做好。比如条码位数校验，国内商品条码一般是13位，如果录入的条码是8位或者12位，系统要主动拦截并提示。还有条码重复检查，同一个条码在不同公司之间必须唯一，否则就会出现A公司商品扫码出来是B公司价格的问题，这在多公司场景下是致命伤。

1.3 价格策略的多维度优先级

仓储式超市价格体系复杂，普通超市一般就是"零售价"和"会员价"两套，仓储式超市往往有阶梯价、批发价、促销价、会员专享价、大宗团购价、临期折扣价。

价格策略的核心是优先级，这个必须在系统设计时定死。我采用的价格优先级从高到低是：单品促销价（限时） > 满减满赠促销分摊价 > 会员专享价 > 大宗批发价（需要审核） > 门店自定义售价 > 公司统一零售价。

注意这里单品促销价要放在最前面，因为你一旦上了促销价，就必须强制覆盖所有其他价格。有些收银系统会把会员价优先级设得特别高，导致促销期间会员扫出来还是促销价，两个优惠叠加变成双重折扣，这在财务上是没法交代的。

价格生效的时间窗口也要设置到位。促销不是"点了生效就生效"，而是要配置预生效时间。比如大促周五晚上8点开始，那么系统在8点之前必须还按原价结算，1秒都不能差。我习惯在价格表里加上valid_from和valid_to字段，查询价格时用当前时间做条件，避免并发情况下价格不一致。

2. 仓库与门店库存联动，仓储式超市的命脉

收银系统表面上是管销售，但底层其实是在动库存。仓储式超市的库存管理有个特殊性：仓库和卖场往往是同一个空间，顾客拿了商品直接去收银台，不像普通超市有独立的仓库和补货流程。

2.1 库存扣减的实时性与异步设计

库存扣减方式上有两种主流方案：实时扣减和异步扣减。实时扣减就是扫码的同时锁定库存，优点是账实同步好，缺点是高并发下性能压力大，促销活动期间经常出现库存超卖或者锁死的情况。

我的方案是异步扣减为主，实时预占为辅。顾客在收银台扫码结算时，系统先把商品加入订单明细，此时只做预占用（pending），并不直接扣库存；订单支付成功后，通过消息队列触发库存扣减任务，真正从库存表里减去数量。

为什么要这样设计？因为现场经常出现顾客扫完了商品但最后不付款走人的情况。如果扫码就扣库存，那顾客把商品放回去之后，库存和实物就对不上了。用预占用加支付后扣减的方式，可以彻底避免这个问题。

库存扣减之后还有一个回补机制。如果订单被取消或者退款，系统要自动回补库存。回补不是简单地把库存加回来，还要校验有效期、批次等维度的回补逻辑，这个在后面仓储批次管理里详细说。

2.2 仓储式超市的批次与效期管理

仓储式超市的退货率集中在生鲜和临期食品上，批次和效期管理因此成了刚需。系统里面不能只存"库存数量100件"，还要细化到"哪一批进的货、哪一天到期、保质期内剩余天数是多少"。

批次管理的核心表设计是：批次表（批次号、商品、生产日期、到期日期、入库数量、剩余数量、库位），销售明细必须关联批次号。收银台扫码时，系统根据当前批次分配策略自动选择一个批次扣减。

效期预警策略分三级：临期预警（到期前30天）、禁售预警（到期前7天）、过期锁定（到期后禁止销售）。这个逻辑必须在后端强制处理。我见过最坑的情况是门店收银系统可以正常扫出过期商品，就是因为效期校验只在前端做了提示，后端没有拦截。

按批次管理的库存，建议在前端界面上给门店员工提供一个"批次调整"功能，允许他们实时录入手工报损、报溢的批次信息。财务对账时，批次级的数据比数量级的数据更加清晰。

2.3 整箱与拆零两种形态的库存换算

仓储式超市里同一个商品经常存在两种库存形态：整箱和拆零，这两个单位之间存在换算关系。比如一箱矿泉水12瓶，箱规就是12，系统里的库存表必须同时记录箱数和瓶数。

我建议所有内部库存统一使用最小单位（单件）作为基础库存单位，展示时再进行箱零转换。这样做的好处是所有进销存报表和财务核销都能统一口径。举例来说，A商品的库存是50箱又8瓶，基础库存就是608瓶，系统会在界面上显示两种格式：箱数50.67箱（保留两位），瓶数608瓶。

收银台扫码的商品条码决定了销售单位。顾客买一整箱，扫码枪扫的是外箱条码；顾客拆零买，扫的是单品条码。订单明细需要记录销售单位以及件数，库存扣减时统一转换成最小单位进行扣减。还有一个细节：拆零商品在扣减时，系统会优先扣减拆零库存，如果拆零库存不足，再从整箱库存中自动拆箱扣减，但拆箱行为需要记录操作日志，防止月底盘点对不上账。

3. 收银核心链路，那些最容易出问题的环节

前面的大多数架构都是在"幕后"，收银系统真正坐在台前的是收银台操作。门店店员一天到晚面对的就是收银界面，如果流程设计不合理，系统再强大也会被骂成废物。这里把POS端的核心流程完整拆解。

3.1 商品扫描、快速录入与手工输入的双通道

仓储式超市的特点是客单价高、单品数多、结账速度必须快，这决定了收银界面不能像传统ERP那样表单化。我设计的POS收银台界面加载全部核心功能，只有四个核心区域：商品明细区、价格计算区、付款方式区、功能按键区。

商品录入有两个通道。第一通道是扫码枪扫描，条码命中后商品自动进明细；第二通道是关键字检索，收银员输入商品拼音首字母或者品名关键词，下拉选择。这两个通道必须做到毫秒级响应。

扫码后有个关键步骤叫"商品匹配确认"。仓储式超市经常有同一个商品多个条码的情况（外箱条码、单品条码、店内码），系统必须能根据条码自动判断出具体的SKU和销售单位，不需要人工二次选择。如果系统无法自动匹配，就弹出一个候选列表让收银员手动选，但这种操作要坚决控制在5%以内，否则结账速度提不上去。

手工录入环节有一个防呆设计：数量默认是1，如果收银员需要修改数量，必须在数量框中输入正确的数字再按回车。不要做成点一下数量框弹出一个计算器，那样键盘操作反而变慢。实际运营下来，收银员最习惯的是直接用键盘敲数字，触摸屏点数效率低很多。

3.2 单结单走、整单结算与挂单机制

仓储式超市有大宗采购客户，也有普通散客。大宗采购客户经常是推着好几辆购物车装满了商品，散客可能只买一盒鸡蛋。如果收银模式一刀切，两种客群都会骂人。

系统必须支持三种结算模式：单结单走、整单结算、挂单处理。

单结单走模式用于大宗采购。每扫一件商品，系统立即计算出当前累计金额，顾客可以直接一件一件付款，也可以累积到一定数量一次性付款。这个模式有一个隐藏需求，就是订单拆分打印，每件商品都要打独立的明细，最后再汇总打印一张总额小票。

整单结算模式是默认模式，适合普通散客。所有商品扫完，统一按当前购物车进行结算。这里要注意促销计算要在整单之间跨商品进行，比如满100减10这种活动，必须整单扫描完成才能算出来。

挂单机制是为高峰期设计的。收银台排长队时，先让前面顾客的购物车整单保存为挂单状态，收银员可以先服务后面的顾客，然后再回来调出挂单继续结算。挂单明细要保存完整的商品列表和预计算金额，调出时可以直接继续收款。

3.3 支付方式多渠道组合：现金、储值卡、银行卡、第三方支付

现在收银系统碰到的支付场景很复杂，一个订单往往不是单一支付方式。顾客可能用会员储值卡扣一部分，现金补一部分，微信再付剩下的。系统必须支持多种支付方式组合结算。

支付渠道抽象成统一接口。我先定义了一个PayChannel的抽象，所有具体支付方式都实现这个接口：现金、银行卡、微信、支付宝、银联云闪付、会员储值卡、优惠券、挂账。

组合支付的核心是结算顺序策略。我建议的固定顺序是：先扣优惠券、再扣会员储值卡余额、然后第三方支付、最后现金。这个顺序可以避免一个尴尬场景：顾客说用现金付，结果现金不够了，最后用第三方支付补差，顺序灵活反而造成对账复杂。

每笔支付流水要有独立的流水号。不仅是整单有订单号，每个支付方式都要有对应的支付流水号。现金有现金流水号，微信有微信支付流水号，储值卡有储值卡消费流水号。财务对账时，报表必须能够展示"订单 - 支付流水 - 第三方对账单"三者的勾稽关系。

3.4 小票模板的动态配置与打印控制

小票是收银系统最容易被人忽略但又最容易出问题的模块。多公司多门店的场景下，不同公司的小票格式还不一样，有的是58mm热敏小票，有的需要80mm。

我建议把POS小票做成动态模板配置，每个公司在后台维护自己的小票模板。模板字段包括：公司抬头、门店名称、收银机编号、收银员、订单号、商品明细、金额明细、支付明细、二维码/条形码、促销提示语、售后说明。

小票打印有个性能坑，很多系统的打印速度慢是因为把整张小票生成一张图片再打，这样慢而且容易乱码。正确做法是走ESC/POS指令流式打印，把小票内容逐行发送给打印机，边走边打，速度会快很多。58mm和80mm打印机的ESC指令不一样，模板配置时就要区分打印机型号。

4. 系统落地实操，从零到上线的关键细节

方案设计是一回事，实际落地是另一回事。这套POS系统在某个项目里从需求确定到试点门店上线用了三个月，中间经历了大量调试。把常见问题和实操过程中的关键细节记录下来，对准备实施这类系统的人应该有价值。

4.1 硬件选型与网络环境的现实约束

收银机的硬件选型直接影响运行稳定性。仓储式超市客流量大，收银机往往是早上8点开机一直到晚上10点，中间不能死机重启。

我给这套方案定的硬件标配是：收银主机一台（低功耗CPU、8G内存、128G固态硬盘，Windows系统）、72mm热敏打印机一台、扫码枪一把、顾客显示屏一台、钱箱一个。

这里多说一句，扫码枪建议买USB即插即用的，不要买蓝牙的。蓝牙确实是方便，但现场经常出现电池没电、配对掉线的情况，USB插上就能用，而且价格便宜，坏了换新成本低。键盘口的扫码枪理论上不用驱动，但老式键盘口接入Win10经常有兼容问题，不建议。

网络环境要多说一嘴，因为仓储式超市的面积大，收银台分布在卖场出口一圈，走的是WiFi还是有线网，体验差别巨大。我的建议是收银台位置必须部署有线网络，无线只作为备用，因为高峰期顾客集中结账时一旦WiFi不稳定，收银直接中断，投诉立刻爆发。

4.2 数据同步与离线兜底机制

POS系统最怕的是什么？网络断了，单子结不了。卖场可以断网，但不能断收银，否则店长直接疯掉。

这里必须要做离线收银方案。收银机本地要维护一份商品最小数据集，包含条码、品名、售价、促销信息，每天营业前自动同步到收银机本地数据库。当网络中断时，收银机自动切换为离线模式，商品可以正常扫描、正常结算、小票正常打印，所有订单先保存到本地。

恢复网络后，系统自动把离线订单批量上传到主服务器。这里有个细节：离线订单上传时，服务器必须重新进行库存扣减和促销校验，如果有异常（比如促销已结束、库存不足）要单独标记，不能篡改原有的销售数据。

离线切换逻辑不要做成手动按钮，要做成自动检测。每次收银操作前，系统ping一下服务器心跳接口，通就正常模式，不通就切换离线，基本无感知。如果做成手动切换，门店员工根本想不起来切，等发现问题时已经积压了十几单。

4.3 对账结算、报表统计与财务稽核

系统上线后，财务最关心的就是对账。仓库式超市的日结流程是这样的：门店当天的销售订单、支付流水、退款单、促销优惠券核销数据，在门店级先做一遍日结汇总；然后上传总部，总部做公司级汇总；所有数据在当天24点后锁定，不允许修改历史订单。

具体到支付对账，第三方支付（微信、支付宝）每天都会生成对账单，系统需要将这些对账单与系统内的支付流水做自动比对，差异数据（比如金额不一致、单边账）必须自动标记出来，由财务人工处理。

报表系统这块要有日、周、月三个时间维度的报表中心，日有销售日报、品类销售排行、门店客流、客单价、连带率；周有同比环比、Top10、Bottom10；月有毛利分析、坪效分析、人效分析。报表中心的数据全部实时从订单数据仓库计算，不允许各门店上报Excel再汇总，否则数据口径都不一样没法看。

4.4 会员储值卡与促销活动在收银端的联动

仓储式超市的会员储值卡非常普遍。会员充1000送100，然后门店所有活动都以会员价为基准。储值卡的逻辑并不复杂：卡账户表、充值流水表、消费流水表，核心是两件事：余额实时更新和支持部分支付。

储值卡支付时，系统先按应付金额尝试从储值卡全额扣除，如果余额不足就扣一部分、剩下的走其他支付方式，这个逻辑需要写清楚。

会员的积分规则是按实付金额来的，也就是优惠后实际收到的钱，而不是订单原价。比如原价100元的商品，促销减了10元，实付90元，积分按90元累计。积分累计规则可以按门店、按品类、按商品分别配置，灵活度很高。

促销在收银端有个常见坑：促销规则计算完总价后，由于四舍五入的精度问题，多条优惠叠加起来可能比原价还要贵0.01元，这在POS里是不允许出现的。我的做法是系统计算促销时逐级保留，最后一级调整到分位，所有优惠分摊后汇总金额必须等于订单原价减去总优惠。

5. 技术方案：架构决策与实现要点

前面讲的都是业务侧的东西，最后把这套系统的技术架构重点梳理一下，方便想自己开发或者让研发团队落地的朋友有个抓手。我不敢说这套架构是完美的，但它在多公司多门店仓储式超市这个业务场景下是经过验证的。

5.1 单体应用优先，别再随手拆微服务

这些年很多人一聊系统就说微服务，但在POS收银场景下，我强烈建议优先做单体应用。POS系统是典型的内部业务系统，用户量不大（门店收银员、店长、财务、运营），但业务逻辑非常复杂，单体应用反而更好维护。

我这个方案里的推荐技术栈是：后端Java Spring Boot单体应用、MySQL数据库、Redis缓存、RabbitMQ消息队列，前端用Vue3加Element Plus做管理后台、收银端用React Native或Flutter做PDA/收银机App。全部部署在内网或专有云上，不建议直接依赖某一家公有云的专有组件。

单体应用不是说完全不分模块，而是模块之间通过代码层面的包边界做隔离，而不是拆成独立的进程服务。比如商品模块、库存模块、价格模块、订单模块是同一个进程里的不同package，数据库层面可以分库分表，但应用部署是一套。

如果你预测未来业务复杂度还会上升，单体应用也不是死路。后续可以做模块化拆分，把订单、商品这种核心模块独立成服务，但一开始就上微服务会显著增加开发、部署、运维的复杂度，对于大部分连锁零售场景其实是过度设计。

5.2 关键数据表与核心状态机

系统核心表大概有：公司表、门店表、用户表、角色权限表、商品表、商品条码表、价格表、促销表、库存表、库存批次表、订单表、订单明细表、支付流水表、退款表、储值卡账户表、储值卡流水表、日结表。

订单状态机是核心，它是后续所有业务逻辑的基础。订单状态分为：待支付、支付中、已支付、已退款、部分退款、已取消、已挂单。订单生成之后不会马上进入已支付状态，而是先待支付，收到支付回调后进入已支付，如果超时未支付则自动取消。

注意一点：挂单状态的订单不能直接删除。门店如果清掉挂单，必须记录是哪个收银员在什么时间清除的，防止财务上说不清楚。

5.3 数据同步最终一致性与防重复支付

POS收银和总部服务器之间的数据要保持最终一致性。这里说的最终一致性，意思是门店本地操作和总部数据之间允许有短暂的时间差，但不能无限拉长，不能出现门店说已支付、总部说未收到的情况。

支付这块需要重点关注防重复支付。用户扫码支付时，如果支付回调因为网络问题延迟了，用户又扫了一次，系统必须通过幂等机制保证同一个订单不会被扣两次款。实现上可以用订单号加支付渠道作为唯一索引，重复支付回调直接拒绝。

离线订单的上传要做增量同步机制，每次上传记录last_sync_id，只有新产生的订单才会上传，不要每次把全部订单重新传一遍。本地还要记录一个确认机制：上传成功多少条、失败多少条，失败的要定时重试，实在失败要告警通知管理员。

5.4 数据安全与权限审计

门店收银员流动性大，权限必须做得细。我的习惯是权限最小化原则：门店收银员只能操作收银、查看本店实时销售、提交日结，不能调整价格、不能查看毛利、不能导出数据、不能查看其他门店的报表。

敏感操作全部留痕。退款、改价、挂单、清除挂单、日结修改、库存调整这些操作，在系统里必须有专门的审计日志。审计日志不是简单地记录"谁做了什么"，还要记录操作前后的数据快照，这样才能在盘点差异或者财务稽核时追查问题。

收银机本地数据加密存储。数据库文件、日志文件必须加密，防止门店设备被盗后数据泄露。密码策略上，收银员账号要定期强制定期更换密码，离职人员的账号必须第一时间禁用，这是一个简单但经常被忽略的安全漏洞。

6. 实施中的几个惨痛教训，写出来让你们少走弯路

做这套系统最大的感受是：技术方案本身占成功的一半不到，另一半全在实施运营的细节里。这里把所有实际过程中踩过的坑精简出来，希望后来的朋友不要重复交学费。

6.1 条码管理混乱引发的价格错乱

出现过一次具体事故：A公司的一个商品条码录入正确，但B公司给同一个商品录入了不同的内部货号，同一个条码在两个公司的系统里对应了不同的SKU。门店收银台扫描时，如果数据源配置没做好隔离，就直接扫到了另一个公司的价格。

解决方案是在条码表创建的时候就做全局唯一约束，条码同时关联企业维度。这个在所有环境（测试环境、生产环境）都必须生效，否则就是给自己埋雷。

6.2 促销叠加导致负毛利

有些促销设计出来之后财务一看毛利变负了，这种情况往往不是促销设置错了，而是促销与促销之间产生了叠加效果，而配置人员没有意识到。比如"全场满100减20"叠加"生鲜满50减10"，买100元生鲜最后只需要付70元，已经低于成本价了。

促销叠加控制必须在促销配置后台提前做规则引擎校验，计算同一商品参与的所有促销，计算最终毛利，如果毛利低于警戒线则给出警告。宁愿让运营人员看到警告后再确认，也不要事后财务来找你扯皮。

6.3 高峰期并发瞬间把数据库打爆

有个门店做开业促销时，收银台同时结账的订单数达到了每分钟300单，数据库连接直接被耗尽，收银台交替出现卡顿和系统等待。

后来做了三件事缓解：数据库连接池动态调整、Redis缓存商品价格和库存预占、订单写入改为批量插入合并。还有就是把MySQL的innodb_buffer_pool_size调大，以及把读多写少的业务（比如商品查询、价格查询）全部切到Redis缓存，数据库压力顿时下来不少。

6.4 门店日结与总部数据不同步

门店日结后，财务发现总部汇总的销售数据和门店上报的数据差了十几笔。原因在于门店日结时只上传了订单汇总金额，没有上传每笔订单的明细。后来改为明细上传，总部根据明细重新汇总，差异就消除了。

日结逻辑要这样：门店端生成日结单，包含订单总数、应收总额、实收总额、退款总额、优惠总额；总部接收后不信任门店汇总，逐单比对明细，有不一致的自动标记。这个机制才是数据准确的最终保障。

7. 多门店与仓储式超市场景下的扩展思考

系统上线稳定运行之后，如果你的生意持续增长，可以考虑一些扩展功能。这些不是必选，但提前在方案里预埋好扩展点，后面做起来会顺手很多。

多公司多门店的基础模型可以直接扩展出加盟商管理。每个加盟商相当于一个独立的公司组织，总部作为品牌方，给加盟商分配商品池和价格规则，加盟商自主管理门店。数据权限模型只要在组织架构里增加一级，就可以支撑加盟商体系，这是单体应用也做得到的。

仓储式超市的库存模型可以扩展出"前置仓"的概念。门店的仓库或者卖场后场，可以单独设置为一个"不出售但可调拨"的库存组织，商品在门店和前置仓之间流动是内部调拨单，不需要走销售流程，库存和财务都更干净。

会员体系层面可以扩展出跨门店通用的电子券。电子券在总部发放，用户在A门店领取，可以在B门店核销。核销数据必须实时回流总部，这个对多门店场景非常重要。

最后补充一个很多老板会在意的东西：这套系统能不能做连锁加盟模式的"店中店"？答案是如果你的组织架构模型允许一个物理门店挂多个公司主体的话，完全可以。比如同一个商场里，A公司开超市，B公司开餐饮柜台，但共用同一个收银硬件和网络，系统里只要把物理门店和经营公司分开建模就行。

实际做下来之后我最大的感触是：POS收银系统不是越复杂越好，而是要贴合业务本身。多公司多门店仓储式超市的复杂在于组织多、商品杂、促销狠、条码乱，搞清楚了业务模型，系统设计自然就有章法。希望这份方案和实战经验对正在做同样事情的人有帮助，哪怕只是帮你避掉一个坑，这篇文章也算值了。