企业官网建设流程全解析

这两年接过不少电商类项目，但真正让我觉得"跟普通的商品销售压根不是一回事"的，还是这套家禽商城销售系统。甲方是本地一家规模不小的养殖企业，线下有批发档口和直营门店，线上想扩展零售和批量采购渠道。一开始我也觉得，电商系统不就是商品、购物车、订单、支付那套标准流程，换一类商品而已。可真把需求聊细了才发现，家禽这个品类几乎把电商系统里所有"标准化假设"都打破了：活禽怎么计价、宰杀后重量怎么算、同一只鸡拆成不同SKU库存怎么管、发货时怎么能证明这批货有检疫合格证。这篇文章就把我们从需求调研、系统设计到落地部署的核心经验完整拆一遍，给准备做农产品、活体类、非标品商城的朋友一个参考。

先说结论：家禽商城销售系统本身并不复杂，复杂的是你如何把一个"非标、易损、强监管、随行就市"的品类，硬塞进一套原本为"标品、固定价、常规物流"设计的电商逻辑里。做之前不把这个想清楚，后续每个环节都会很痛苦。

1. 项目定位与整体设计思路

1.1 家禽销售场景和普通电商的四个核心差异

家禽类商品在电商系统里和标准工业品有四个明显的不同点，这四个点基本决定了整个系统的设计走向。

第一是商品形态多样。同一只土鸡，可以按活禽卖（用户买回去自己宰杀或委托宰杀），也可以按宰杀净膛卖（去毛去内脏的冷鲜鸡），还能拆分成鸡胸、鸡腿、鸡翅这类分割品，或者加工成熟食。这些不同的形态在系统里是多个独立商品，但源头库存都是同一批活鸡。这个关系如果不在商品模型里梳理清楚，后面库存统计会乱套。

第二是计价方式特殊。标准化商品是固定单价乘数量，家禽行业则是"按只卖"和"按斤卖"并存。按只卖比较简单，体现为某个规格区间的固定价（比如2到2.5斤的活土鸡定价88元一只）；按斤卖则麻烦得多，用户下单时只能按预估重量计算金额，等到实际称重后再多退少补。系统必须支持这种"预结算＋尾差调整"的订单模式。

第三是履约链路长且非标。一单买了活鸡和鸡蛋，活鸡可能需要从养殖场现抓、现宰、现打包，鸡蛋则从仓库直接分拣发货，两者时效和物流方式完全不同。这意味着订单需要支持拆单，不同的明细行走不同的发货流程。

第四是强监管要求。活禽交易涉及动物检疫，每批出栏的活禽必须附带检疫合格证明。系统在订单详情、快递面单或随货单据中要能关联批次检疫信息，否则零售端一旦被抽检，拿不出溯源凭证就很麻烦。

这四点叠加，决定了我们不能直接拿一套开源商城二开了事，而是要把商品、库存、订单、履约这四个核心域单独重新设计。

1.2 系统角色划分与技术选型考量

这套系统的使用角色比标准电商多两级：除了普通消费者（C端用户）和平台运营（商城管理员），还有养殖场的出栏计划员、分拣宰杀车间工人、配送司机，以及批发渠道的VIP客户。所以系统实际上由四个端组成：

• 用户端：微信小程序为主，辅以H5页面，承担商品浏览、下单、支付、订单跟踪、售后申请。
• 商家管理后台：PC端Web管理界面，负责商品上下架、价格调整、订单审核、拆单、称重回写、发货、售后处理。
• 养殖场端：简化版Web/移动页面，用于同步出栏计划、上报批次检疫信息、确认可售库存。
• 配送端：司机使用的移动端应用，查看配送任务、确认送达、登记异常（如活禽运输途中损耗）。

技术选型上，后端采用的是Spring Boot + MySQL + Redis这套主流组合，管理后台前端用Vue，用户端和配送端基于uni-app打包成小程序和App。说实话这套技术栈没什么惊喜，选它的核心原因就三条：团队熟练度最高、社区生态完善、Java系在订单和财务相关场景下的稳健性不用多虑。选型上真正值得讲的是两点。

