股海求生直接把一套带地址自提、预售团购、多人成团的农产品小程序，硬生生当成“通用商城”来搭，项目做到一半基本就要返工。
我第一次接“SpringBoot地区特色农产品团购平台 小程序”这个需求时，原型评审上大家的第一反应也是：商品列表、购物车、订单、微信支付、后台管理，照着标准电商模板改一改不就完了？等到整理业务细节才发现，农产品团购跟标品电商的差别不是“换几个字段”能搞定的。规格怎么定、今日可售量怎么约束、成团条件如何触发、自提点如何履约，这些才是决定系统能不能真正用起来的关键。
这篇文章我按自己的实操过程来梳理，覆盖 Spring Boot 后端、微信小程序端、后台任务、上线后的坑。适合准备做农产品电商、社区团购、产地直发类小程序的同学参考，也适合给客户做定制开发时提前避雷。
1. 先别急着搭工程：这轮需求里的农产品属性才是真正的主线
很多开发团队一拿到需求就开建项目，但农产品团购最需要先花时间统一的，其实是需求模型。领域模型没想清楚，后面写的代码全是补丁。
1.1 非标商品如何定义可购买单位
农产品不是可乐，不是一卷卫生纸。它没有一个厂家给的“标准条码”，同样是一箱苹果，不同产地、不同大小、不同成熟度，价格可能差出一倍。标准电商里的SPU/SKU模型能用，但要改造成更适合农产品的形态。
我做这套系统时，商品主数据只维护“这是什么产品”，真正卖的是“份”——比如砂糖橘5斤装、土鸡蛋30枚装、腊肉礼盒2斤装。每份具体重量允许有±10%的浮动，这是农业行业本身的客观情况。如果硬要像工业品那样做到每个单位重量一致，供应商做不到，你也别硬逼。
所以在数据库里，我不建议只设计一张商品表就开卖，会让运营非常痛苦。
- 商品基础层：维护品名、图片、产地、介绍、供应单位，比如“阳光玫瑰葡萄”“山地放养土鸡”。
- 规格层：一个商品可以有多个销售规格，比如“5斤家庭装”“10斤礼盒装”。
- 场次层：同一规格在不同时间段可能做不同的价格，或限量售卖，必须挂到独立的场次活动表。
这个分层以前很多人不在意，遇到客户问“为什么不能把今天的果子挪到明天的团里卖”时才反应过来，库存和价格都应该跟着“场次”走，而不是跟着商品跑。
1.2 “团购”到底是商城拼团还是预售集中采购
从字面上说，地区特色农产品团购平台，尤其面向本地社区或城区消费者，通常有两种模式：
一种是“预售集中采购”。农民今天摘多少货，就开多少个预售名额，卖完即止；用户先下单付款，达到一定起送量后，隔天采摘、分拣、配送或自提。这种模式让农户没有库存压力，也避免损耗。
另一种是“多人拼团”。用户发起一个团，需要拉足够的人参团，成团后才发货，不成团自动退款。好处是增加传播，坏处是用户下单到最终成团之间有一段等待期，售后压力大。
我在第一版里没有强行把两种揉在一起，而是通过一个“活动类型”字段区分。一个场次可以配置成“总量售完即成团”，也可以配置成“达到最低人数成团”。底层逻辑接近，用户端虽然体验不同，后台任务和状态机却是同一套。
如果你一开始就把两种模式写成两套代码，后面维护会非常累。
1.3 自提与快递，决定了下单页要早做区分
社区农产品团购大多走“到点自提”，用户在自己小区门口、驿站、团长家里取货。长途特产则走快递，或者区域代理商集中配送。这个小细节看着不起眼，但对下单流程影响特别大。
自提需要维护提货点表，需要用户选择提货点，后台还要能够导出按自提点分组的分拣单；快递则需要有完整的收货人信息，有物流单号回填。如果同一个场次里既有自提也有快递，订单表和配送计划表就要设计得足够灵活，不能写死只有一个收货地址字段。
我通常建议第一版就把“配送方式”作为订单主表的独立字段，并在下单页根据当前场次的默认配送范围自动带出。这样运营在创建场次时就能选择是“仅自提”“仅快递”还是“都支持”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 后端技术选型与工程结构，别被 Spring Boot 3 的新版本带偏
Spring Boot 是这套系统比较稳妥的后端选择。但“用哪个版本”这个问题，比想象中更容易出问题。我看到很多刚起步的团队直接选了 Spring Boot 3.x + JDK17，然后被老牌工具链整得焦头烂额。
2.1 JDK8 + Spring Boot 2.7 还是 JDK17 + Spring Boot 3.x
先放一个不容易后悔的方案：如果客户没有明确要求新版本特性，或者团队对 Spring 生态没有长期维护经验，建议先选 Spring Boot 2.7.x + JDK8。
原因比较实际：
- 很多做农业信息化的公司，客户手里的服务器还是几年前的配置，预装的 JDK 往往是 8。
- Spring Boot 2.7 是 2.x 的最后一个大版本，社区仍有很多项目依赖基于它维护。
- 老牌生成工具比如代码生成器、部分低代码平台、便宜的短信服务商 SDK，很多是基于 JDK8 写的，放到 Boot3 下会出现包名不兼容或者 javax/jakarta 命名空间冲突。
如果非要用 Spring Boot 3.x，就需要接受 javax.* 全面改成 jakarta.*。比如引入参数校验时，代码里不能再写 javax.validation，要写 jakarta.validation。Redis、MyBatis、MQ 这些中间件如果版本太老，也要一并升级。
我自己的建议是：新项目，无历史包袱，团队 JDK 都比较熟，选 Boot 3.2+ 没毛病；但如果你接的是一个要给客户长期维护、需要控制部署成本的项目，Boot 2.7 会省很多事。
2.2 工程目录划分与模块职责
小程序后端不要把所有代码堆到一个包下面。农产品团购平台涉及用户端、商家运营端、定时任务、微信对接，至少按以下边界拆一下：
text复制farm-group-api/
├── farm-common/ # 通用返回结构、异常、工具类
├── farm-admin/ # 运营后台接口，给管理员/团长用
├── farm-user/ # 小程序 C 端接口
├── farm-job/ # 定时任务：关单、成团检查、退款
├── farm-wx/ # 微信登录、支付、订阅消息封装
每块之间通过服务接口调用，领域对象不要互相透传。特别是微信相关的逻辑，抽到 farm-wx 里单独维护比较好。微信支付签名、回调验签、解密手机号这类代码夹杂在各业务 Service 中，后面排查问题会很难受。
Spring Boot 项目我建议保持传统 package by feature 的做法，按 controller/service/mapper/entity 分包即可，不