企业官网建设流程全解析

做电商类项目，最怕的不是业务逻辑，而是骨架搭建。最近我把一套Spring Boot登山用品商城的源码整理出来了，编号27394，前后端完整，数据库脚本齐全，非常适合拿来当毕业设计或者Spring Boot实战练手。这篇博文我会把这个项目从表结构设计到部署运行整个链路拆开讲，重点说清楚每个模块为什么这么设计，以及本地跑起来的时候最容易踩哪些坑。

这个项目不是那种只放几个接口的“玩具商城”，它把用户、商品、购物车、订单、后台管理这些常规电商闭环都覆盖到了。商品模块做了分类、搜索、详情和图片上传，订单模块做了库存扣减和订单状态流转，前端用了Vue，后端接口全部是RESTful风格。如果你正在找Spring Boot实战源码做参考，这个项目大概率能省你不少事。

1. 项目概述与设计思路

1.1 为什么用Spring Boot构建登山用品商城

早些年做Java Web项目，光配置Spring和MyBatis的xml文件就能耗掉半天，数据源、事务、扫描包、拦截器全部要手搓。Spring Boot最大的价值不是“新”，而是把那些重复劳动统一收口了。

登山用品商城这类项目，需求相对清晰：商品展示、用户登录、加购下单、后台管理。用Spring Boot做，好处有三个：

第一，起步快。引入spring-boot-starter-web之后，只要一个带@SpringBootApplication注解的启动类，内置Tomcat直接跑，不需要再单独部署外部容器。这对课程设计和毕设来说特别友好，演示的时候一个命令就能启动。

第二，生态整合省心。MyBatis、Redis、Minio、JWT这些组件都有对应的starter或者自动配置类，yml里配几个参数就能用。项目源码27394里用的也是这套思路，除了一些特殊配置，基本不需要碰JavaConfig复杂代码。

第三，分层结构清晰。Controller、Service、Mapper、Entity按包划分，和团队协作、后期维护的节奏都比较匹配。就算以后要拆微服务，边界也容易划清楚。

选型不一定要追求最新版本，关键是稳定。Spring Boot 2.7.x配合JDK8，这是目前校园环境里兼容性最好的组合。如果硬上Spring Boot 3.x，JDK版本不够或者依赖不兼容，反而会让项目跑不起来。

1.2 核心功能模块拆解

这个项目把商城拆成了两套端：前台用户端和后台管理端。前台用户端给普通用户用，后台给管理员维护数据。

用户模块主要负责注册、登录、个人信息维护和收货地址管理。登录状态用JWT处理，前端拿到token后放到请求头里，后端通过拦截器统一校验，不用像传统Session那样担心跨域丢登录态。

商品模块是重点，包含三级分类、商品列表、商品详情、关键字搜索、排序和分页。登山用品分类很典型：服装、鞋子、背包、帐篷、登山杖、照明工具等。分类表设计了父子关系，支持无限级展开。商品表里除了基础信息，还有主图、轮播图和富文本详情。图片不存本地，而是统一上传到Minio对象存储，这样服务器扩容和静态资源分离都很方便。

购物车和订单模块是电商的核心链路。购物车支持勾选商品、修改数量、批量删除。订单模块从提交订单开始，生成订单号和订单明细，扣减库存，然后进入支付环节。这个项目里没有接入真实支付渠道，用的是模拟支付回调，把订单状态从待支付改成已支付，对毕设和练手来说已经足够。

后台管理模块主要做商品分类管理、商品上下架、库存调整、订单处理（发货、取消）和用户列表管理。页面不复杂，但接口逻辑和后端一样，该做的权限校验都做了。

1.3 技术栈选型与理由

整个项目的技术栈可以总结成下面这张表：

选MyBatis Plus是因为商城项目里大量操作都是单表查询，比如按分类查商品、按用户查订单，用Plus自带的Wrapper能省掉很多重复SQL。订单模块这种多表关联的就保留XML手写SQL，灵活性还是需要的。