一点是用Redis做库存预占和价格缓存。家禽价格波动快，可能早上的批发价和下午就不一样，我们把实时价格放在Redis里，后台改价即时生效，避免用户读到脏数据。另一点是预留与养殖场ERP的对接接口。很多养殖企业已经有自己的进销存系统，商城系统如果和市场库存脱节，就会出现网上显示有货但实际这批鸡还没出栏的尴尬。所以我们在设计阶段就定义了出栏计划同步、批次库存回传两个接口契约，先做成可配置的开关，有系统就自动对接，没有系统就先人工录入。

2. 商品与库存管理模块：给一只鸡建模的难点

2.1 商品SPU与SKU的设计思路

家禽商品的建模，建议分三层：品类层、SPU层、SKU层。

品类层是固定的分类树，比如"活禽-鸡-土鸡-放养土鸡"，"禽蛋-鸡蛋-土鸡蛋-散装/礼盒"，"冷鲜分割-鸡-鸡胸肉"这样。这一层主要是为了前端导航和后端报表汇总。

SPU（Standard Product Unit，标准产品单元）对应的是一个具体的品种，比如"散养土鸡""三黄鸡""乌鸡""白鸭""老鹅"。消费者在商品列表页看到的通常就是SPU。

关键是SKU（Stock Keeping Unit，库存保有单位），家禽商品的SKU不能只按"规格"来定，而需要组合多个维度：销售方式（活禽/宰杀净膛/分割/熟食）、重量区间（1.5-2斤、2-2.5斤、2.5-3斤）、包装形式（普通袋/冰鲜盒/礼盒）。比如同一只"散养土鸡"，可以延伸出六个SKU：活禽2-2.5斤、净膛整鸡1.5-2斤、半只切块500克、土鸡腿250克、土鸡翅200克、整鸡礼盒。每个SKU有独立的条码、图片、价格和库存。

这里必须想清楚一个逻辑：SKU和养殖批次之间是多对多的关系。一个批次的活鸡，可以转化为多个SKU的库存；一个SKU的库存，也可能来自多个批次（比如分割品会把不同批次的鸡胸肉混在一起）。所以库存表不能只挂在SKU下面，还得关联批次维度。

2.2 库存联动、批次管理与数量口径

库存模块是这个系统里最容易出bug的地方。我们在实际操作中采用了"三级库存"模型。

第一级是养殖场活禽存栏，这代表物理上真实存在的活鸡数量。它来自出栏计划，每天更新，数据录入由养殖场端完成（或者对接ERP自动同步）。第二级是可售库存，即可用于线上销售的数量。因为一部分活禽要留给线下批发档口，还要预留损耗，所以可售库存并不等于存栏数，而是存栏数乘以一个可售比例（通常由运营手工设置）。第三级是SKU库存，即可售库存经过"拆解转化"后分配到每个SKU的数量。

一个具体的例子：某批次有500只土鸡可售。运营计划其中300只按活禽整只卖，100只送去宰杀做净膛整鸡，50只做分割装盒，50只预留礼盒。那么系统里就自动生成300的活禽SKU库存，100的净膛鸡库存（每只净膛鸡对应1只活禽投入），分割品则按出肉率换算（比如1只3斤的活鸡，净膛后约1.8斤，切块后能做3份500克）。这个转化过程需要后台有一个"加工转化配置"，而不是让运营人工在各个SKU上分别录库存，那一定会对不上账。

批次属性也必须做进系统：每批活禽有进场日期、出栏日期、产地、质检单号、检疫证编号。商品详情页可以展示"出栏批次"信息，消费者下单时能看到这只鸡是哪个批次、哪天出栏、检疫编号是什么，信任感会强很多。临期批次（超过预定出栏周期）系统要自动置为不可售，提醒人工确认。

2.3 价格策略与重量计价实现

家禽价格不是京东那种"固定价＋满减"，更像股票行情：随行就市。运营后台每天可能要修改好几次价格。所以我们把价格模型设计成：基础价（默认日常价）、临时调整价（覆盖基础价）、批发客户协议价（针对VIP企业客户单独维护）、促销价（限时活动用），取价优先级是促销价大于协议价大于临时调整价大于基础价。价格变更通过Redis广播通知，用户在商品列表页拿到的始终是最新价。

