企业官网建设流程全解析

1. 项目概述与核心需求解析

1.1 城乡商城协作系统到底解决什么问题

先说结论：这个"基于SpringBoot的城乡商城协作系统"（项目编号57734107），本质上是一个解决"农产品上行、工业品下行"双向流通痛点的电商平台原型。它跟普通商城系统的最大区别在于，业务模型里多了一层"城乡协作"的维度——城市端的消费者需要买到产地直供的农副产品，乡村端的农户/合作社需要把货卖出去，而两者之间的信息差、物流差、信任差，就是这套系统要解决的核心问题。

从毕设或者个人项目的角度来看，这个选题的切入点很讨巧。它不是单纯的CRUD堆砌，而是把电商、权限、订单流转、物流协作这几个业务域串在一起，技术栈又能完整覆盖SpringBoot的主流玩法。我当时拿到这个题目的时候，第一反应是：这玩意儿的关键不在"商城"，而在"协作"两个字——城乡两端的角色、流程、数据模型都要围绕这个协作关系去设计。

那具体来说，这套系统需要支撑的角色大致有这么几类：平台管理员、城市端消费者、乡村端商户（农户/合作社）、以及配送协作方。每个角色的操作边界和核心诉求都不一样，这就决定了权限设计不能用一个简单的user表打天下，而是需要引入角色-权限的灵活控制机制。

再聊聊适合谁来参考。如果你正在准备Java方向的毕设，或者想做一个能写进简历里的SpringBoot实战项目，这个题目提供了很好的业务复杂度——它不像是图书管理、学生管理系统那样一眼看穿，也不至于像电商秒杀那样把并发和分布式做得太重，属于那种"跳一跳够得着"的项目，能展示你对业务建模和主流框架的掌握程度。

1.2 技术选型背后的思考

SpringBoot作为核心框架，没什么好犹豫的，它已经是Java后端开发的事实标准。但选型的过程里有一些细节值得展开说说，因为这些决策直接影响后续开发的效率。

首先是版本选择。我记得做这个项目的时候，SpringBoot 2.x还是主流，选的是2.7.x，JDK对应1.8。为什么不直接上SpringBoot 3.x？最关键的原因是生态兼容性。3.x基于Jakarta EE规范，包名从javax改成了jakarta，很多老牌的第三方库（比如一些Activiti工作流、老的MyBatis插件）在新规范下会出现兼容问题。另外，很多资料、教程、网上的报错解决方案，都集中在2.x版本，遇到坑的时候能搜到的参考更多。如果你现在才开始做，可以去看看SpringBoot 3.x + JDK 17的搭配，但务必确认你集成的前后端组件都支持Jakarta规范，否则排查起来比较痛苦。

持久层框架选了MyBatis-Plus。这里要说一下我的理由：这个项目的数据模型涉及用户、商品、订单、购物车、物流、结算等多个维度，如果全用原生MyBatis写XML，工作量会翻倍。MyBatis-Plus提供了通用的Mapper CRUD接口，单表操作基本不需要写SQL，复杂查询再手写XML，开发效率提升非常明显。当然，Hibernate/JPA也是一个选项，但考虑到国内社区生态、以及很多人对SQL可控性的偏好，MyBatis-Plus在这类项目中更主流。

前端这块，我用的是Vue + Element UI，前后端分离开发。为什么不用服务端模板引擎（比如Thymeleaf）？因为这个系统的交互复杂度摆在那里——购物车、订单追踪、后台管理看板，都是典型的单页应用场景，前后端分离可以让前端工程师和后端工程师并行开发互不阻塞。如果你是一个人独立开发，前后端分离也能让代码结构更清楚，接口边界更明确。

数据库必然选MySQL，配合Redis做缓存和会话管理。Redis在这里的定位值得说道说道——不只是做缓存，购物车的临时状态、商品浏览记录的存储、以及高频访问的分类信息，都可以用它来处理，后面我会单独讲怎么用。

2. 系统架构与数据模型设计

2.1 整体架构：从单体到分层再到模块化

这个系统用的是经典的SpringBoot单体分层架构，但内部做了模块化处理。先别急着上微服务——城乡商城协作系统的业务复杂度还没到必须拆微服务的程度，单体架构在开发、部署、调试上的优势非常明显，尤其对于个人项目或者小团队来说，一个SpringBoot应用就能搞定的事情，拆成多个服务只会平添运维负担。