Redis在项目里承担了两方面工作：一是存登录token，二是做热门商品的缓存。严格说，一个小型商城的商品数据直接查MySQL也没问题，但演示的时候为了让项目看起来更有说服力，Redis还是要用上。

Minio最开始我犹豫过，因为本地文件存储更简单。后来考虑到图片多了以后目录会特别乱，而且打包部署时windows和linux路径处理起来很麻烦，换Minio以后所有图片都通过接口上传和回显，环境一致性好了非常多。这部分源码27394里有完整的工具类和上传Controller，后面会专门讲到。

2. 数据模型与核心表设计

2.1 商品分类与商品信息表设计

商城项目里，表结构设计比代码更重要，因为后续所有接口都是围绕表来写的。这个项目的分类表结构很直接：

CREATE TABLE category ( id BIGINT PRIMARY KEY AUTO_INCREMENT, parent_id BIGINT DEFAULT 0, name VARCHAR(50) NOT NULL, sort INT DEFAULT 0, status TINYINT DEFAULT 1 );

parent_id为0表示一级分类，子分类的parent_id指向父分类id。查询的时候可以先查一级分类，再通过parent_id查子分类。登山用品商城里典型的分类关系是：户外服装下面有冲锋衣、抓绒衣、速干衣；登山鞋下面有徒步鞋、攀岩鞋、高山靴。

商品表我习惯把统一信息放主表，差异化属性放扩展表。这个项目里商品主表长这样：

CREATE TABLE product ( id BIGINT PRIMARY KEY AUTO_INCREMENT, category_id BIGINT NOT NULL, name VARCHAR(120) NOT NULL, subtitle VARCHAR(200), main_image VARCHAR(255), detail_html TEXT, price DECIMAL(10,2) NOT NULL, stock INT NOT NULL DEFAULT 0, sales INT NOT NULL DEFAULT 0, status TINYINT DEFAULT 1, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );

price字段用DECIMAL而不是FLOAT，这一点非常重要。MySQL里FLOAT存在精度丢失问题，做金额计算时会出现0.1+0.2不等于0.3的情况。DECIMAL(10,2)虽然存储上多了点空间，但金额精度有保障。

商品图片不止一张，所以项目里还有product_image表，product_id和image_url一一对应。dedetail_html存的是富文本编辑器的内容，包含商品参数、装备介绍、使用建议等长文本信息，用TEXT类型足够。

索引设计上，category_id是查询最频繁的字段，一定要加索引；price和sales用于排序，可以加普通索引；商品名用模糊搜索，数据量不大时LIKE '%关键字%'可以接受，如果以后数据量上来了再考虑全文索引或ES。

2.2 购物车与订单流转表设计

购物车表设计相对简单，核心字段是用户id、商品id、购买数量、选中状态。

CREATE TABLE cart_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, product_id BIGINT NOT NULL, quantity INT NOT NULL DEFAULT 1, checked TINYINT DEFAULT 1, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_user_product (user_id, product_id) );

给user_id和product_id加上唯一索引，同一用户同一商品只能有一条记录。用户重复添加商品时，直接在原记录上增加数量，避免数据重复。

订单表是整个项目里逻辑最复杂的部分。订单主表和订单明细表分开设计，这是电商项目的基本常识。订单主表存一次订单的整体信息：订单号、用户id、总金额、状态、收货地址快照、支付时间、发货时间等。订单明细表存这个订单里每一个商品的快照信息：

CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, user_id BIGINT NOT NULL, total_amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0, receiver_name VARCHAR(50), receiver_phone VARCHAR(20), receiver_address VARCHAR(200), create_time DATETIME DEFAULT CURRENT_TIMESTAMP, pay_time DATETIME, UNIQUE KEY uk_order_no (order_no) ); CREATE TABLE order_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, product_id BIGINT NOT NULL, product_name VARCHAR(120), product_image VARCHAR(255), price DECIMAL(10,2) NOT NULL, quantity INT NOT NULL );

为什么订单明细要存product_name和product_image？因为商品名称和图片是可能会变的，尤其是管理员修改商品名称后，历史的订单里不该跟着变。把下单时的商品快照存下来，才能保证订单数据的历史一致性。