重量计价是个必须正面解决的需求。处理方案是这样的：按只卖的SKU，系统设定一个标准净含量区间（比如2-2.5斤），用户下单时按该区间的中间值或固定一口价结算；按斤卖的SKU，商品页展示一个参考价（每斤单价），用户拍下时按预估重量（如3斤）冻结金额。等到订单进入宰杀和称重环节，工人录入实际重量，系统自动重新计算金额，差额原路退回或补扣。

这里面有个细节：活禽运输过程中会有"掉膘"现象，一只鸡称重时2.3斤，送到用户手里可能只有2.25斤，前72小时的断食运输还会让重量进一步下降。所以系统里设置了"合理损耗阈值"（通常3%到5%），实际重量在预估重量的合理范围内波动时不触发退款，超出范围才启动差值结算。这个规则上线前一定要和甲方确认清楚，否则用户投诉率会非常高。

3. 订单与配送履约：从下单到活禽上门

3.1 订单状态机设计：比标准电商多出的几个状态

家禽订单的状态流转比标准电商复杂，因为中间插入了"排单、宰杀、称重、检疫绑定"这几个环节。

我们最终落地的状态机如下：

• 待支付：用户提交订单但未付款，超过30分钟自动关闭。
• 已支付（待排单）：付款成功，订单进入运营队列。这个状态下运营要确认库存真实可用，周末和节假日订单量大时，往往要按产能排期。系统支持"预约送达时间"，用户可以选第二天某个时段收货，所以待排单状态会和预约时间绑定。
• 待宰杀：订单已排入生产计划，车间开始抓鸡、宰杀、净膛。这个状态在系统里是真正触发库存扣减的节点，不是在用户支付时扣减，因为活禽在支付到宰杀之间还有死亡、掉膘等不确定性。
• 待发货（待称重）：宰杀完成，工人录入实际重量，系统自动完成金额尾差调整，生成发货单和检疫信息绑定记录。
• 配送中：司机在配送端接单，扫描发货单，系统更新物流轨迹。这里要记录两个时间：预计送达时间和实际送达时间，后面对配送时效统计和客诉判定都有用。
• 已完成：司机确认送达，用户点击确认收货（或超时自动确认）。
• 售后中：涵盖拒收、重量异常、品质问题、活禽死亡等场景，需要走独立的售后审核流程。

注意这里面没有"退款/关闭"混在一起。在待宰杀之前，用户可申请取消订单并全额退款；进入待宰杀之后，原则上不再支持直接取消，只能走售后流程，因为鸡已经宰了。这种规则要在用户下单页明确提示，避免纠纷。

3.2 拆单与多渠道履约

一个订单里有活鸡、冷鲜分割品、鸡蛋礼盒的情况非常常见，三种商品的履约方式完全不同。我们做法是在支付成功后根据SKU属性自动拆单，生成多个"履约单"。

• 活禽履约单：由养殖场处理，现抓活禽，装入专用运输笼，通过同城活禽配送专线送达，用户收货后自行宰杀或联系代宰。部分城市对活禽交易限制较严，这个流程需要按当地政策决定是否开放。
• 冷鲜/冷冻履约单：由加工车间处理，宰杀、净膛、打包、贴标签，走冷链物流（同城冷藏车或第三方冷链快递）送达。
• 蛋品/标品履约单：由仓库处理，常规打包后走普通快递或同城配送。

拆单后，每个履约单有独立的物流单号、发货状态和售后入口。用户在订单详情页能看到"该订单包含3个包裹，分别由不同仓库发出"的提示，避免看到不完整的物流轨迹产生误解。

3.3 检疫信息绑定与售后溯源

这个环节是家禽商城区别于普通生鲜电商的重点，也是合规底线。每一批出栏活禽，养殖场都会拿到当地动物卫生监督机构出具的《动物检疫合格证明》，证明上载明货主、产品名称、数量、产地、目的地和检疫日期。

