简介这是基于 Java 的农村电子商务系统设计与实现的完整学位论文电子版面向计算机相关专业毕业生、Java 开发者及农业信息化研究者。资源以 O2O 模式为主线将 PC 端与电子货柜终端相结合围绕 Spring、SpringMVC、MyBatis、Shiro 等主流技术栈展开涵盖选题背景、关键技术对比、需求分析、数据库设计、分层架构及前台后台功能实现并介绍了在县域超市、零售店测试运营的实际情况可助力读者掌握电商系统开发流程与论文写作结构。压缩包内为 1 个 PDF 文件整体大小 11.39MB内容完整、排版清晰便于阅读与打印。目前已有 758 人学习使用适合系统设计类课题参考及农村电商项目研发借鉴。1. 用 Java 做农村电子商务系统先想清楚它和城市电商差在哪用 Java 把农村电子商务系统从零跑通比想象中难的不是商城下单那五分钟而是商品怎么按斤卖、订单能不能送到村、超时订单谁来收尾。这个题目看起来是“给县城做个淘宝”实际上主角不是前台页面而是商品规格、配送规则、订单状态机这三个业务模块。它也是很多 Java 课程设计、研究生毕设项目以及 Java 面试题里常被拿出来问“你怎么设计”的一类系统。这篇笔记从需求拆分讲到 Spring Boot 落地再到部署验证照着走你能在本地跑通一个可以演示完整闭环的农村电商单体应用。2. 需求与系统设计先拆清三大角色、订单流转和表结构边界2.1 用户角色与订单流转买家、卖家、运营后台的数据闭环做这类系统我习惯先跟产品经理把角色清单过一遍而不是急着打开 IDEA 建工程。农村电商里有三类人行为模式差别很大买家要的是“下单快、能看到什么时候送到”卖家要的是“上架简单、订单别漏、结算清楚”运营要的是“哪个村的订单没人接、哪家的商品违规下架”。如果直接用城市电商那种“普通用户 管理员”两级角色后面做订单分配、配送批次、卖家结算的时候代码里会到处塞 if 判断越改越乱。角色和权限我建议落地成一张表字段包括 user_id、user_type、seller_id可选。user_type 用 1-买家、2-卖家、3-运营来区分运营后台接口做方法级权限校验卖家只能操作自己的商品和订单。这样登录后Controller 里通过当前登录用户的 user_type 决定能请求哪些接口而不是给每个用户配一串菜单权限那对这个小体量系统来说太重。订单流转要在一开始就定义清楚。我一般先画一张状态表把每个状态的前置条件和后续动作写出来再动手建表。农村电商跟城市电商比多出来的节点主要是“待卖家接单”和“待分配配送”这两个。因为卖货的可能是个合作社不是随时盯着电脑的客服订单付款后得先由卖家确认能不能发货再由运营安排配送批次。这张表我列给你们状态名状态值谁触发后续动作待付款10买家提交订单超时30分钟自动取消待卖家接单20买家完成支付卖家确认接单或拒单待发货30卖家确认接单卖家称重打包并标记发货配送中40运营分配配送批次司机/自提点确认送达待自提50配送到自提点买家到点提货并确认已完成60买家确认收货触发卖家结算已取消70任意一方取消释放库存这张表的顺序就是订单模块的开发顺序。跟产品确认需求时只要这张表双方都认可后面写状态机枚举就不会反复返工。我见过有人把状态字段直接写成 String 存在数据库里“已付款”“已付”“支付完成”三种写法混着来这种项目早晚要翻车。2.2 技术选型为什么 Spring Boot MyBatis-Plus 比 SSH 更适合这个场景十年前做这个题目常见方案是 SSH也就是 Struts Spring Hibernate页面用 JSP 写。现在再这么干光是维护 JSP 里的标签和 Struts 的配置文件就要耗掉一半时间。我现在的选型很固定Spring Boot MyBatis-Plus数据库 MySQL前端用服务端模板加少量 Vue。理由有三条。第一农村电商的 SQL 比普通 CRUD 复杂。商品按多规格拆分库存订单按状态统计配送范围按行政区划编码匹配这些用 Hibernate 的 HQL 写会非常别扭最后往往还是得落到 native SQL。MyBatis-Plus 直接把单表 CRUD 和分页封装好复杂查询自己写 XML两边都舒服。第二开发效率差太多。SSH 时代配一个事务要写一堆 XMLSpring Boot 里加个 Transactional 注解就完事实体类用 Lombok 省掉 getter/setter代码量能少三分之一。第三部署简单一个可执行 jar 就能跑对只懂一点服务器的运营来说几乎没有上手成本。前端这块我提供个参考选型商品列表页、购物车、订单列表用 Thymeleaf 渲染首屏用户点击“立即购买”选规格时用 Vue 做交互。不要一上来就搞前后端分离那意味着你要同时维护 Vue 工程、接口文档、跨域配置对这个体量的项目是负担。等服务端页面真的撑不住了再把页面拆出去商品和订单接口已经在后端写好了不影响。2.3 模块划分与表结构设计商品、订单、库存、配送的落地边界模块按业务切分不按页面切分。我一般拆成五个中心用户中心、商品中心、订单中心、配送中心、运营后台。每个中心只允许通过 Service 方法被别人调用Controller 只做参数接收和结果封装。这样开发时几个人各负责一个中心互相不踩对方的表后面如果要把配送中心独立成服务也只要把 Service 包一层接口就能拆。核心表我建议按这个清单来建用户表 sys_user卖家信息表 seller_info商品表 goods商品规格表 goods_sku订单表 order_info订单明细表 order_item收货地址表 user_address配送区域表 delivery_region配送批次表 delivery_batch。其中最容易设计错的是把商品和规格混在一张表里。举个例子同一个“土鸡蛋”有 30 枚装和 60 枚装这是同一个商品的两个规格两个规格的价格、库存、图片都可能不同。如果当成两个商品前台搜索会出现两条内容几乎一样的结果卖家上架时也要重复造一堆数据。下面这段建表语句是 goods 表和 order_info 表的核心字段够你启动项目用后续再按业务加字段CREATE TABLE goods ( id bigint NOT NULL AUTO_INCREMENT COMMENT 商品ID, seller_id bigint NOT NULL COMMENT 卖家ID, goods_name varchar(255) NOT NULL COMMENT 商品名称, main_image varchar(255) DEFAULT NULL COMMENT 主图路径, category_id int DEFAULT NULL COMMENT 类目ID, min_price decimal(10,2) DEFAULT NULL COMMENT 最低起售价格, status tinyint NOT NULL DEFAULT 0 COMMENT 0下架 1上架, version int NOT NULL DEFAULT 0 COMMENT 乐观锁版本号, deleted tinyint NOT NULL DEFAULT 0 COMMENT 逻辑删除 0正常 1删除, create_time datetime DEFAULT NULL COMMENT 创建时间, update_time datetime DEFAULT NULL COMMENT 更新时间, PRIMARY KEY (id), KEY idx_seller_status (seller_id,status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品主表; CREATE TABLE order_info ( id bigint NOT NULL AUTO_INCREMENT COMMENT 订单ID, order_no varchar(32) NOT NULL COMMENT 订单号, buyer_id bigint NOT NULL COMMENT 买家ID, seller_id bigint NOT NULL COMMENT 卖家ID, total_amount decimal(10,2) NOT NULL COMMENT 订单总金额, status tinyint NOT NULL DEFAULT 10 COMMENT 订单状态 10待付款, delivery_fee decimal(10,2) DEFAULT 0.00 COMMENT 配送费, receiver_name varchar(50) DEFAULT NULL COMMENT 收货人, receiver_phone varchar(20) DEFAULT NULL COMMENT 联系电话, receiver_region_code varchar(12) DEFAULT NULL COMMENT 收货地区编码, receiver_address varchar(255) DEFAULT NULL COMMENT 详细地址, create_time datetime DEFAULT NULL COMMENT 下单时间, pay_time datetime DEFAULT NULL COMMENT 支付时间, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_status_time (status,create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单主表;两个表的设计要点goods 表要建 seller_id 和 status 的联合索引因为运营后台最常见的查询是“某个卖家的所有上架商品”order_info 表要建 status 和 create_time 的联合索引因为超时关单任务每分钟都要按这个条件扫表。字段类型上有两个硬性约定金额一律 decimal(10,2)不能用 float 或 double状态一律 tinyint 并配状态枚举禁止在代码里散落魔法数字。逻辑删除用 deleted 字段统一管理MyBatis-Plus 里配好全局逻辑删除配置后查询会自动带上 deleted 0不用每个 SQL 手写。3. 用 Spring Boot MyBatis-Plus 搭骨架从依赖配置到第一个分页接口3.1 初始化项目与依赖最小可运行的 pom.xml 与配置文件工程我建议建在 JDK 8 或 JDK 11 上Spring Boot 版本选 2.7.x这两个搭配最稳。不要一上来图新鲜用 Spring Boot 3很多老教程里javax.servlet包在 3.x 里迁到了jakarta.servlet照抄会直接编译报错光是排这个坑就够折腾半天。下面这个 pom.xml 是跑通本项目的最小依赖集parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.2/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependenciespom 里两个版本是固定的mybatis-plus-boot-starter 用 3.5.3.2对 Spring Boot 2.7 兼容性最好mysql-connector-j 在 2.7 里由父工程管理版本不要手写版本号否则可能与 Boot 内置的数据库初始化逻辑冲突。spring-boot-starter-web 同时引入 Spring MVC 和内嵌 Tomcat不需要再单独部署 Tomcat。lombok 标 optional 是为了打入 jar 时排除它运行时本来也用不到它。配置文件的重点是数据源和 MyBatis-Plus。下面这段 application.yml 是我在项目启动时最先写的三件套server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/rural_shop?useUnicodetruecharacterEncodingutf8allowPublicKeyRetrievaltrueuseSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0连接串里那五六个参数是我踩过坑后固定下来的useUnicodetrue 和 characterEncodingutf8 解决中文乱码serverTimezoneAsia/Shanghai 解决新版驱动报时区异常allowPublicKeyRetrievaltrue 解决 MySQL 8 用 caching_sha2_password 插件时第一次连接握手失败useSSLfalse 避免本地环境 SSL 握手警告。map-underscore-to-camel-case 打开后数据库的 seller_id 自动映射到实体类的 sellerId不用每个字段写注解。log-impl 配置成 StdOutImpl开发时控制台能看到完整 SQL方便排查上线前记得删掉这行否则 SQL 全打到日志里。3.2 实体类与 MyBatis-Plus 自动建表从 Java 实体直接生成建表 SQL项目里我习惯“实体类先行”也就是根据实体类生成创建表的 SQL 语句。MyBatis-Plus 没有现成的实体类转 DDL 功能但可以自己写一个小工具通过反射读取实体类字段和注解拼出 CREATE TABLE 语句。这样做的价值在于实体类就是表结构的唯一事实来源不会出现 Java 代码和数据库表结构不同步的问题。Data TableName(goods) public class Goods { TableId(type IdType.AUTO) private Long id; private Long sellerId; private String goodsName; private BigDecimal minPrice; private Integer status; Version private Integer version; TableLogic private Integer deleted; TableField(fill FieldFill.INSERT) private LocalDateTime createTime; TableField(fill FieldFill.INSERT_UPDATE) private LocalDateTime updateTime; }这个实体类里TableName 指定表名TableId(type IdType.AUTO) 表示主键自增Version 乐观锁TableLogic 逻辑删除TableField(fill ...) 配合 MetaObjectHandler 实现创建时间和更新时间的自动填充。下面这段 DdlGenerator 是我自己封装的小工具不是框架功能读者可以复制去改public class DdlGenerator { public static String generate(Class? clazz) { TableName tableName clazz.getAnnotation(TableName.class); StringBuilder sb new StringBuilder(); sb.append(CREATE TABLE ).append(tableName.value()).append( (\n); for (Field field : clazz.getDeclaredFields()) { String column camelToUnderline(field.getName()); String type mapType(field.getType()); sb.append( ).append(column).append( ).append(type); TableId tableId field.getAnnotation(TableId.class); if (tableId ! null) { sb.append( NOT NULL AUTO_INCREMENT COMMENT 主键); } else { sb.append( DEFAULT NULL COMMENT ); } sb.append(,\n); } sb.append( PRIMARY KEY (id)\n) ENGINEInnoDB DEFAULT CHARSETutf8mb4;\n); return sb.toString(); } private static String mapType(Class? type) { if (type Long.class) return bigint; if (type String.class) return varchar(255); if (type BigDecimal.class) return decimal(10,2); if (type Integer.class) return int; if (type LocalDateTime.class) return datetime; throw new IllegalArgumentException(未映射的类型: type.getName()); } }这段工具代码的实用要点有三个。一是 getDeclaredFields() 和 getFields() 的区别前者能拿到所有字段包括 private后者只返回 public 字段。二是类型映射表要覆盖 Long、String、BigDecimal、Integer、LocalDateTime 这五种就够别贪多。三是主键字段名固定叫id生成 SQL 时统一加 PRIMARY KEY。生成出来的 SQL 手动在数据库执行一次后后续加字段只改实体类再重新执行生成的增量语句即可。线上环境不要反复整体执行那样会把表结构重建我一般维护一个增量 SQL 文件夹只放每次字段变更的 alter 语句。3.3 商品分页查询接口Controller、Service、Mapper 三层怎么写骨架搭好、表建好后第一个接口建议从商品分页查询开始因为它能验证建表、实体映射、分页插件、统一返回对象这一整条链路。Mapper 层继承 BaseMapper 后单表查询几乎不用写 SQLService 层封装业务逻辑Controller 只做参数接收。RestController RequestMapping(/api/goods) public class GoodsController { Autowired private GoodsService goodsService; GetMapping(/page) public ResultIPageGoods page( RequestParam(defaultValue 1) long current, RequestParam(defaultValue 10) long size, RequestParam(required false) String keyword, RequestParam(required false) Integer categoryId) { PageGoods page new Page(current, size); LambdaQueryWrapperGoods wrapper new LambdaQueryWrapper(); wrapper.eq(Goods::getStatus, 1); wrapper.like(StringUtils.hasText(keyword), Goods::getGoodsName, keyword); wrapper.eq(categoryId ! null, Goods::getCategoryId, categoryId); wrapper.orderByDesc(Goods::getCreateTime); return Result.ok(goodsService.page(page, wrapper)); } }这段代码是 MyBatis-Plus 最典型的查询写法。LambdaQueryWrapper 的两个好处eq 和 like 方法的第一参数是布尔条件keyword 为空时后面那段条件不会拼进 SQL不用自己写 if方法引用 Goods::getStatus 在编译期就能检查字段名写错字符串直接报编译错误。current 和 size 是页码和每页条数注意 current 从 1 开始不是从 0 开始前端组件如果传 0 要自己在适配层处理。分页能生效依赖一个关键配置忘了它 Page 就只是内存分页查出来是全部数据再切割Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }这个配置类必须显式注册否则 BaseMapper 的 selectPage 方法不会在 SQL 里拼 limit。我还建议给 Page 加一个上限size 最大 50防止有人传 10000 把数据库打崩。common 返回对象 Result 的字段保持 code、message、data 三项code 为 0 表示成功业务异常时返回非 0 码。IPage 返回给前端时带 total、current、size、records前端表格组件直接消费这四个字段不要自己再包一层。4. 农产品规格、配送范围与订单状态机三个农村场景要单独设计4.1 农产品多规格斤/盒/份与价格字段设计普通电商的规格是“颜色 尺码”农产品则是“重量 包装”。同一个果园的苹果5 斤装 39.9 元10 斤装 69.9 元整箱批发又一个价。如果每个规格都以独立商品上架前台搜索结果会重复泛滥卖家后台也要把所有信息重新录一遍。所以我把商品和规格拆成两张表goods 表存商品通用信息goods_sku 表存每个规格的具体价格、库存和图片。Data TableName(goods_sku) public class GoodsSku { TableId(type IdType.AUTO) private Long id; private Long goodsId; private String specName; private BigDecimal price; private BigDecimal originalPrice; private Integer stock; private String skuImage; Version private Integer version; }goods 表里的 min_price 字段其实是 goods_sku 表里最低那个 price 的冗余。每次卖家调整 SKU 价格后Service 里要同步更新 goods.min_price前台列表页按 price 排序时才准确。originalPrice 是用来展示划线价的录入时要校验必须大于等于 price否则页面上划线价比实际价还低看着很傻。这里还要加一道校验同一个商品下不允许存在两个规格名完全一致但价格不同的 SKU。比如卖家先建了“5 斤装 39.9”又建了“5 斤装 35.9”买家下单时根本分不清该选哪个。我的做法是在 Service 的 saveSku 方法里先查同名规格是否存在存在就抛业务异常。这道校验不写运营后台很快会被脏数据占满。4.2 配送范围按村/镇划分用与或表达式代替复杂地理位置计算农村电商的配送范围不能照搬城市电商的“经纬度 半径”。地图在村里的坐标偏移大而且“能不能送”还不只是距离问题哪怕直线距离三公里中间隔一条河司机也要绕十公里。所以我不建议用高德或百度地图的地理围栏接口而是直接用行政区划编码匹配简单、可靠运营也看得懂。配送规则表的设计要能表达两种粒度按村配送和按镇配送。我这样建CREATE TABLE delivery_region ( id bigint NOT NULL AUTO_INCREMENT, seller_id bigint NOT NULL COMMENT 卖家ID, region_code varchar(12) NOT NULL COMMENT 行政区划编码, region_type tinyint NOT NULL DEFAULT 2 COMMENT 1按村 2按镇, delivery_fee decimal(10,2) NOT NULL DEFAULT 0.00 COMMENT 配送费, sort_order int NOT NULL DEFAULT 0 COMMENT 优先级数字小的先匹配, create_time datetime DEFAULT NULL, PRIMARY KEY (id), KEY idx_seller_region (seller_id,region_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT配送区域表;为什么需要 sort_order 字段因为同一个卖家可能同时配置“全镇可送配送费 5 元”和“某某村加收 3 元”这时候该村订单应优先匹配更细的“按村”规则。我建议在代码里把规则查出来后先按 region_type 升序排type1 的按村规则排前面再用 sort_order 做第二排序匹配不上再退化到镇级规则。判断逻辑的核心就是行政区划编码的比较public boolean canDeliver(DeliveryRegion region, String buyerRegionCode) { if (region null || !StringUtils.hasText(buyerRegionCode)) { return false; } // 按村配送12位编码完全一致 if (region.getRegionType() 1) { return region.getRegionCode().equals(buyerRegionCode); } // 按镇配送比较前9位县以下编码基本是9位 return buyerRegionCode.length() 9 region.getRegionCode().equals(buyerRegionCode.substring(0, 9)); }这里用的 12 位国标行政区划编码前 6 位代表省市区县前 9 位代表乡镇街道。按镇匹配时我比较前 9 位等于说买家收货地址属于这个镇下的任何一个村都算可配送。这段逻辑看着简单但它是整个配送模块的基础测试时一定要覆盖两个边界买家选了外省地址但编码前缀恰好相同的情况以及 regionCode 长度不足 9 位或 12 位的异常数据。前端在下单页展示“当前地址可配送/暂不配送”时实际调用的就是这个逻辑对应的接口。4.3 订单状态机的设计与超时未支付自动关闭订单状态是这类系统里最容易写烂的地方。我见过有人把状态存成字符串“已付款”“已支付”“支付完成”三种写法并存统计一塌糊涂。规范做法是用枚举定义状态机把每个状态的合法流转收敛到一个方法里。订单状态我固定为 7 个10 待付款、20 待卖家接单、30 待发货、40 配送中、50 待自提、60 已完成、70 已取消。每个状态能转移到哪些目标状态直接写在枚举里public enum OrderStatus { UNPAID(10) { Override public boolean canTransferTo(OrderStatus target) { return target PAID || target CANCELED; } }, PAID(20) { Override public boolean canTransferTo(OrderStatus target) { return target WAIT_SHIP || target CANCELED; } }, WAIT_SHIP(30) { Override public boolean canTransferTo(OrderStatus target) { return target DELIVERING; } }, DELIVERING(40) { Override public boolean canTransferTo(OrderStatus target) { return target WAIT_PICKUP || target COMPLETED; } }, WAIT_PICKUP(50) { Override public boolean canTransferTo(OrderStatus target) { return target COMPLETED; } }, COMPLETED(60), CANCELED(70); private final int value; OrderStatus(int value) { this.value value; } public boolean canTransferTo(OrderStatus target) { return false; } }COMPLETED 和 CANCELED 是终态没有重写 canTransferTo默认返回 false。所有改状态的操作统一走 OrderService.changeStatus 方法方法内部先比较当前状态是否能转目标状态不能转就抛异常。这样做的好处是将来运营后台要加“强制关闭异常订单”功能只需要在枚举里加上从某个状态到 CANCELED 的合法路径而不用在业务代码里到处搜索订单状态赋值的地方。超时未支付自动关闭订单常见做法是 Spring 定时任务每分钟扫描一次把超过 30 分钟未支付的订单批量取消并释放库存。不要一上来就引入 RabbitMQ 延迟队列或 Redis 过期事件这个体量的项目加了中间件部署和运维成本直接翻倍。定时任务延迟最多一分钟买家几乎感知不到完全可以接受Component public class OrderTimeoutTask { Autowired private OrderService orderService; Scheduled(cron 0 * * * * ?) public void closeTimeoutOrders() { ListOrderInfo timeoutOrders orderService.listTimeoutOrders(30); for (OrderInfo order : timeoutOrders) { orderService.changeStatus(order.getId(), OrderStatus.CANCELED); orderService.releaseStock(order.getId()); } } }这段任务有两个细节值得注意。一是 cron 表达式 “0 * * * * ?” 是每分钟第 0 秒执行如果写成 “0 0 * * * ?” 就变成每小时执行一次不仔细看还真发现不了。二是 releaseStock 方法必须按 order_item 表里的 sku_id 和数量把库存加回去不能直接把商品主库存加满。释放库存时要先确认订单状态确实是 20已取消否则两个线程同时处理同一张订单库存会被重复加一次。这个重复执行的坑我在实际项目里踩过所以要在这里强调一下。5. 避坑手册金额、库存、图片、乱码、打包的 5 个经典翻车点5.1 BigDecimal 与金额计算别用 double 给农产品称重结算现象商品 39.9 元买家下单 3 份后端算出来 119.69999999999999 元页面金额对不上对账总是差几分钱。原因double 是浮点型二进制无法精确表示 0.1 和 39.9 这类十进制小数金额计算只要用过 double精度就从那一刻开始丢失积累到一定量级就会暴露成对账差异。解决金额字段全链路用 BigDecimal数据库列类型 decimal(10,2)实体类字段 BigDecimal计算只用 add、subtract、multiply除法必须指定精度和舍入模式BigDecimal price new BigDecimal(39.90); BigDecimal quantity new BigDecimal(3); BigDecimal total price.multiply(quantity).setScale(2, RoundingMode.HALF_UP);两个参数说明new BigDecimal 必须传字符串不能直接传 double 字面量 39.9否则精度在构造时就已经坏了setScale(2, RoundingMode.HALF_UP) 表示结果保留两位小数并四舍五入这是电商金额计算的标准舍入策略。另外订单明细表的单价、数量、金额入库前要做一次校验明细金额之和必须等于订单总金额不相等直接拦截防止前面某一步计算错误污染对账数据。5.2 并发扣库存select 再 update 会超卖现象做了一个土鸡蛋限时活动库存 100 份最终订单卖出去 130 份。原因两个请求同时读到库存剩余 1都判断“库存够”然后各自把库存更新成 0最后两张订单都创建成功。这就是典型的先查后改并发问题。解决把判断和扣减合并成一条原子 SQL或者用乐观锁。我推荐用带条件的 update 语句UPDATE goods_sku SET stock stock - #{buyNum}, version version 1 WHERE id #{skuId} AND stock #{buyNum} AND deleted 0这条 SQL 的关键在 WHERE 条件stock #{buyNum} 保证库存充足才更新返回影响行数 1 表示扣减成功返回 0 表示库存不足或 SKU 已删除业务层拿到 0 就抛“库存不足”异常。这里还手动了 version 1配合实体上的 Version 在 updateById 时也能生效。数据一致性方面创建订单和扣库存最好放在同一个事务方法里但事务里不要调远程接口、不要 Thread.sleep否则高并发下连接池会被占满。遇到真正的秒杀场景再考虑 Redis 预扣减。5.3 商品图片上传本地存储别把图片塞进数据库现象商品图片用 base64 存进数据库一张图 2MB数据库表迅速膨胀商品列表接口越来越慢。原因把二进制大对象放进数据库列数据库既要维护索引又要读大字段普通查询每次都要把 blob 从磁盘拖出来性能自然恶化。解决图片文件只落盘到服务器本地目录数据库存相对路径。Spring Boot 里做一个静态资源映射把上传目录暴露成 /upload/** 访问路径Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { String uploadPath System.getProperty(user.dir) /upload/; registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadPath); } }addResourceHandlers 的意思是把所有 /upload/** 的请求映射到 jar 运行目录下的 upload 文件夹。addResourceLocations 必须带 file: 前缀路径末尾要有分隔符这是最容易漏的细节。上传接口保存文件时文件名用 UUID 加原始扩展名不要用原始中文名避免 URL 编解码踩坑。上线后 upload 目录和 jar 放在一起备份时打包整个部署目录即可。5.4 中文乱码UTF-8 要设置三处以上现象商品名称在数据库查询正常网页上显示问号或者本地开发正常部署到 Linux 服务器就乱码。原因字符集断在了某一个环节。常见的是本地 IDE 默认 GBK、项目源码是 UTF-8编译后字节对不上或者 MySQL 连接串少了 characterEncoding 参数或者建表语句没问题但表默认字符集是 latin1。解决按三个位置排查。第一pom.xml 里锁定源码编码避免在不同系统上编译产物不一致properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties第二数据库连接 URL 里带 useUnicodetruecharacterEncodingutf8这个在 3.1 节的 yml 里已经写了。第三建表语句统一用 DEFAULT CHARSETutf8mb4MySQL 5.7 默认字符集可能是 latin1不指定就是乱码源头。部署到 Linux 后如果还乱码检查服务器 locale 和 jar 包内容编码用mvn clean package重新打一次包不要从 Windows 解压 tar 包直接塞到服务器文件编码可能已经在压缩解压过程中被改掉了。5.5 打包 war 还是 jar怎么把项目交给不会配环境的运营现象项目在 IDEA 里点运行一切正常打成包发给运营对方说双击没有任何反应。原因最常见的三种情况打了 war 包但没人会部署到 Tomcat打了 jar 包但服务器没配 JDK 环境变量还有人直接把源码目录打成 tar 包发过去运营拿到一堆 .java 文件根本不知道怎么启动。解决Spring Boot 项目默认打成可执行 jar用 Maven 命令打包不要依赖 IDEA 的按钮mvn clean package -DskipTests启动命令一行java -jar rural-shop-1.0.0.jar --server.port8080如果服务器装了多个 JDK先用java -version确认默认版本再用全路径指定 JDK。用户环境里存在多个 JDK 时环境变量 PATH 最前面的那个生效这个顺序问题经常导致启动直接报 UnsupportedClassVersionError。如果运营确实要求交付 tar 包打包的应该是部署目录而不是源码目录tar -czf rural-shop-deploy.tar.gz rural-shop/deploy-tar 目录里只放三类东西可执行 jar、upload 目录、一个 start.sh 启停脚本。脚本内容就是判断 java 存在后执行 java -jar。这样运营拿到 tar 包解压、执行脚本就能启动不需要重装环境。6. 从小村试点到多商户演进验证方法和我的教训6.1 单机部署先跑通用 docker-compose 组织 MySQL 与应用如果是给一个镇做试点不要一开始就上多机部署。单机用 docker-compose 把 MySQL 和应用组在一起既省了手动装数据库的麻烦又能在另一台机器上快速复现环境。把 jar 包和 upload 目录挂载进容器后续更新版本只替换 jar不用重建整个容器version: 3.8 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: rural_shop ports: - 3306:3306 volumes: - ./mysql-data:/var/lib/mysql command: --character-set-serverutf8mb4 app: image: openjdk:8-jre volumes: - ./rural-shop-1.0.0.jar:/app/app.jar - ./upload:/app/upload ports: - 8080:8080 depends_on: - mysql command: java -jar /app/app.jar这里的 MySQL 通过 command 显式指定 utf8mb4避免容器内默认字符集问题。upload 目录必须挂载出来否则容器一删运营传的商品图全没了。这个代价是值得的因为容器是给运营做演示的好选择但数据库文件必须放在宿主机磁盘上。6.2 给系统做一轮最基础的性能验证看哪些参数正式给客户展示前我先做冒烟验证再考虑压测。冒烟流程是固定的注册一个卖家账号和买家账号、上架两种规格的商品、买家下一单、走一遍卖家接单和发货、运营确认配送、买家收货完成。这条链路全通了业务才算基本可用。压测时只关心三个指标接口平均响应时间、TPS、MySQL 连接数。农村电商单点试点阶段接口 200ms 内、TPS 50 以上已经够用容易出问题的反而是运营后台导出订单明细的慢 SQL我一般会提前给 order_info 表加上 status、create_time 联合索引统计报表按月分组时会明显快很多。6.3 我的一点教训别一上来就上微服务我做这个类型的第一个项目时同事坚持用 Spring Cloud把用户、商品、订单、配送拆成四个微服务结果光搭网关、注册中心、配置中心就耗了一周业务一行没写。后来我把架构改成单体应用模块边界不拆Java 包结构按用户中心、商品中心、订单中心划分一个月就交付了试点。农村电商系统的核心业务闭环全在一张订单上拆服务解决不了农村配送和农产品规格的问题反而让排查问题变成跨服务追日志。技术选型跟着业务复杂度走别为了简历好看而过度设计。希望帮到你。本文还有配套的精品资源点击获取