分层这块没有什么悬念：Controller层负责接收参数和返回结果，Service层处理业务逻辑，Mapper层做数据持久化，实体层定义数据模型。不过我会额外加一层DTO/VO的转换，这样设计的目的是避免直接把数据库实体暴露给前端接口。比如用户密码字段，如果直接把User实体返回给前端，一旦忘了忽略敏感字段，密码就泄露了。用VO做隔离，前端需要什么字段就返回什么字段，这也是一个很重要的安全意识。

在代码组织上，我用的是按业务模块分包，而不是按技术层次分包：

com.citymall ├── common // 通用工具、统一返回结果、异常处理 ├── config // 配置类（Redis、拦截器、跨域等） ├── controller // 前端接口入口 ├── service // 业务逻辑层 ├── mapper // 数据访问层 ├── entity // 数据库实体 ├── dto // 请求参数对象 ├── vo // 返回视图对象 └── utils // 工具类

这种组织方式的优点是：当你需要在"商品模块"里加一个功能时，你只需要在对应包下面新增类，而不是在十几个不同名称的包里来回跳动。实际开发下来，我对这个组织结构最大的体会是：项目初期花半小时规划包结构，比后期维护时花半天调整要划算得多。

2.2 核心数据表设计思路

数据表设计是整个系统的地基。城乡商城协作系统涉及的核心表，我梳理了一下大概有这么几张：

订单相关的表，我把orders和order_item拆分成了主从两张表。为什么不把商品信息直接塞进orders这张表？因为一个订单可能包含多个商品，如果塞在一起，会违反数据库的第一范式，后续统计销售额、做退款结算都会非常痛苦。order_item里会冗余一份product_name和price快照，这点很重要——商品价格和名称随时会变，但订单里的历史快照必须保留，否则拉出三年前的订单，显示的价格和当时实际支付对不上，这就是事故了。

再强调一下collaboration这张表——它是我为了体现"城乡协作"这个业务主题专门设计的。当城市用户下单后，系统会生成一条协作记录，标记这个订单是由哪个乡村商户供货、配送任务流转到哪个环节。通过这张表，管理员可以直接看到"哪些乡村商户在最近一个月给城市供应了多少商品"，这比在订单表里硬查要清晰得多。

数据库字段类型上，金额一律用DECIMAL(10,2)，不要用float或double。浮点数在计算机里是近似存储的，累计到一定程度会出现账不平的问题，这是电商系统的大忌。库存字段如果用int，在并发扣减时要注意加锁或使用乐观锁，我后面会细说。

3. 核心功能模块实现详解

3.1 用户注册登录与JWT鉴权

用户的注册和登录自然是系统的入口。密码不能明文存储，这个不用多说了吧？我用的BCrypt加密算法，Spring Security内置支持。BCrypt的一个特点是你不需要单独存盐，每次加密时随机生成盐并拼在密文里，校验的时候自动提取，这对开发者来说省了不少事。

登录成功后，我用JWT（JSON Web Token）生成一个Token返回给前端。这里要解释一下为什么用JWT而不是session：前后端分离的架构下，后端接口是无状态的，如果用session，就需要处理跨域携带Cookie、集群同步session等一系列麻烦。JWT把用户信息加密后放在Token里，前端每次请求带上，后端验签通过就信任这个身份，这就是它的核心思路。

JWT的代码实现大概长这样：

public String generateToken(User user) { return Jwts.builder() .setSubject(user.getUsername()) .claim("userId", user.getId()) .claim("role", user.getRoleType()) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + 7200 * 1000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); }

要注意的是，不要把敏感信息塞进JWT的载荷里，因为JWT虽然是签名防篡改的，但载荷部分默认只是Base64编码，任何人拿到Token都能解码看到内容。密码之类的信息绝对不要放进去。有效期我设置了2小时，前端在Token快过期时通过拦截器静默刷新，这个属于体验优化的细节。

拦截器是鉴权落地的关键一环。自定义一个HandlerInterceptor，在preHandle方法里从请求头取出Token、解析校验、把用户信息放进ThreadLocal里供后续业务使用。对于登录接口、注册接口、商品浏览这些不需要鉴权的路径，用excludePathPatterns排除掉；而下单、结算、后台管理等接口，必须登录才能访问。

3.2 商品管理与城乡双视角展示

商品模块是这个系统的内容核心。乡村商户可以在后台发布商品、设置库存和价格、管理上下架；城市消费者则在前台按分类浏览、搜索、查看详情。