订单状态用TINYINT数字表示，0待支付、1已支付、2已发货、3已完成、4已取消。用数字比用字符串好维护，前端再通过字典翻译成文案。

2.3 用户与权限的数据落地方式

用户表就是最常规的设计：

CREATE TABLE user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL, password VARCHAR(100) NOT NULL, nickname VARCHAR(50), phone VARCHAR(20), avatar VARCHAR(255), role TINYINT DEFAULT 0, status TINYINT DEFAULT 1, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_username (username) );

role字段区分角色，0是普通用户，1是管理员。这个项目没有把角色拆成单独的表，因为商城业务里角色就两种，拆表反而多余。如果是做权限要求更高的后台系统，再引入Spring Security加RBAC也不迟。

密码字段存的是BCrypt加密后的结果，绝对不允许明文存储。Spring Security里自带BCryptPasswordEncoder，用起来很方便。注册时把明文密码编码后写入数据库，登录时用matches方法校验。

登录之后的鉴权我选择了JWT配合自定义拦截器的方式。相比完整引入Spring Security，轻量拦截器更容易看懂，也方便在学习过程中调试。JWT好在服务端不存状态，对前后端分离和横向扩展都友好，缺点是token无法主动失效，所以项目里还设置了过期时间。

3. 源码运行：从下载到跑起来

3.1 源码目录结构解读

整个项目分成后端和前端两个部分，后端是Maven工程，前端是Vue工程。拿到源码27394后，能明显看到目录结构是有意整理过的：

springboot-shopping ├── backend │ ├── src/main/java/com/shop │ │ ├── config # 配置类：跨域、拦截器、MyBatis Plus分页 │ │ ├── controller # 接口层 │ │ ├── service # 业务逻辑层 │ │ ├── mapper # MyBatis Plus Mapper接口 │ │ ├── entity # 数据库实体类 │ │ ├── common # 通用返回结果、异常处理、常量 │ │ └── util # JWT工具、Minio工具、文件上传工具 │ └── src/main/resources │ ├── mapper # XML SQL文件 │ ├── application.yml │ └── sql/shop.sql └── frontend ├── src │ ├── api # 接口调用封装 │ ├── views # 页面组件 │ ├── router # 路由配置 │ ├── store # 状态管理 │ └── main.js └── package.json

我特别说一下common包里的统一返回结果。所有Controller接口返回的都不是裸数据，而是类似Result.success(data)的封装结构。前端通过统一结构判断请求是否成功，后端在全局异常处理器里把异常也统一成这种结构。这样前后端对接时字段格式一致，排查问题省事很多。

3.2 数据库初始化与yml配置

先把sql/shop.sql导入MySQL，这个脚本创建了数据库和所有数据表，还插入了一些登山用品的基础分类和测试商品数据。导入之后，重点修改后端resources下的application.yml：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/mountain_shop?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: 123456 redis: host: localhost port: 6379 database: 0 mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

MySQL 8和高版本的连接驱动，必须带serverTimezone参数，否则时间字段会出现8小时的时区偏差。useSSL=false也建议加上，本地开发环境不需要走SSL握手。MyBatis Plus打开map-underscore-to-camel-case后，数据库字段update_time就能自动映射到实体类的updateTime，不需要手动写resultMap。

Redis如果本地没装，项目启动时会报连接失败。可以先确认Redis服务是否启动。如果只是想先跑通后端接口，也可以把Redis相关的登录校验逻辑暂时注释掉，但正式演示最好还是把Redis装好。

3.3 Maven构建和前端Vue打包

后端构建比较简单，在backend目录执行：

mvn clean package -DskipTests

构建完成后，target目录下会生成一个可直接运行的jar包。第一次构建时Maven会下载大量依赖，如果网络不好可能要等一会儿。这里建议配置阿里云Maven镜像，能明显加快依赖下载速度。

前端是Vue项目，需要先安装依赖。进入frontend目录执行：

npm install npm run build

npm install如果报错，可以先检查Node版本。Vue 2项目建议Node 14到16之间，太高或太低都可能出现依赖兼容问题。构建完成后，dist目录就是打包好的静态文件。