系统在设计上把检疫信息和批次绑定，存放在quarantine_info表中。当订单进入"待发货"状态时，系统根据该批次自动把检疫证明编号、证明图片关联到履约单上。用户在订单详情页可以看到："本批土鸡检疫合格证明编号：XXXX，发证日期：XXXX，产地：XXXX。"配送司机打印随货单时，检疫证明也一并打印，随货配送。

售后溯源场景同样依赖这套数据。用户投诉"收到鸡品质有问题"，运营在售后后台输入订单号，就能看到这单对应哪个批次、哪张检疫证、什么时间宰杀、哪位称重员经手。如果同一批次出现多条品质投诉，系统会自动告警，提醒品控排查该批次是否存在健康隐患。这种"批次到订单再到个人"的链路闭环，是行业客户最看重的功能。

4. 数据库设计与并发处理细节

4.1 核心数据表结构与关系梳理

数据库是整个系统的基础，我挑几张最关键的表说明设计思路。

商品表product：存SPU基本信息，包括品类ID、名称、主图、描述、状态。一张SPU对应多条SKU记录，存放在sku表中，字段包括规格参数、重量区间、计价方式（按只/按斤）、单价、包装方式、状态。

库存表inventory不直接挂在SKU上，而是采用inventory_batch（批次库存）和inventory_sku（SKU库存）两张表配合。批次库存按"养殖批次"记录活禽数量，SKU库存则记录该批次转化为某个SKU后的可售数量。举个例子，批次B001有500只活禽，其中300只分配给了SKU"A1活禽2-2.5斤"，100只转化给SKU"A2净膛整鸡"，50只转化给SKU"A3切块"。当A2卖出10份，对应的批次活禽消耗也要核减，这个联动关系通过事务保证一致性。

订单相关表按电商标准设计：orders（订单主表）、order_item（订单明细）、fulfillment（履约单）、fulfillment_item（履约单明细）、delivery_info（配送信息）。订单主表存客户信息、总金额、状态；明细表存SKU、数量、单价、重量预估值；履约单和订单明细是多对多关系，一个履约单可以包含多个订单的明细（合单发货）。

此外还有几个业务特有表：weigh_record（称重记录，关联履约单号和实际重量）、price_adjustment（价格与尾差调整记录）、quarantine_info（批次检疫信息）、slaughter_batch（宰杀批次，关联活禽批次和加工时间）。

4.2 防止超卖与库存扣减的时机选择

家禽系统防超卖，难度比标准电商高，因为库存扣减的时点比较尴尬——不能支付时扣，也不能发货时不管。

我们的方案是"两步锁库存"。用户提交订单时，系统在Redis中执行预占操作：DECR inventory_sku_stock:{skuId}，如果返回值为负数，说明库存不足，下单失败。这个预占动作同时会设置一个TTL，与订单超时时间一致（30分钟）。如果用户未支付，订单关闭，Redis执行INCR回补库存。

用户支付成功后，进入待宰杀状态，此时在数据库层面正式扣减SKU库存，同时扣减对应的活禽批次库存，使用UPDATE inventory_sku_stock SET stock = stock - #{num} WHERE sku_id = #{skuId} AND stock >= #{num}这样的带条件更新语句，配合受影响行数判断，保证不会扣成负数。

这里有个细节值得提醒：重量计价的商品，预占库存时不能按"件数"扣，而应该按预估重量占用。比如一个SKU总库存是200斤，用户下单预估3斤，那Redis预占就是扣3，数据库正式扣减也扣3。到了称重环节发现实际是3.2斤，系统要做两件事：在库存中追加扣减0.2斤（如果该用户订单是最后一份，就可能出现库存不足的情况），同时更新订单关联的重量值。所以称重环节的操作顺序必须是：先检查余额库存是否足够消化超量部分，再确认超量部分的金额扣款，最后更新订单状态。

4.3 报表统计与经营分析维度

甲方毕竟是养殖企业，光把线上商城跑通不够，他们需要数据辅助生产决策。所以系统里内置了一套经营报表，覆盖几个核心维度：