商品列表接口我做了几点优化。第一是分页参数必填，避免一次性查出全表数据把数据库压垮；第二是关键词搜索用MySQL的LIKE，但不要用前置通配符%keyword，那样会导致索引失效；第三是列表查询的结果统一放进Redis缓存，key设计为product:list:{categoryId}:{page}:{size}，缓存5分钟。这个缓存策略很有效，因为商品列表是访问量最大的热数据，但变化频率不高，即使缓存里有5分钟的滞后也完全能接受。

商品上下架的并发控制值得一提。商户在后台把库存调整成1000件，但同一时间可能已经有用户在创建订单了。我的方案是，在用户提交订单时校验库存并执行扣减SQL，扣减语句必须带库存条件：

UPDATE product SET stock = stock - #{quantity} WHERE id = #{productId} AND stock >= #{quantity}

这条SQL返回的受影响行数为0，说明库存不足，直接抛业务异常回滚订单。这种方式就是乐观锁思想，不需要显式加悲观锁，在高并发场景下性能更好，对毕业设计这个级别足够用。

城乡双视角是这个系统的一个特色。同样的商品，城市消费者看到的是"产地直供"的商品卡，展示的是城市标准价格和预计配送时间；乡村商户后台看到的是自己的商品列表、销量统计、待发货订单。前端可以根据用户角色，显式渲染不同的路由和组件，后端的接口则在返回数据时根据角色类型做字段裁剪。

3.3 购物车与订单流转

购物车我采用了Redis + MySQL双写方案。为什么这么设计？购物车的特点是频繁增删改查、但数据重要性中等——用户可能连续加好几件商品再一起结算，如果每次都写数据库，压力很大。我的方案是：购物车主要操作走Redis，用Hash结构存储，field为userId，value为商品条目列表的JSON；用户点击结算时，再把Redis中的购物车数据同步到MySQL生成正式订单。

这个方案的好处是明显的：Redis的读写性能高，可以支撑用户频繁点击加入购物车而不至于把MySQL打爆；同时结算时以MySQL订单为准，保证数据的持久性。当然，设计上需要处理一个细节——如果用户清空了Redis但还没结算，购物车就丢了。我的处理是，Redis的购物车数据设置了较长的TTL（比如7天），同时每次加入购物车时异步写一份到MySQL做备份。用户重新登录时，优先读Redis，读不到再回源数据库，这样既保证性能又保证不丢数据。

订单的流转状态是电商项目里最需要认真设计的状态机。我把订单状态定义为：待付款、待发货、已发货、已收货、已完成、已取消、退款中、已退款。每次状态流转的合法性校验不能只在前端做，后端必须有一张状态流转表来校验。比如待付款订单不能直接跳到已发货，必须经过支付回调。它的实现方式很简单，就是一个枚举类，定义了状态之间的合法性映射：

