Spring Boot商城后端源码从环境配置到项目改造实战指南

简介基于Spring Boot框架的网上购物商城后端系统源码面向Java初学者、需要快速实现小型电商后端的学生或开发者。项目涵盖购物车、客服、地址、商品评论等核心业务模块使用MyBatis Plus操作数据库提供增删改查、分页查询、条件查询、详情查询以及提醒等通用接口地址模块还可获取默认地址客服与评论模块均支持完整的管理操作。压缩包共772个文件大小约14.62MB文件类型以Java源码、Vue组件、JavaScript、CSS样式、SVG图标为主并包含SQL数据库脚本、XML配置文件等前后端结构完整清晰。目前已有87人学习下载。源码可直接用于课程设计、毕业设计或小型电商项目的二次开发既能帮助理解Spring Boot与MyBatis Plus的整合方式也可参考其中接口设计、统一响应格式与分页逻辑快速落地实际功能。1. 一个商城后端源码包为什么值得你从解压开始重走一遍拿到这个(源码)基于Spring Boot框架的网上购物商城后端系统.zip时你面对的不只是几个 Controller而是一个至少包含用户、商品、购物车、订单、库存等模块的完整后端工程。我第一次解压这种压缩包也翻过车配置文件没改、数据库没导甚至不知道.sql文件放在哪一层目录最后卡在启动日志里反复看同一个异常。我的建议是别把它当黑匣子直接跑而是从上到下重走一遍先理清模块划分再配环境、启动、改代码。这篇文章按这条路径来写覆盖最小启动命令、核心表设计、事务边界、常见异常排查和监控接入。适合谁刚学完 Spring Boot 想做商城实战的入门者以及拿到课程设计源码但被环境折腾到怀疑人生的同学。如果你已经有几年后端经验重点看第五章避坑和第六章压测与升级就够了。2. 拿到 Spring Boot 商城压缩包后环境准备与最小启动命令2.1 先看包内目录和 pom.xml再决定 JDK 与 Maven 版本解压后第一件事不是双击 pom.xml而是先看目录层级。常见商城后端源码有两种形态单模块应用所有代码在src/main/java下按controller、service、mapper、entity分包多模块工程例如mall-common、mall-admin、mall-member、mall-order。多模块通常还要看根目录的pom.xml里modules标签确认哪几个子模块是启动入口哪几个只是公共库。为什么先看版本Spring Boot 版本直接决定你能用的 Java 版本和配置语法尤其 Spring Boot 2.3.x 与 2.6.x 差异很大。2.6 以后默认用PathPattern解析路径以前写/api/**/*.do这类 Ant 风格路径会失效Spring Boot 3.x 更是把包名从javax换成jakarta。所以先用 Maven 直接读出版本比打开文件用眼找 parent 更可靠# 在项目根目录执行先看 parent 版本 mvn help:evaluate -Dexpressionproject.parent.version -DforceStdout -q-Dexpression是 Maven Help 插件读取 POM 属性的标准方式-DforceStdout强制把结果直接打到终端-q让 Maven 不刷进度条。如果这个项目没有 parent命令会输出null这时执行mvn help:evaluate -Dexpressionproject.version -DforceStdout -q看自身版本。注意多模块项目要先cd到子模块目录或者用-pl指定模块否则读不到子模块的 parent。拿到版本后按下面的组合选环境Spring Boot 版本建议 JDK建议 Maven启动前重点检查2.3.xJDK 8 或 113.6MySQL 驱动版本、Servlet API2.6.xJDK 8/11/173.6spring.mvc.pathmatch.matching-strategy3.xJDK 173.8javax是否已改成jakarta如果你的源码标着 2.3.x就不要图新鲜升到 3.x否则一堆import javax.servlet会全部标红。老项目老老实实用 JDK 8跑通的概率最高。多模块工程还有一个隐藏坑子模块之间用的是本地依赖第一步要先mvn clean install -DskipTests把mall-common这类公共包装进本地 Maven 仓库后面启动子模块时才能找到依赖 jar。2.2 用 IntelliJ IDEA 社区版导入源码避免红头文件的三处配置很多人问“IntelliJ IDEA 社区版怎么用 Spring Boot”。答案很简单社区版没有 Spring Initializr 的图形模板但不影响跟 Spring Boot 工程因为它是 Maven 项目。导入时选择File - New - Project from Existing Sources找到根目录pom.xmlIDEA 会按 Maven 方式解析。导入后如果 pom 里全是红色波浪线第一步不是重装软件而是检查三处IDE 使用的 JDK、Maven 的 JDK、Maven 的 settings.xml。在Settings - Build Tools - Maven - Importing里把“JDK for importer”切到本机安装的 JDK 8 或 11再到Settings - Build Tools - Maven - Runner把 JRE 指到同一个 JDK。很多“项目跑不起来”实际是 IDEA 用了内置 JBR 而不是你安装的 JDK导致 Maven 编译时找不到tools.jar。源码里如果有.mvn/wrapper/maven-wrapper.properties说明作者希望用 Maven Wrapper 固定版本。我一般会让 IDEA 选择mvnw而不是系统 Maven这样其他同事拿到代码也不会因为本机 Maven 版本不一致而崩溃。如果没有mvnw就用系统 Maven但要在 Mavensettings.xml里配好镜像源避免第一次加载依赖卡在下载阶段。2.3 初始化 MySQL 数据库并修改 application.yml第一次启动成功商城后端一定连数据库常见组合是 MySQL MyBatis或 MyBatis-Plus。源码包里一般会带.sql文件名字不外乎mall.sql、database.sql、db_mall.sql。找出来之后先看里面的建库语句绝大多数不会包含CREATE DATABASE要自己建库再导入# 创建 utf8mb4 数据库 mysql -uroot -p -e CREATE DATABASE mall DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; # 导入表结构和测试数据 mysql -uroot -p mall mall.sql建库用utf8mb4是因为商城商品名称、用户备注会有 emoji 和生僻字utf8只能存 3 字节存不进四字节字符。导入成功后打开src/main/resources/application.yml也有部分工程用application.properties改三处数据源、Redis、端口。最关键的数据库配置长这样spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/mall?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue username: root password: 123456参数说明serverTimezoneAsia/Shanghai解决 MySQL 8 与 JDBC 的时区冲突不然日志会报The server time zone value йʱ这种乱码useSSLfalse是本地开发关掉 SSL 握手免得提示证书警告allowPublicKeyRetrievaltrue是配合 MySQL 8 的caching_sha2_password认证老版本驱动没这个参数也能跑加上更顺。启动前先打包避免 IDEA 编译和 Maven 编译不一致mvn clean package -DskipTests java -jar target/xxx.jar --spring.profiles.activedev如果源码只有一个启动类也可以直接在 IDEA 里右键运行。看到类似Tomcat started on port(s): 8080 (http)和Started MallAdminApplication的输出说明环境通了。第一次启动如果秒退出先用mvn clean package看 Maven 日志大多数问题在依赖下载和数据库连接。还可以用--debug参数启动Spring Boot 会输出自动配置报告你能直接看到DataSourceAutoConfiguration里哪一步没满足条件。3. 网上购物商城的后端骨架表结构、接口与事务边界3.1 五张核心表的关系从用户到订单的数据流商城后端纵有几十张表核心链路离不开这几张。我通常用一张表帮新人记忆表作用关键字段user会员、登录账号、收货信息id, username, password, phonecategory商品分类id, parent_id, nameproduct商品基本信息id, category_id, name, price, stockcart_item购物车id, user_id, product_id, quantityorder_master订单主表id, user_id, status, total_amountorder_item订单明细id, order_id, product_id, quantity, snapshot_price注意点order_item里要保存下单时的商品价格快照而不是关联product.price实时查。因为商品可能改价订单详情必须对当时的价格负责。很多课程设计源码偷懒不设计快照字段等运营改价后就对不上账这是源码从“能跑”到“能用”的分水岭。我还会在商品表加一个version字段用于并发控制DDL 大概是这样的CREATE TABLE product ( id bigint NOT NULL AUTO_INCREMENT, category_id bigint DEFAULT NULL, name varchar(128) NOT NULL, price decimal(10,2) NOT NULL, stock int NOT NULL DEFAULT 0, version int NOT NULL DEFAULT 0, created_at datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;价格字段必须用DECIMAL(10,2)不要用float或double。二进制浮点在做金额累加时会出现 0.10.20.30000000000000004财务核算时会被当成 bug。stock用int并配合后面的条件 UPDATE比应用层select再update可靠得多。version是留给乐观锁的如果源码里没有这个字段后面遇到超卖问题再补也可以但 DDL 迁移要小心。3.2 REST 接口怎么设计加购、下单、支付回调的路径与请求方式商城后端接口通常按资源路径前缀区分给客户端一个明确约定/api/user/**处理会员/api/product/**处理商品/api/cart/**处理购物车/api/order/**处理订单/api/pay/**处理支付回调。如果源码里面直接用/user/register而没有/api前缀建议在后面改造时统一加上前端反代规则会更好做。一个最小但完整的购物流程接口是这样一组方法路径说明POST/api/user/register注册校验手机号、密码长度POST/api/user/login登录返回 TokenGET/api/product/list按分类/关键字分页搜商品POST/api/cart/add加购POST/api/order/create从购物车或立即购买下订单POST/api/pay/callback支付平台回调接口的实现方式我建议 Controller 里只做参数接收和结果包装不要让 Controller 直接操作 Mapper。一个常见的最小 Controller 骨架RestController RequestMapping(/api/order) public class OrderController { private final OrderService orderService; public OrderController(OrderService orderService) { this.orderService orderService; } PostMapping(/create) public ResultLong create(RequestBody Valid CreateOrderRequest request) { return Result.ok(orderService.create(request)); } }Valid会触发CreateOrderRequest里的NotBlank、Min这类校验注解避免参数异常落到 Service 层。ResultT统一包装返回值前端只需要判断data.code。很多源码里直接用 Map 返回短期方便时间长了字段名对不上所以第四章我会专门讲统一返回体改造。分页查询时还要注意参数命名统一。我见过一个项目里pageNum和currentPage混着用前端联调时翻车。做商城后端接口一旦定下来就尽量别改字段名宁可新增一个pageParam也不要破坏原有契约。3.3 Service 层事务与 Mapper 的防超卖 SQL下单是购物商城后端的核心事务至少涉及扣库存、生成订单、清购物车三个动作。Spring 的Transactional是一个基于 AOP 的实现但很多人把它当成“加上就完事”实际上注解只有通过 Spring 管理的 Bean 外部调用时才生效。如果你在同一个类里A()方法调用同类里的B()方法并且B()上面标了Transactional事务不会生效这是一个非常隐蔽的翻车点。我常用的下单方法结构如下Transactional(rollbackFor Exception.class) public Long createOrder(CreateOrderRequest request) { // 扣库存返回 0 表示库存不够 int rows productMapper.deductStock(request.getProductId(), request.getQuantity()); if (rows 0) { throw new BizException(库存不足); } // 生成订单主记录和明细 OrderMaster order new OrderMaster(); order.setUserId(request.getUserId()); order.setStatus(OrderStatus.CREATED); orderMasterMapper.insert(order); // 清掉购物车中已下单的商品 cartMapper.deleteByUserIdAndProductId(request.getUserId(), request.getProductId()); return order.getId(); }注意rollbackFor Exception.classSpring 默认只回滚RuntimeException如果BizException是检查异常不写这个参数就会导致库存扣了但订单没建成功。另一件容易忽略的事deductStock必须是一条原子 UPDATE而不是先select stock判断再update。后者在并发时超卖。对应的 Mapper XML 写成这样update iddeductStock UPDATE product SET stock stock - #{quantity} WHERE id #{productId} AND stock #{quantity} /update这里stock #{quantity}放在 WHERE 里InnoDB 会对命中的行加锁只有当库存足够时才更新成功返回影响行数 1库存不足返回 0。配合外面的Transactional扣库存失败抛出异常订单记录整体回滚不会留下半截数据。这个写法不需要select ... for update对冲突少的商城场景足够也是课程设计里最容易让新手抄明白的版本。如果源码用的是 MyBatis-Plus可以在 Service 里用LambdaUpdateWrapper实现同样的条件更新但需要注意默认的updateById不会带stock #{quantity}条件不能直接用来扣库存。你说你在改造时换成 Redis 预扣也行但那要处理返回自增 ID、超时回滚补偿复杂度上了一个台阶。4. 从“别人的源码”到“自己的后端”确定要做的四项改造4.1 统一返回体和全局异常处理前端联调不再猜字段源码第一次启动后你最该做的第一项改造是统一返回结构。商城前端H5、小程序、App需要稳定的 JSON 协议。如果每个 Controller 各返回各的前端联调时看到一会是code/message/data一会是{success: true}心态会崩。常见的统一返回体是一个泛型类public class ResultT { private int code; private String message; private T data; public static T ResultT ok(T data) { return new Result(0, ok, data); } public static T ResultT error(int code, String message) { return new Result(code, message, null); } }只做这个还不够还要配全局异常处理把 Service 层抛出的业务异常翻译成 JSON而不是让 Spring 默认返回 Whitelabel 错误页。我用RestControllerAdvice拦异常RestControllerAdvice public class GlobalExceptionHandler { ExceptionHandler(BizException.class) public ResultVoid handleBiz(BizException e) { return Result.error(e.getCode(), e.getMessage()); } ExceptionHandler(MethodArgumentNotValidException.class) public ResultVoid handleValid(MethodArgumentNotValidException e) { String msg e.getBindingResult().getFieldError().getDefaultMessage(); return Result.error(400, msg); } }BizException是业务自定义异常库存不足、重复支付这类情况都靠它抛。参数校验异常单独处理直接把第一个校验失败原因返回给前端比让前端猜密码长度规则更友好。注意code不要直接用 HTTP 状态码比如“库存不足”业务码设为 20001前端只要判断code 0成功其他统一弹提示。这样 HTTP 状态码始终是 200避免反代层把 4xx 当成故障。4.2 登录鉴权改造先确认单点登录还是 JWT很多商城源码的鉴权写得很随意比如在 Controller 里用session.getAttribute(userId)或者每个方法都手动从参数拿 token。如果要接到小程序或 H5我建议改成无状态 JWT。先不用上 Spring Security因为那会引入大量配置新手很容易在这里翻车。用拦截器是最轻量的落地方案。public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 浏览器跨域预检请求没有 Authorization必须放行 if (OPTIONS.equalsIgnoreCase(request.getMethod())) { return true; } String token request.getHeader(Authorization); Long userId JwtUtil.parseToken(token); if (userId null) { response.setStatus(401); return false; } UserContext.set(userId); return true; } }这里的UserContext用ThreadLocal保存当前登录用户Service 层需要用户 ID 时直接UserContext.get()。注意拦截器返回 false 前要设置响应状态码很多源码直接 return false前端拿到的是一堆空白页很难排查。注册到配置类时要明确放行哪些路径Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new AuthInterceptor()) .addPathPatterns(/api/**) .excludePathPatterns(/api/user/login, /api/user/register, /api/product/**, /api/pay/callback/**); }商品列表和支付回调必须放行否则用户没登录连商品都看不见支付平台回调也进不来。JWT 的过期时间建议设 2 小时不要为了省事设成 30 天商城恢复登录态可以用 refresh token 续签而不是把一个长有效期 token 放在前端。4.3 给第三方提供的支付回调接口放当前应用还是独立服务网上经常有人问“Spring Boot 对外提供的接口给第三方应该放在哪里是单独服务还是放在对应模块”。支付回调就是典型问题。我的判断标准是这个第三方接口是否只服务于当前应用内部的订单模块。如果答案是“是”那就放在当前应用的独立controller里用专门的/api/callback/前缀和其他业务接口隔离如果回调要触发积分、消息推送、库存同步等多个模块且这些模块已经拆分成独立服务那就把回调单独做成一个轻量服务避免其他服务挂掉导致回调失败。回调 controller 有几个细节特别容易踩坑。一个代码骨架RestController RequestMapping(/api/callback/payment) public class PaymentCallbackController { PostMapping(/notify) public String notify(RequestBody String plainText) { // 第一步验签失败直接返回错误报文 // 第二步按 outTradeNo 查订单做幂等处理 // 第三步修改订单状态并返回 SUCCESS return SUCCESS; } }注意这里不能返回商城自己的ResultT支付平台要求的是它规定的纯文本SUCCESS或FAIL。另外回调接口必须做幂等支付平台因为网络原因会重复推送同一笔订单通知如果你的逻辑是先查订单状态再更新并发重复回调时可能把已完成的订单覆盖成“支付中”。最简单做法是在订单表加一个唯一索引out_trade_no重复插入会直接异常然后在 catch 里返回 SUCCESS。4.4 用 Spring Boot Admin 和 Actuator 监控商城接口商城上线后最怕接口悄悄变慢或者线程池被打满。Spring Boot Admin 配合 Actuator 可以给后端做实时监控而且它的接入成本很低。先在商城应用的 pom 里加依赖版本沿用项目的 Spring Boot 版本不要单独指定一个很高的数字dependency groupIdde.codecentric/groupId artifactIdspring-boot-admin-starter-client/artifactId /dependency然后在 application.yml 里把 Admin Server 地址指过去spring: boot: admin: client: url: http://localhost:9090 management: endpoints: web: exposure: include: health,metrics,loggersmanagement.endpoints.web.exposure.include默认只暴露health不写 metrics 的话 Admin 面板拿不到 JVM 内存、线程、HTTP 请求耗时。Spring Boot Admin 的 Server 端是一个独立应用用spring-boot-admin-starter-server建一个最简单的工程启动后访问9090端口就能看到所有注册进来的商城实例。要注意版本对齐Spring Boot 2.3.x 的商城对应 Admin 2.3.x 左右Boot 2.6.x 对应 Admin 2.6.x。如果 Client 版本比 Boot 主版本高很多有可能出现注册不上或端点解析失败。我一般先在本地同时启动 Admin Server 和商城应用看 Admin 页面里的“Journal”标签有没有收到客户端注册事件收到再部署测试环境比上线后查日志头大要好得多。5. 商城后端源码跑起来后最容易翻车的五个坑5.1 数据库连接失败时区、密码和驱动版本现象启动时 Spring Boot 报com.mysql.cj.exceptions.InvalidConnectionAttributeException或Access denied for user rootlocalhost应用秒退。原因常见有三种。一是application.yml里的密码没改源码作者用123456你本机 MySQL 密码是另一套二是 MySQL 8 的默认认证插件是caching_sha2_password而 pom 里引的驱动还是mysql:mysql-connector-java老版本三是缺serverTimezone参数JDBC 连不上正确时区。解决按本文 2.3 的配置改 URL并把驱动依赖升级到 8.x。检查 pom 里是否有mysql-connector-java注意从 MySQL 8.0 开始官方把驱动改名成com.mysql:mysql-connector-j包名变成com.mysql.cj.jdbc.Driver。如果项目里还在用旧包名并且没有旧驱动 jar换成新的即可。改完先mvn clean package重新编译再启动。5.2 Maven 依赖下载慢settings.xml 和本地仓库现象IDEA 的 Maven 面板一直在下载项目里所有引用springframework.*的地方都标红或者mvn clean时卡在进度条几十分钟。原因访问 Maven Central 很慢或者是依赖 jar 下载了一半导致本地仓库.lastUpdated文件残留。Maven 每次读取到校验失败的文件会重复尝试不清理会一直报错。解决在~/.m2/settings.xml里加一个镜像把中心仓库指向国内公共仓库mirror idaliyun/id mirrorOfcentral/mirrorOf urlhttps://maven.aliyun.com/repository/public/url /mirror注意mirrorOf只写central写成*会把项目里可能配置的私服也拦截掉公司内部开发的商城源码拿到外面用反而更乱。改完 settings 后回到项目根目录执行mvn clean install -U-U是强制刷新 SNAPSHOT 和远程仓库元数据。如果本地仓库里已经有一堆.lastUpdated文件可以顺手定位到repository目录删掉这些残留再重新拉依赖。5.3 接口 404 或 500控制台却像没事发生现象明明 Controller 写了GetMapping(/api/product/list)浏览器请求http://localhost:8080/api/product/list却返回 404日志里没有任何异常。原因最大嫌疑是应用配置了server.servlet.context-path。这个参数会让所有接口统一挂到一个前缀下比如server.servlet.context-path/mall那正确地址是http://localhost:8080/mall/api/product/list。另一个常见来源是拦截器放行规则写反了商品列表接口被当成未登录请求拦截拦截器里没有返回 JSON而是response.sendError(404)。解决先用curl -i看真实响应头curl -i http://localhost:8080/api/product/list如果响应头里有X-Application-Context: /mall说明是 context-path 造成的。把 application.yml 里的server.servlet.context-path改掉或者前端地址统一加前缀。如果是拦截器拦截看控制台有没有preHandle日志或者临时把拦截器的addPathPatterns改成空再跑一次确认。5.4 并发下单库存超卖现象用压测工具模拟 50 个线程同时买同一个商品数据库里的库存变成了负数或者一个商品只放了 10 件库存订单却生成了 12 单。原因代码里用了先select stock再判断if (stock quantity)最后update。这三个操作之间不是原子的多个请求同时读到stock10都认为可以买最后一起 update。这就是最典型的竞态。解决把扣库存改成一条条件 UPDATE见 3.3 的 XML。关键点是 UPDATE 的 WHERE 里带stock #{quantity}并且外层方法加Transactional。如果源码里用的是“查出来再减”把它替换成这条 SQL问题立刻消失。注意不要再在 UPDATE 前用Version乐观锁除非你把version也拼到 WHERE 里否则两套机制叠加会误伤正常请求。压测时先用测试库观察库存字段值和订单数是否对得上再谈 QPS 优化。5.5 Spring Boot 2.3.x 换到 2.6.x 的路径匹配变化现象把商城源码从 Spring Boot 2.3.x 升到 2.6.x 后原来正常访问的路径乱返回 404比如/api/order/detail/{id}带v1.0这种后缀就匹配不上。原因2.6 把默认路径匹配方式从AntPathMatcher换成了PathPatternParser。Ant风格里的{id:*}通配、以及某些正则表达式不再被支持。Spring Security 里如果写了mvcMatchers(/api/**)也可能受影响。解决如果你不打算立刻改注解先回退到原策略在 application.yml 写一行spring: mvc: pathmatch: matching-strategy: ant_path_matcher设置后重启一般能恢复。但要注意这只是给升级争取时间PathPattern的性能和规则都比Ant更严格长期还是建议把 Controller 里的路径改规范别再用*通配符。检查代码时重点搜RequestMapping和SecurityConfig里带*的字符串逐个改成{pathVariable}。6. 从“能跑”到“能用”压测接口和升级版本的两个实用技巧6.1 用 wrk 给下单接口做一次有意义的冒烟压测先curl确认接口能正常返回再做压测。写一个post.lua文件发送固定 JSON然后执行wrkwrk.method POST wrk.headers[Content-Type] application/json wrk.body {userId:1,productId:1,quantity:1}wrk -t4 -c100 -d30s -s post.lua http://localhost:8080/api/order/create-t4表示 4 个线程-c100表示保持 100 个连接-d30s表示压 30 秒。压测完先别看 QPS先查数据库里的库存和订单数商品 ID 为 1 的库存应该只扣那么多订单明细数和成功响应数一致。如果库存对不上不管 QPS 多高都是白忙。如果大量响应是 500优先看数据库连接池maximum-pool-size和 Tomcat 线程数商城源码里默认连接池只有 10 的时候压 100 并发必挂。6.2 从 2.3.x 升到 2.6.x 前先跑一遍回归链路升级版本时我习惯用一条命令先看实际解析到的 Spring Boot 版本mvn dependency:tree -Dincludesorg.springframework.boot:spring-boot如果依赖树里显示的还是 2.3.x说明 parent 版本没生效或者被某个子模块的dependencyManagement覆盖了。升级后要跑一遍最小回归链路注册、登录、商品列表、加购、下单、支付回调。支付回调用测试环境伪造一笔异步通知确认幂等逻辑没被新版本搞坏。我自己的教训是第二次接商城源码时为了省事直接用线上库跑过一次导入脚本结果把一张订单扩展表覆盖了。从那以后我定了条规矩——任何别人的源码先在本机建独立数据库用--spring.profiles.activetest启动所有压测只打测试库。升级版本也是一样改一行配置跑一遍回归链路再谈性能优化。希望帮到你。本文还有配套的精品资源点击获取