为了让前端能跟后端一起部署，项目里配置了把dist目录的内容复制到后端的static目录，这样最终只需要启动一个Spring Boot应用，访问8080端口就能看到商城页面，不需要单独部署Nginx。这个思路对毕设演示特别实用。实际项目用的是maven-resources-plugin，在pom.xml里做了资源拷贝，也可以用脚本手动复制。

前端调用后端接口时，Vue项目开发环境通过proxy把/api开头的请求转发到localhost:8080，生产环境则直接请求同源地址。跨域问题在后面单独说。

3.4 Minio对象存储的接入位置

Minio在这个项目里承担图片存储任务。先在本地安装Minio服务，默认端口9000，控制台端口9001。然后创建一个bucket，比如shop-image。

后端接入需要引入Minio Java SDK，在pom.xml里添加依赖：

<dependency> <groupId>io.minio</groupId> <artifactId>minio</artifactId> <version>8.4.3</version> </dependency>

application.yml里加配置：

minio: endpoint: http://localhost:9000 access-key: admin secret-key: admin123 bucket-name: shop-image

写一个MinioConfig把客户端Bean注入容器，再写一个MinioUtil提供上传和获取URL的方法。上传接口的典型写法是接收MultipartFile，生成随机的文件名，用putObject保存到Minio，最后返回可访问的图片地址。

这里踩过的坑是图片回显：如果Minio bucket权限是private，前端img标签访问图片地址会直接403。开发阶段最简单的办法是把bucket的访问策略设置成public，所有图片通过endpoint加文件名直接访问。如果后续要控制权限，再考虑生成临时的预签名URL。

4. 核心业务逻辑与实现细节

4.1 登录鉴权与Spring Security集成

这个项目没有引入全套Spring Security，只使用了其中的BCrypt工具类，其他鉴权逻辑是手写拦截器实现的。这样做的好处是代码运行链路清晰，适合学习。

登录流程是这样的：用户提交用户名和密码，后端从数据库查出用户，用BCryptPasswordEncoder校验密码。校验通过后，生成JWT字符串，里面存放userId和username，设置过期时间比如24小时，然后把token返回给前端。