public enum OrderStatus { PENDING_PAYMENT("待付款"), PENDING_SHIPMENT("待发货"), SHIPPED("已发货"), RECEIVED("已收货"), COMPLETED("已完成"), CANCELLED("已取消"), REFUNDING("退款中"), REFUNDED("已退款"); private static final Map<OrderStatus, List<OrderStatus>> TRANSITION_MAP = new EnumMap<>(OrderStatus.class); static { TRANSITION_MAP.put(PENDING_PAYMENT, Arrays.asList(CANCELLED, PENDING_SHIPMENT)); TRANSITION_MAP.put(PENDING_SHIPMENT, Arrays.asList(SHIPPED, CANCELLED)); TRANSITION_MAP.put(SHIPPED, Arrays.asList(RECEIVED, REFUNDING)); // ... 其他状态流转 } }

在下单这个核心操作上，我用了Spring的@Transactional注解保证事务，并设置了事务的传播级别和回滚规则。特别注意一点：事务方法不要同类内部调用，否则@Transactional注解不生效。这是Spring的代理机制导致的经典坑——同类内部调用走的是this.xxx()，不经过代理对象，事务就失效了。我当时排查了很久的"订单数据没写入但也没报错"，最后发现就是这个原因。

3.4 城乡协作任务分配与结算逻辑

这个模块是项目名字里"协作"二字的落地。当一个订单创建后，系统会根据订单中的商品归属，自动生成一个协作任务，任务内容包括：乡村商户供货、城市仓收货、末端配送三个环节。

我用了一个简单的策略模式来实现任务分配。定义TaskDispatcher接口，根据订单中商品类别和收货地址的不同，选择不同的配送协作策略。比如生鲜类商品，对时效要求高，优先匹配同城配送策略；日用品类商品，时间不敏感，走常规物流策略。这样设计的可扩展性很好——将来接入新的物流供应商，只需要实现TaskDispatcher接口并注册到Spring容器即可，不需要改动已有的订单主流程。

结算模块采用的是T+1日自动结算模式。什么意思？T日确认收货的订单，T+1日系统定时任务会把交易金额扣除平台佣金后，结算给乡村商户。这里有个定时任务的实现细节：很多初学者用Scheduled注解直接写死每天凌晨执行，然后扔在那里不管了。但真实的场景要考虑三点——任务幂等性、任务失败补偿、以及时区问题。我用的是SpringBoot内置的@Scheduled配合分布式锁思路来保证：多个实例同时跑定时任务时，只有拿到Redis锁的那个实例真正执行，其他实例直接跳过。如果不加这个控制，将来系统做集群部署，同一个结算任务会被执行两次，商户的钱就会多打一次，这是非常严重的生产事故。

4. SpringBoot关键技术点落地

4.1 自动装配原理与自定义Starter

SpringBoot最核心的"魔法"就是自动装配。很多初学者知道加了@SpringBootApplication注解就能跑起来，但不知道为什么。这里我把原理掰开来说。

SpringBoot的自动装配机制基于@EnableAutoConfiguration注解，这个注解通过@Import引入了AutoConfigurationImportSelector，Spring在启动时会扫描所有jar包下META-INF/spring.factories文件（或者SpringBoot 2.7+的META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件），找到所有标注了@Configuration的自动配置类，然后根据条件注解@ConditionalOnClass、@ConditionalOnMissingBean、@ConditionalOnProperty等，按需加载这些配置类。

举个例子，Redis自动配置类RedisAutoConfiguration上标注了@ConditionalOnClass(RedisOperations.class)，意味着只要项目的classpath里有Redis相关的类，它就生效，然后自动创建RedisTemplate、StringRedisTemplate等Bean。如果你的项目根本没引入Redis依赖，这个配置类就不会生效，不会报错。这就是SpringBoot"智能"的底层原理。

理解了原理之后，我还尝试做了一个自定义Starter——把文件上传功能封装成一个独立的模块，配置prefix和suffix前缀/后缀即可自动装配上传服务。做这个小东西的过程让我对SpringBoot的配置体系理解深了很多，也建议你有时间可以试一下，比干看文档有效多了。

4.2 多数据源与读写分离配置

城乡商城协作系统的数据量虽然不算大，但我在设计时考虑了读写分离的扩展性。这个项目早期只有一台MySQL实例，后期为了提升查询性能，我配置了多数据源：主库负责订单写入、库存扣减等写操作，从库负责商品浏览、统计报表等读操作。

SpringBoot多数据源的核心是配置两个DataSource Bean，并配合AbstractRoutingDataSource实现动态数据源切换。具体的思路是：在mapper接口或者Service方法上自定义注解@DataSource("slave")，通过AOP切面拦截方法执行前动态切换当前线程使用的数据源。

这里有个关键问题是事务和连接的管理。如果主从两个数据源都配置了@Transactional，Spring默认只使用primary数据源的事务管理器，从库的操作不会被包含在同一个事务里。所以务必要理解：读操作一般不需要事务，写操作集中在主库，不要把读写分离和跨库事务混在一起用。如果真有跨库事务需求，就需要引入分布式事务框架（比如Seata），但那个复杂度对当前系统来说没有必要。

4.3 Redis缓存、限流与分布式会话

Redis在这个系统里承担了三个职责。第一个是缓存，前面已经提过商品列表和购物车。第二个是接口限流，我实现了一个简单的基于Redis+Lua的滑动窗口限流器——对特定接口（比如短信发送、订单提交）规定某个用户每分钟最多调用N次，超出则直接拒绝。用Lua脚本是为了保证"检查计数"和"增加计数"两个操作的原子性，避免高并发下计数超限还被放行。

public boolean allowAccess(String key, int maxCount, long windowSeconds) { String luaScript = "local count = redis.call('incr', KEYS[1]) " + "if count == 1 then " + " redis.call('expire', KEYS[1], ARGV[1]) " + "end " + "if count > tonumber(ARGV[2]) then " + " return 0 " + "end " + "return 1"; Long result = stringRedisTemplate.execute( new DefaultRedisScript<>(luaScript, Long.class), Arrays.asList(key), String.valueOf(windowSeconds), String.valueOf(maxCount)); return result != null && result == 1L; }

第三个职责是分布式会话。之前说过项目用JWT做接口鉴权，但在某些场景下（比如后台管理系统的登录状态记录、操作审计），JWT的无状态特性反而不好用，因为无法在服务端主动让某个Token失效。我的方案是JWT + Redis黑名单：正常登录的Token在Redis里有记录，每次请求校验JWT合法后，再查一下Redis里这个Token是否在黑名单中；用户退出登录时把Token加入黑名单，并清除Redis里的登录态。这样兼顾了JWT无状态快速校检的优点，又补充了主动失效的能力。

4.4 统一异常处理与接口规范

很多项目做得粗糙，接口返回格式不统一，前端对接起来非常痛苦。这个系统从一开始就定义了统一的返回结构，所有接口的响应都遵循这个格式：

{ "code": 200, "message": "操作成功", "data": { } }

业务上定义异常码：200表示成功，400表示参数错误，401表示未登录，403表示无权限，500表示服务器异常，自定义的业务异常码从10001开始递增。Controller层使用@RestControllerAdvice配合@ExceptionHandler做全局异常捕获，捕获到MethodArgumentNotValidException时返回400参数错误，捕获到业务异常时返回业务码，捕获到Exception时记录错误日志并返回500。

统一返回结构的好处我不用多说，这里想分享一个经验：一定不要把后端的堆栈异常直接返回给前端。第一是信息泄露风险（别人可以通过异常信息猜到你的数据库表结构、框架类型），第二是前端根本看不懂。全局异常处理里把真实异常记录到日志文件，返回给前端的只有通用提示和业务码，这才是正确的做法。

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

5.1 SpringBoot版本太高引发的兼容性坑

这个项目开发初期，Idea默认创建的SpringBoot版本是2.7.13，当时觉得版本新就是好，结果很快就踩了坑。最典型的是Swagger集成问题。我用的springfox 2.9.2版本，在SpringBoot 2.6及以上版本中，因为路径匹配策略从AntPathMatcher变成了PathTraversalMatcher，启动时直接报错，空指针异常一片，Swagger的UI页面全都打不开。

解决方式有两种：第一种是把SpringBoot降回2.5.x，继续用老版本springfox；第二种是升级到springdoc-openapi，这个库专门适配了新版SpringBoot。我做项目时选择了第二种，因为项目才刚开始，没必要为了一个依赖去降低主框架版本。

类似的兼容性问题还包括：SpringBoot 2.7中Spring Security的配置链方式有变化、MyBatis-Plus的旧版本分页插件和新版本的拦截器实现不同。我的建议是，如果你遇到了奇怪的启动报错，第一步不是搜报错信息本身，而是先检查SpringBoot版本和你引入的第三方库版本是否是同一个时代的产物。版本不对，一切努力白费。

5.2 Idea与开发环境配置经验

Idea新建SpringBoot项目，初期一个让我比较头疼的问题是默认的Maven仓库在国内访问外网太慢。这个问题的处理方式很直接：把Maven的镜像源配置成阿里云的，具体是在~/.m2/settings.xml里的mirrors节点配置镜像地址。换完之后，依赖下载速度从几十K每秒提升到几M每秒，体验完全不在一个档次。

还有一个环境问题是JDK版本混乱。我本机装了JDK 8、11、17好几个版本，Idea新建项目时如果没注意Project Structure里的SDK设置，很容易出现编译报错"invalid source release"或"java: 错误: 不支持发行版本",。这个坑的根源是Idea的Project SDK和Java编译器的target版本不一致，把两处都统一设置成1.8即可，还有Maven的编译器插件里也要确认source和target都是1.8。三处设置对不上，就会出现这种看似莫名其妙的问题。

VS Code能启动SpringBoot项目吗？能，但我劝你别在开发阶段用。VS Code跑Java项目主要靠Language Support for Java插件，勉强能编译能调试，但是对Spring注解的支持、application.yml的自动补全、热部署的体验都比Idea差不少。我的定位是：VS Code适合临时改代码、看日志、紧急修个bug，正经开发还是用Idea。

5.3 部署上线与服务器配置记录

项目完成后我把它部署到了云服务器上。部署方案很简单：Maven打包成jar包，用java -jar命令启动，配合systemd做成服务。这里有几个要点：

第一，生产环境的SpringBoot配置要跟开发环境分离。我用了SpringBoot的多Profile机制，application-dev.yml和application-prod.yml分开，生产环境指定--spring.profiles.active=prod启动。生产配置里的数据库密码、Redis密码不要写在配置文件里明文保存，用环境变量引用。

第二，JVM参数要调。默认的JVM堆内存可能太小，我这边服务器是2G内存，配置了-Xms512m -Xmx1024m，给系统留足够余量。另外加了-XX:+HeapDumpOnOutOfMemoryError参数，一旦发生内存溢出自动生成堆转储文件，方便事后排查。

第三，关于内嵌容器。项目默认内嵌Tomcat，端口在application.yml里配置server.port。有些单位要求用国产中间件替换Tomcat，比如宝兰德，SpringBoot是支持通过替换内嵌容器依赖来实现的——把spring-boot-starter-tomcat排除，引入宝兰德的SpringBoot适配依赖，再调整相关配置项即可。这个操作的原理是SpringBoot的内嵌Web容器通过WebServerFactoryCustomizer接口实现可定制，换容器只是换一个工厂实现。

5.4 订单超时未支付与库存回滚

这个问题的处理方式我放在最后说，因为它涉及一个很经典的定时任务方案。用户下单后如果不支付，订单会一直处于待付款状态，占着库存不放。传统的做法是定时器每分钟扫描超过30分钟未支付的订单，将其改为已取消并释放库存。但这个方案有一个隐患：如果同一时间有大量订单超时，SQL扫描和更新会对数据库造成瞬时压力。

我的优化方案是把"超时订单扫描"这个动作拆两步走。第一步，下单时把订单号和超时时间写入Redis的延迟队列（用Sorted Set，score为超时时间戳）。第二步，后台线程每分钟从Sorted Set里取出score小于当前时间戳的订单号，批量查询这些订单的状态，把仍处于待付款的订单置为取消并释放库存。这样做的好处是，数据库不需要全表扫描"所有超时订单"，而是只针对Redis里明确到期的订单做精确处理，压力要小得多。

这个方案让我在项目答辩和简历上都有了很亮眼的亮点。因为它体现的不是"会用SpringBoot"，而是"理解业务本质并选择合适的技术方案来解决问题"，这两者之间的差距，正是区分普通代码搬运工和合格开发者的地方。

6. 实操经验总结

最后分享几个我自己在实际开发中踩出来的经验，如果你也在做同类系统，应该能帮你少走弯路。

第一，接口设计文档前置。哪怕是自己一个人开发，也先把所有接口路径、请求方法、参数、返回结果列成一张表，再动手写代码。这个动作看着繁琐，但能避免在开发中途频繁改代码导致前后端联调被拖垮。我自己在做这个项目的用户模块时，就是先列了登录、注册、验证码、刷新Token、改密码、个人信息这6个接口的明细，后面写代码基本没返工。

第二，日志要舍得打。开发阶段觉得日志是噪音，遇到线上问题才知道日志就是你的眼睛。我在关键业务节点（下单、支付回调、取消订单、结算）都打印了业务日志，包含订单号、用户ID、操作前状态、操作后状态。后来排查一个"订单状态被错误更新"的问题，就是靠日志定位出来的——用户重复点击提交按钮，导致两个请求并发处理了同一笔订单。

第三，数据库建表时预留扩展字段。每个业务表我都加了create_time、update_time、deleted这三个字段。deleted字段配合MyBatis-Plus的逻辑删除功能，可以在不真正删数据的情况下实现删除操作。这个设计的好处是，将来做数据恢复、历史数据统计时，数据还在，不至于追悔莫及。

第四，Git提交信息要规范。这个项目前后写了大概三千多行代码，提交次数上百次。我刚开始的提交信息是"修bug"、"改代码"这种，后来发现根本不知道某次提交改了什么。后来强制自己按"feat:功能"或"fix:修复"的格式提交，再配合tag打版本，回滚排查问题的效率高了很多。

这个城乡商城协作系统，做完之后最深的感受是：SpringBoot只是一个工具，真正有价值的是你对业务的理解和建模能力。系统的每个模块背后，都对应着现实中真实存在的协作关系——乡村商户的希望、城市消费者的需求、平台方的调度统筹，这些交织在一起，才构成了"协作"二字的分量。如果你也在做类似的毕业设计或实战项目，别急着写代码，先花两天把业务理清楚、把表设计好，后面写代码的速度会快到让你自己都惊讶。