• 日/周/月销售趋势：按品类汇总销售金额和数量，和养殖场出栏计划对比，判断哪些品种存在滞销风险。
• 批次售罄率：按养殖批次统计售出比例，低于预期值的批次要加大促销力度。
• 客户复购分析：统计用户在一定周期内的复购率，区分散户和批发客户，针对性设计会员权益。
• 损耗分析：统计称重环节实际重量和预估重量的偏差分布，定位哪些品种掉膘严重，辅助调整商品预估单价。

报表模块技术上不复杂，重要的是数据口径要和业务对齐。比如"销售额"是按下单金额算还是按称重后的最终结算金额算？我们最终按最终结算金额作为财务报表口径，按下单金额作为运营趋势口径，两者都保留，在报表页标注清楚。

5. 实操过程记录：从关键接口到联调部署

5.1 下单接口的库存预占实现

分享一段下单接口的核心逻辑，用伪代码说明流程，这是整个系统里最容易写错的地方：

@Transactional public String createOrder(CreateOrderRequest req) { // 1. 校验商品状态和价格（价格从Redis读取最新价） Sku sku = skuService.getSkuById(req.getSkuId()); if (sku.getStatus() != 1) { throw new BizException("商品已下架"); } BigDecimal unitPrice = priceService.getCurrentPrice(sku.getId(), req.getCustomerId()); // 2. 预占库存（Redis扣减） long remain = stockClient.preoccupyInventory(sku.getId(), req.getEstimatedWeight(), 30 * 60); if (remain < 0) { throw new BizException("库存不足"); } // 3. 创建订单主表和明细表 Order order = new Order(); order.setOrderNo(OrderNoGenerator.generate(OrderTypeEnum.NORMAL)); order.setCustomerId(req.getCustomerId()); order.setTotalAmount(unitPrice.multiply(req.getEstimatedWeight())); order.setStatus(OrderStatusEnum.PENDING_PAYMENT); orderMapper.insert(order); OrderItem item = new OrderItem(); item.setOrderId(order.getId()); item.setSkuId(sku.getId()); item.setEstimatedWeight(req.getEstimatedWeight()); item.setUnitPrice(unitPrice); orderItemMapper.insert(item); // 4. 写入待支付状态记录，设置30分钟过期 orderExpireService.scheduleCloseOrder(order.getOrderNo(), 30 * 60 * 1000); return order.getOrderNo(); }

执行这段时间序里最关键的坑是第2步和第5步之间：如果创建订单数据库事务失败，Redis里的库存预占必须回补。这里要用try-catch，在catch里调用stockClient.releaseInventory()，并且回补操作要保证幂等（同一个订单号不能重复回补）。我们当时因为这个疏忽线上出现过几次"扣了库存但订单没生成"的故障，后来给回补接口加了基于订单号去重的机制。

5.2 称重回写与金额尾差处理

称重环节是车间工人用蓝牙电子秤录入的，程序里要处理"预估重量vs实际重量"的差异。核心逻辑如下：

public void handleWeighComplete(Long fulfillmentId, BigDecimal actualWeight) { Fulfillment fulfillment = fulfillmentMapper.selectById(fulfillmentId); BigDecimal estimatedWeight = fulfillment.getEstimatedWeight(); // 计算差异比例，若超过合理损耗阈值则触发多退少补 BigDecimal diffRatio = actualWeight.subtract(estimatedWeight) .abs().divide(estimatedWeight, 4, RoundingMode.HALF_UP); if (diffRatio.compareTo(new BigDecimal("0.05")) > 0) { // 实际重量比预估重量轻5%以上或重5%以上，触发补差/退款 if (actualWeight.compareTo(estimatedWeight) > 0) { // 需要补差价，生成待支付补差单，用户确认收货前支付 createSupplementOrder(fulfillment.getId(), actualWeight.subtract(estimatedWeight) .multiply(fulfillment.getUnitPrice())); } else { // 需要退款，原路退回 refundService.refundToOriginalChannel( fulfillment.getPayOrderId(), estimatedWeight.subtract(actualWeight) .multiply(fulfillment.getUnitPrice())); } } // 更新称重记录和订单明细中的实际重量 weighRecordMapper.insert(record); }

这段逻辑里有两个注意点。一是"补差价"的处理方式：如果用户买到的东西实际重量比预估重了，而且是活禽（用户已经拿走宰杀了），没有理由拒付，所以我们设计为生成一张补差单，下次进小程序时支付，或者从用户的预存款余额里扣。这比直接发起二次扣款温和得多。二是尾差结算必须在称重当天完成，不能拖到第二周，否则财务对账会乱。我们做了个定时任务，每晚扫描当天称重但未完成尾差结算的履约单，自动推送提醒。

5.3 前后端联调与测试要点

这类系统的联调重点不在接口字段对不对，而在状态流转是否符合业务时序。我们当时列出过一张测试清单，把最容易出问题的场景都覆盖到了：

• 并发下单测试：用压测工具模拟50个用户同时抢最后10只活禽，验证数据库层不会超卖。
• 超时关单测试：用户下单不付款，等待30分钟，验证Redis库存回补、订单状态自动置为关闭。
• 称重尾差测试：分别模拟实际重量轻5%以内、轻5%以上、重5%以上三种情况，验证退款和补差价流程。
• 活禽运输异常测试：司机在配送端登记"活禽死亡"，系统自动触发售后流程，生成赔付单。
• 多门店/多批次商品混购测试：同一个订单包含来自不同批次、不同加工车间的多个SKU，验证拆单逻辑正确。

测试阶段发现的多数bug都集中在库存回补、尾差计算精度、拆单后金额分摊这三块。建议大家在开发排期里给测试留足时间，这类系统的业务规则多，不是简单跑通CRUD就能上线的。

6. 常见问题与排查技巧实录

6.1 典型问题速查表

把实际运行中遇到的几个高频问题和对应的处理思路整理成一个速查表，方便后续维护同学快速定位。

6.2 独家避坑经验分享

系统上线这半年，有几个坑是踩过之后才真正理解怎么处理的，写出来给各位提个醒。

第一，订单编号不要只按时间戳造。我们在订单号里加了业务类型位和批次信息位，比如S开头是零售单，B开头是批发单，后接两位数是出栏批次年份。这样运营在Excel里导出对账时，看一眼订单号就知道是什么业务、大概什么时候的货，排查问题省很多事。

第二，活禽的运输损耗一定要在商品页明确告知。很多用户第一次在网上买活鸡，以为送到手就是三斤活蹦乱跳的，结果路上掉膘了、断食了、甚至轻微应激反应，立刻给差评。我们后来在商品详情页加了一段"活禽配送说明"，写明宰杀前会充分停食静养、运输过程可能出现少量重量自然损耗、收货后请及时处理等内容，差评率明显降下来了。

第三，要给运营留一个"人工强制修改"的开关。家禽行业太活了，系统规则再严谨也难免遇到特殊场景，比如用户下单前沟通好要一只5斤的大公鸡，但抓的时候只剩4.6斤的了，运营需要手动调整订单重量和金额。如果系统不给这个口子，运营每次都要走售后流程，效率极低。我建议在订单详情页加一个"运营备注"和"重量调整"权限，操作留痕，方便审计。

第四，节假日产能预判功能非常有必要。春节前半个月，活禽订单量能翻五倍，养殖场宰杀能力和配送车辆都是固定的。如果系统没有任何预判能力，运营就只能靠经验接单，接多了做不出来，接少了又损失收入。后来我们加了一个"产能日历"页签，运营提前设置每日最大接单量，超过后系统自动提示用户"该时段已约满"，从源头控制接单量，体验比下了单再通知延期好得多。

我个人在实际操作中最深的体会是：这类农产品商城系统，技术从来不是最难的，最难的是把业务语义翻译成系统逻辑。你写出的每行代码、设计的每张表，背后都对应着一个养殖户或消费者的真实场景。如果你手头也在做类似的非标品类电商项目，建议先把业务规则梳理成一张流程图，逐条标注系统应该在哪个环节做什么，和业务方反复确认过再动手写代码，后面返工的几率会小很多。当然，如果已经做进去了，遇到称重尾差、拆单、性能这些坎，可以对照这篇文章找找思路。这套系统的核心逻辑不限于家禽，牛肉、羊肉、海鲜这类品类都适用，关键就是抓住"非标品"背后的确定性——把每一环的状态流转和数据处理都做到有据可循。