String token = Jwts.builder() .setSubject(username) .claim("userId", user.getId()) .setExpiration(new Date(System.currentTimeMillis() + 24 * 60 * 60 * 1000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();

前端把token存到localStorage，请求时放到Authorization请求头。后端拦截器拦截所有需要登录的接口，从请求头解析token，解析失败直接返回401。商品浏览、分类查询这些公开接口要放在拦截器白名单里，否则用户还没登录就什么都看不了。

拦截器里特别要注意的是放行规则。登录接口、注册接口、商品列表、商品详情、图片访问这些必须放行，购物车、订单、个人中心必须拦截。我用的是AntPathMatcher配置路径规则，类似/api/auth/**放行，/api/cart/**拦截这种。

4.2 商品搜索与分页查询

商品列表页是商城访问量最大的接口，涉及分类筛选、关键字搜索、价格排序和分页。项目里用MyBatis Plus的LambdaQueryWrapper实现，结构很清爽：

LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>(); if (categoryId != null) { wrapper.eq(Product::getCategoryId, categoryId); } if (StringUtils.hasText(keyword)) { wrapper.like(Product::getName, keyword); } if ("price_asc".equals(sort)) { wrapper.orderByAsc(Product::getPrice); } else if ("price_desc".equals(sort)) { wrapper.orderByDesc(Product::getPrice); } else { wrapper.orderByDesc(Product::getSales); } Page<Product> page = new Page<>(pageNum, pageSize); productMapper.selectPage(page, wrapper);

分页插件需要配置MyBatis Plus的PaginationInnerInterceptor，在config包下加一个MybatisPlusConfig类。用Page对象接收返回结果，前端就能拿到total、pages、current等分页信息。

这里有个容易被忽略的点：分类筛选时，如果选了二级分类，不能只查product表里category_id等于该分类的商品，还要处理分类id变化的情况。比如后台把商品从一个子分类移到另一个子分类，接口查询条件要跟着对。

商品搜索还有一个细节是热门商品的Redis缓存。商品详情接口先从Redis查，查不到再查数据库并回填缓存，同时设置过期时间。这样并发访问爆款商品时，数据库压力会小很多。

4.3 订单创建与库存扣减的并发处理

商城项目最容易翻车的地方是订单和库存。两个用户同时买同一个商品，如果代码写了先select查库存再update扣库存，一定会出现超卖。

这个项目采用的方案是数据库层面的原子扣减。创建订单时，直接执行类似这样的SQL：

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

这条SQL的返回值是影响行数。如果影响行数为0，说明库存不足，事务回滚，下单失败。这样不用加锁，也能在并发场景下保证不超卖。这个方法看起来简单，但效果非常可靠，适合大多数电商场景。

订单创建整体要加@Transactional注解。整个方法涉及查询商品、校验库存、扣减库存、生成订单号、插入订单主表、插入订单明细、清空购物车，任何一步失败都要回滚，否则会出现订单生成了但库存没扣，或者库存扣了但订单没生成的情况。

关于订单号，项目里用时间戳加随机数生成，格式类似20250101120000123456。订单号有一个唯一索引，即便高并发下生成的订单号也要保证不重复。我用的是UUID去掉横线再截取一部分拼接时间戳，后来觉得麻烦，干脆用Redis自增或数据库乐观锁生成。演示项目用时间戳加随机字符串完全够用。

支付环节做的是模拟支付。用户点击支付按钮后，后端把订单状态从待支付修改为已支付，记录支付时间。如果要接真实支付，只需要在支付回调接口里做同样的状态更新逻辑，项目结构可以平滑扩展。

5. 常见问题与排查实录

5.1 Spring Boot版本过高怎么处理

很多同学拿到源码后直接改版本号，结果编都编不过。如果当前环境是JDK8，却把Spring Boot版本改成了3.0以上，启动会直接报UnsupportedClassVersionError或者java.lang.NoClassDefFoundError。

Spring Boot 3.x基于Jakarta EE，包名从javax.servlet变成了jakarta.servlet。很多老项目里import javax.servlet.http.HttpServletRequest的地方全部要改包名。同时MyBatis Plus 3.5.3之前的版本对Spring Boot 3的支持也不够，需要升级到对应的starter版本。

我的建议是：课程设计和毕设环境用Spring Boot 2.7.x，稳定且资料多。不需要盲目追求新版本，项目能跑、逻辑能讲清楚才是最重要的。

5.2 前端请求跨域与静态资源404

前后端分离开发时，前端启动在8081端口，后端在8080端口，浏览器直接从8081发起/api请求会跨域。解决方式有两种：一种是前端配置Vue的proxy，让/api代理到后端，浏览器看到的是同源请求；另一种是后端配置CORS，允许跨域访问。

后端CORS配置可以继承WebMvcConfigurer，重写addCorsMappings方法，允许所有来源和方法，放开所有路径。生产环境建议把allowedOrigins换成具体域名，不然会有安全隐患。

还有一个常见问题：前端打包放到后端static目录后，页面刷新出现404。这通常是因为Vue Router启用了history模式，浏览器访问/user/detail路径时，后端没有对应的Controller，自然返回404。解决办法有两种：一是把Vue Router改成hash模式，URL变成带#的形式；二是后端添加一个转发Controller，把所有非api路径转发到index.html。演示项目为了省事，基本都是改hash模式。

5.3 Minio连接失败的排查

Minio出问题时的表象往往是商品图片上传失败或者图片加载不出来。排查首先看Minio服务是否正常启动，浏览器访问endpoint能不能打开控制台。如果控制台都打不开，检查服务进程和9000端口监听情况。

其次看accessKey和secretKey是否正确。Minio控制台里显示的Access Key对应的Secret Key是固定的，如果你重置过密钥，一定要同步更新到yml里。

还有一类坑是时间不同步。服务器和Minio所在机器时间相差太大会导致签名校验失败，报错信息通常是RequestTimeTooSkewed。做部署时，统一用NTP同步一下系统时间就能解决。

最后是bucket权限。开发阶段为了省事，我建议把bucket设为public。如果设成private，前端img标签访问时就得走预签名URL，逻辑会复杂一层。

5.4 数据库字段变更后的兼容

项目跑了一段时间后，难免要加字段，比如给商品表加一个is_hot标识热门商品。最简单的做法是执行alter table，同时修改实体类加一个字段。要注意MyBatis Plus的驼峰映射会自动把is_hot映射为isHot，实体类用isHot命名即可，不需要改XML。

如果有多个人一起开发，或者项目上线需要管理数据库变更，最好用Flyway或Liquibase这类工具。但毕设项目一般不需要引入，手动执行SQL加README说明就够了。

有一点必须提醒：实体类字段类型和数据库字段类型要保持一致。Java的LocalDateTime对应MySQL的DATETIME，如果数据库用DATE类型，查询时可能出现类型转换异常。这类问题在替换数据库版本时特别常见。

6. 部署与优化经验

6.1 打包部署到服务器的基本流程

运行这个商城项目到服务器，不需要太复杂的环境。先装好JDK8、MySQL、Redis和Minio，然后数据库导入sql文件。把后端打包好的jar包传到服务器，启动命令：

nohup java -jar shop-0.0.1-SNAPSHOT.jar --spring.profiles.active=prod > shop.log 2>&1 &

生产环境我会把配置文件里的账号密码、密钥都抽到application-prod.yml里，避免默认配置泄露。启动后先看日志有没有报错，再访问接口确认状态。

如果前端没有打进jar包，就需要用Nginx托管dist目录，同时把/api反向代理到后端8080端口。一个简单的Nginx核心配置：

server { listen 80; server_name your-domain.com; root /var/www/shop/dist; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

本地演示用jar包内置static页面的方式最省事；正式部署用Nginx分离静态资源更灵活。两者不冲突，可以根据场景选。

6.2 性能与安全方面的几个小改动

商城项目虽然小，但一些基本的安全习惯还是应该养成。密码必须加密存储，项目里用的BCrypt，注册登录都不能给明文密码开绿灯。接口层面做了参数校验，比如商品数量不能为负数、价格不能超过合理范围，避免脏数据进入数据库。

Redis缓存热门商品时，要注意缓存穿透问题。如果用户反复查一个不存在的商品id，每次都打到数据库，可以在缓存里存一个空值并设置很短过期时间，或者用布隆过滤器解决。演示项目用空值缓存就够了。

上传图片时一定要限制文件类型和大小。只允许jpg、png、webp这类图片格式，不能允许上传jsp、html等文件。文件大小限制建议放在Spring配置里，spring.servlet.multipart.max-file-size设为10MB，防止有人传超大文件撑爆磁盘。

6.3 后续可以扩展的方向

如果这个项目要做成更能打的毕设，可以在现有基础上接上支付功能，支付宝和微信支付的沙箱环境都能用来演示。订单超时未支付自动关闭，可以用DelayQueue、定时任务或者RocketMQ延迟消息实现，推荐从定时任务扫表方案入手，逻辑最直观。

商品模块还可以加评价系统，用户下单完成之后对商品打分并评论，这会让项目完整度和答辩素材都丰富很多。登山用品商城还有一个比较有特色的点：装备推荐。根据用户浏览历史和购买记录，推荐相关装备，比如买了登山鞋就推荐登山袜和鞋垫，用简单的标签匹配就能做。

这些都是“加分项”，不建议一开始就铺开。先把订单、库存、支付回调这条主链路跑通，再增加周边功能，这样开发节奏不会乱。

做这个源码整理的过程中，我把很多实际运行时才暴露的坑都补上了注释。像数据库时区、FastJson漏洞、分页插件失效、前端刷新404这些问题，代码里基本都有对应处理。如果你准备拿Spring Boot做一个类似的电商项目，建议先跑一遍这套代码，再结合自己的需求去改表结构和接口。踩过一轮坑之后，你对Spring Boot的理解绝对会比只看文档扎实得多。