简介gpmall-repo.rar 是面向云计算与微服务实验环境搭建者的离线软件仓库资源包主要服务于 GPMall 电商项目相关组件的依赖安装与本地 yum 源配置适合课程实验、毕业设计及内网测试等需要在无外网或网络受限条件下复现环境的学习者。压缩包共收录 173 个文件以 166 个 rpm 安装包为主体涵盖 Java 运行环境、MongoDB、Elasticsearch、Logstash 等常用服务组件另含 3 个 gz、3 个 bz2 压缩的仓库元数据及 1 个 xml 索引文件整体约 304.19MB便于快速建立可检索、可校验的本地软件源。目前已有 187 人学习下载。借助这些内容读者可完成离线依赖安装、组件版本核对与 yum 仓库初始化减少逐项联网查找 rpm 包的时间也能为后续微服务部署、日志与搜索组件联调提供较完整的软件包基础适合作为云计算实验和项目环境复现的配套材料。1. 从 gpmall-repo 解压出来的那一刻这套电商商城源码该在云上怎么用拿到 gpmall-repo.rar 的人动机通常很实际想在一台云服务器上把一套电商商城的完整骨架跑通看商品、购物车、订单、后台管理这些模块到底怎么串起来。它适合两类人一类是刚接触云计算部署、需要真实项目练手的新手另一类是想拿现成业务骨架做二次开发的熟手。别指望解压完敲一条命令就能用它依赖的中间件不少建库、改配置、调端口一样都省不掉但也正因为链路完整跑通一次比读十篇入门教程都值。2. 仓库结构拆解一个 rar 里藏着的分层与聚合工程2.1 解压后先扫一遍顶层目录别急着执行构建rar 包在 Linux 云主机上解压第一道坎往往不是内容而是文件名编码。我一般不在目标目录里直接解先在/opt/src建个临时目录用7z或unar展开确认没有中文名乱码再往里挪避免后面 Maven 扫描路径时出现莫名其妙的找不到文件。# 建临时目录避免解压产物和已有文件混在一起 mkdir -p /opt/src/gpmall cd /opt/src/gpmall # -O 指定输出目录unar 对非 UTF-8 文件名比 unrar 友好 unar -o ./unpack /opt/upload/gpmall-repo.rar # 先看两层判断是单个工程还是聚合工程 前端的结构 find ./unpack -maxdepth 2 -type d | sort | head -40 # 统计体积判断仓库里是否混入了编译产物target、node_modules du -sh ./unpack/* | sort -h这段命令的重点在后两条。find -maxdepth 2用来快速判断结构类型如果顶层就一个pom.xml加一堆src那是单体工程如果下面同时出现多个带pom.xml的子目录和一个前端目录就是聚合工程加前后端分离。du -sh是血泪经验很多打包者会把target/、node_modules/、.idea/一起塞进 rar解压后动辄一两个 G真正有用的源码可能只有几十 M先看清楚再决定要不要清理。扫完之后我期望看到的是这样一份目录轮廓gpmall-repo/ ├── docs/ # 部署说明、接口约定、数据库设计草图 ├── sql/ # 建库脚本与初始化数据通常按模块拆分 ├── gpmall-common/ # 工具类、统一返回体、常量、异常定义 ├── gpmall-api/ # 领域模型DO/DTO/VO与对外服务接口 ├── gpmall-service/ # 业务实现、Mapper 接口与 XML ├── gpmall-web/ # 控制器、拦截器、全局配置、启动类 ├── gpmall-portal-web/ # 前台接口层可选的第二入口 └── gpmall-static/ # 前端静态资源交给 Nginx 托管这个轮廓透露的信息比目录名字本身多得多。common和api独立成模块说明作者是有意把「被所有人依赖的东西」和「会频繁改的业务」隔开的这是聚合工程里最基础也最容易被破坏的一条边界。service与web分离意味着控制器里不该出现Transactional之外的业务逻辑事务边界应该压到 service 层。static目录存在说明前端不打算跟后端一起打成 jar而是走 Nginx 静态托管加接口反向代理这在云上部署时直接影响你要开几个进程、几个端口。2.2 聚合 pom 与模块边界谁管版本谁管业务打开顶层pom.xml先看packaging是不是pom再看modules列了哪些子模块。聚合工程里最常见的坏味道是每个子模块自己写依赖版本父 pom 只声明不管理结果升级一个组件要改七八个文件。合格的写法是把版本号全部收到父 pom 的dependencyManagement里。!-- 顶层 pom只管版本与模块清单不写具体业务依赖 -- project modelVersion4.0.0/modelVersion groupIdcom.example.mall/groupId artifactIdgpmall-parent/artifactId version1.0.0/version !-- 打包方式必须是 pom否则 Maven 会尝试编译它 -- packagingpom/packaging modules modulegpmall-common/module modulegpmall-api/module modulegpmall-service/module modulegpmall-web/module /modules properties !-- 统一 JDK 版本避免子模块各自为政 -- java.version17/java.version spring.boot.version3.2.5/spring.boot.version /properties dependencyManagement dependencies !-- 引入 BOM子模块引用时不再写 version -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-dependencies/artifactId version${spring.boot.version}/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement /projectpackagingpom/packaging是关键参数漏了它 Maven 会当成普通 jar 工程去编译直接报「no sources to compile」之后构建失败。scopeimport/scope只对typepom/type生效作用是把 BOM 里的版本声明整体并入当前工程的依赖管理子模块再写spring-boot-starter-web就不用带版本号了。java.version这个属性名是 Spring Boot 父 pom 认的改了它会同时影响编译插件的source/target比单独配 maven-compiler-plugin 省事。实际拆的时候我还会确认一件事service模块有没有反向依赖web。正常应该是一条单向链web → service → api → common一旦出现反向依赖说明有人把 Controller 里的工具方法塞进了 service编译能过但模块边界已经烂了后面想单独抽出订单服务做水平拆分时会非常痛苦。检查办法很土但有效看gpmall-service/pom.xml里有没有gpmall-web的dependency有就记下来这是二次开发时第一个要还的技术债。2.3 前端静态资源与后端服务的分界gpmall-static这个目录值得单独看。如果里面是打包后的dist产物index.htmlassets/说明源码不在包里只能部署不能改如果里面是src/、package.json、vite.config.js那就是完整前端工程得装 Node 环境自己构建。两种情况的部署动作完全不同先ls一眼再决定装不装 Node。前端工程里第一个要改的文件是请求基地址。开发时它指向localhost上云之后要么改成域名要么走 Nginx 同源反向代理留空后者更省事因为不用处理跨域和 HTTPS 混合内容。// src/utils/request.js —— 统一 axios 实例 import axios from axios const request axios.create({ // 生产环境走 Nginx 同源代理baseURL 留空即可避免硬编码 IP baseURL: import.meta.env.VITE_API_BASE || , timeout: 10000 }) request.interceptors.request.use((config) { // 令牌放请求头后端拦截器按 Authorization 取 const token localStorage.getItem(token) if (token) config.headers.Authorization Bearer ${token} return config })baseURL留空的前提是前端和后端同域由 Nginx 把/api前缀转发到后端端口。如果硬编码成http://公网IP:8080浏览器会先发预检请求后端没配 CORS 就直接挂这是新手最常见的翻车点。timeout给 10 秒是个折中值商品列表接口在冷启动时可能超过 3 秒给太短会误报超时。拦截器里读localStorage而不是sessionStorage是因为多标签页场景下后者不共享用户在两个页面之间切换会莫名掉登录。对应地Nginx 那边要有一段 location 把接口转出去并且保留原始路径否则后端的RequestMapping前缀对不上server { listen 80; server_name _; # 静态资源直接由 Nginx 吐不经过 Java 进程 root /opt/app/gpmall-static/dist; index index.html; location / { try_files $uri $uri/ /index.html; # 前端 history 路由必需 } # 接口反向代理proxy_pass 末尾不带斜杠才会保留 /api 前缀 location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files那一行是单页应用的路由兜底少了它用户刷新/order/list会直接 404。proxy_pass后面带不带斜杠是玄学但必须搞清楚带斜杠会剥掉/api前缀不带则原样转发。后端接口如果本身就带/api就别加斜杠。X-Real-IP是为了让后端拿到真实客户端 IP做限流和日志分析时没有它全是 127.0.0.1。3. 环境与启动链路从一台空云主机到接口能通3.1 组件清单与云主机规格估算这套商城跑起来不是单进程的事。按常见的电商骨架后端至少依赖关系库和缓存前台页面依赖静态托管搜索和消息队列看包里有没有对应配置再决定装不装。上云之前先把清单列清楚比边跑边装省一半时间。组件作用最低可用配置是否必需JDK 17后端运行时与 pom 中 java.version 一致必需MySQL 8.0商品、订单、用户主数据2C4G字符集 utf8mb4必需Redis 6会话、商品缓存、库存预扣1C1G开 AOF必需Nginx静态资源 接口反代与后端同机即可必需Elasticsearch商品搜索2C4G单节点视配置而定RocketMQ / RabbitMQ下单后异步扣减、通知1C2G视配置而定云主机我一般给 4C8G 起步。理由不是 Java 吃内存而是 MySQL、Redis、后端 JVM 挤在一台 2G 机器上光 JVM 默认堆就可能把系统撑到 OOM Killer 出手到时候日志里只有一行Killed排查起来毫无线索。JVM 参数手动压一下-Xms512m -Xmx1024m -XX:UseG1GC小机器上比默认值稳得多。安全组只放 80 和 443MySQL 的 3306 和 Redis 的 6379 一律不对外。这不是洁癖公网上扫 6379 的脚本一天能来几万次Redis 没设密码就等于把数据库交出去。本地调试用 SSH 隧道转发端口比开安全组省心。3.2 建库、导数据与配置文件改造sql/目录下通常有建库脚本和初始化数据两份文件。导入顺序不能反先结构后数据。字符集要在建库时就定死utf8mb4因为商品名里出现表情符号或者生僻字是常态utf8三字节存不下写入时报Incorrect string value还很难定位到具体哪条数据。-- 建库字符集和排序规则一次定死避免后续 ALTER 大表 CREATE DATABASE gpmall DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; -- 应用账号只给业务库权限别用 root 跑应用 CREATE USER mall127.0.0.1 IDENTIFIED BY ChangeMe_2024; GRANT SELECT, INSERT, UPDATE, DELETE ON gpmall.* TO mall127.0.0.1; FLUSH PRIVILEGES; -- 导入前先关外键检查避免表顺序导致的约束报错 SET FOREIGN_KEY_CHECKS 0; SOURCE /opt/src/gpmall/unpack/sql/schema.sql; SOURCE /opt/src/gpmall/unpack/sql/data.sql; SET FOREIGN_KEY_CHECKS 1; -- 导入后核对核心表行数确认数据真的进来了 SELECT goods AS t, COUNT(*) FROM goods UNION ALL SELECT orders, COUNT(*) FROM orders;utf8mb4_general_ci是不区分大小写排序商品编码这类字段如果要求区分大小写单独给列指定utf8mb4_bin。GRANT只给 CRUD 四项不给DROP是为了防止误操作或者 SQL 注入把表删掉。FOREIGN_KEY_CHECKS 0只在导入期间关闭导完必须开回来否则后续业务写入会绕过外键约束。最后那条核对语句是习惯动作行数为 0 说明SOURCE路径写错了或者文件是空的早发现比启动后查空列表强。接着改配置文件。数据源、Redis 地址、端口三项是必改的其余保持默认。配置里的密码一律走环境变量别直接写明文提交回仓库。# application-prod.yml —— 生产 profile启动时用 --spring.profiles.activeprod 激活 server: port: 8080 # 云上一般由 Nginx 挡在前面这里只监听回环地址更安全 address: 127.0.0.1 spring: datasource: url: jdbc:mysql://127.0.0.1:3306/gpmall?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue username: ${DB_USER} password: ${DB_PASS} hikari: maximum-pool-size: 20 # 小机器别开太大连接数 × 内存要算总账 connection-timeout: 3000 data: redis: host: 127.0.0.1 port: 6379 password: ${REDIS_PASS} database: 0 lettuce: pool: max-active: 16 logging: level: root: info com.example.mall: debug # 业务包单独开 debug排查时不至于被框架日志淹没server.address设成127.0.0.1是为了让 8080 只对本机开放外部访问统一走 Nginx少一层暴露面。连接串里的serverTimezoneAsia/Shanghai不能省MySQL 8 默认时区是 UTC订单时间会整体偏 8 小时这种错误在产品上线后才被发现改起来要动历史数据。allowPublicKeyRetrievaltrue是 MySQL 8 默认认证插件下的必需参数缺了会报Public Key Retrieval is not allowed。Hikari 的maximum-pool-size按「核数 × 2 磁盘数」估4 核机器给 20 足够给 100 反而会因为线程争抢把响应时间拉长。3.3 启动顺序与健康检查组件之间是有依赖方向的MySQL 起来之前后端连不上库会一直重试Redis 没起来则登录直接失败。所以启动顺序固定为 MySQL → Redis → 后端 → Nginx。# 1. 确认中间件端口在监听没有就先去启服务 ss -lntp | grep -E :(3306|6379|8080)\b # 2. 后端以 prod profile 启动日志重定向到文件 cd /opt/app/gpmall export DB_USERmall DB_PASSChangeMe_2024 REDIS_PASSredis_pwd nohup java -Xms512m -Xmx1024m -XX:UseG1GC \ -jar gpmall-web/target/gpmall-web-1.0.0.jar \ --spring.profiles.activeprod /var/log/gpmall/app.log 21 # 3. 轮询健康检查别用固定 sleep机器慢的时候 10 秒根本不够 for i in $(seq 1 30); do code$(curl -s -o /dev/null -w %{http_code} http://127.0.0.1:8080/actuator/health) [ $code 200 ] echo backend up after ${i}s break sleep 1 done # 4. 起不来就看日志末尾别猜 tail -n 80 /var/log/gpmall/app.logss -lntp一次看三个端口比挨个telnet快。nohup加是临时跑法正式环境还是交给 systemd 或者容器编排至少挂了能自动拉起。健康检查循环里用curl拿状态码而不是pgrep java因为进程活着不代表 Spring 上下文初始化完成actuator/health返回 200 才意味着数据源和 Redis 都连通了。tail -n 80只看末尾Spring Boot 启动失败的根因一般在最后 30 行内从日志开头翻纯属浪费时间。4. 核心链路代码登录鉴权、商品缓存、下单扣库存4.1 登录态与拦截器链路电商系统的第一道门是登录。这套骨架里常见的做法是登录接口签发令牌后续请求靠拦截器解析令牌并把用户信息塞进上下文业务层从上下文取不逐层传参。// AuthInterceptor.java —— 令牌解析与用户上下文注入 Component public class AuthInterceptor implements HandlerInterceptor { private static final String HEADER Authorization; // ThreadLocal 存用户请求结束必须 remove否则线程池复用会串号 private static final ThreadLocalLong USER_HOLDER new ThreadLocal(); private final TokenService tokenService; public AuthInterceptor(TokenService tokenService) { this.tokenService tokenService; } Override public boolean preHandle(HttpServletRequest req, HttpServletResponse resp, Object handler) { String raw req.getHeader(HEADER); if (raw null || !raw.startsWith(Bearer )) { resp.setStatus(HttpServletResponse.SC_UNAUTHORIZED); return false; // 直接短路不进控制器 } Long userId tokenService.parse(raw.substring(7)); if (userId null) { resp.setStatus(HttpServletResponse.SC_UNAUTHORIZED); return false; } USER_HOLDER.set(userId); return true; } Override public void afterCompletion(HttpServletRequest req, HttpServletResponse resp, Object handler, Exception ex) { USER_HOLDER.remove(); // 必须清理这是最容易漏的一行 } public static Long currentUserId() { return USER_HOLDER.get(); } }preHandle返回false表示请求到此为止不会再进 Controller所以设置状态码和直接返回要一起做只设状态码不返回false是无效的。raw.substring(7)的长度取决于Bearer这七个字符包含末尾空格数错了会导致令牌首字符被截断报签名不匹配这种 bug 看代码很难发现。afterCompletion里的remove()是重中之重Tomcat 的线程是复用的不清理的话下一个请求可能读到上一个用户的 ID表现为「偶尔看到别人的订单」属于最难排查的一类问题。拦截器注册时要注意放行路径。登录、注册、商品浏览这些不需要令牌全拦了用户连首页都打不开。Configuration public class WebConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new AuthInterceptor(tokenService)) .addPathPatterns(/api/**) .excludePathPatterns( /api/auth/login, /api/auth/register, /api/goods/list, // 商品列表允许匿名浏览 /actuator/** // 健康检查不能被拦 ); } }addPathPatterns(/api/**)只拦接口前缀静态资源和 Swagger 文档自动放过。excludePathPatterns是按最长匹配优先的/api/goods/list不会连带放行/api/goods/detail如果详情页也想匿名看得单独加一条。/actuator/**一定要放行否则健康检查一直 401启动脚本会误判后端没起来。4.2 商品详情的缓存读写商品详情是典型的读多写少直接查库在并发上来之后会把 MySQL 打满。常见做法是 Cache Aside先读缓存未命中查库再回填更新时删缓存而不是改缓存。Service public class GoodsQueryService { private static final String KEY_PREFIX goods:detail:; // 基础过期时间加随机偏移防止同一批商品同时失效造成缓存雪崩 private static final long BASE_TTL 1800L; private final GoodsMapper goodsMapper; private final StringRedisTemplate redis; private final ObjectMapper objectMapper; public GoodsDetailVO detail(Long goodsId) { String key KEY_PREFIX goodsId; String cached redis.opsForValue().get(key); if (cached ! null) { return readValue(cached); // 命中直接返回 } GoodsDetailVO vo goodsMapper.selectDetailById(goodsId); if (vo null) { // 空值也缓存一小会儿挡住穿透查询 redis.opsForValue().set(key, {}, 60, TimeUnit.SECONDS); return null; } long ttl BASE_TTL ThreadLocalRandom.current().nextLong(300); redis.opsForValue().set(key, writeValue(vo), ttl, TimeUnit.SECONDS); return vo; } // 更新商品后调用先更新库再删缓存 public void evict(Long goodsId) { redis.delete(KEY_PREFIX goodsId); } }BASE_TTL加随机偏移解决的是雪崩如果一万个商品缓存同时到期请求会瞬间全部落到数据库上。空值缓存 60 秒解决的是穿透有人拿不存在的 ID 疯狂请求不缓存空结果的话每次都打到库。evict用删除而不是更新是因为并发更新缓存的顺序无法保证两个线程一前一后写可能把旧值覆盖回去删除操作是幂等的最多多一次回源。序列化这块我吃过亏。ObjectMapper默认会把Long类型的 ID 序列化成数字前端 JS 的Number精度只有 53 位雪花 ID 一超就丢精度用户点详情页跳到了别人的商品。稳妥写法是在序列化配置里把Long全局转成字符串或者在 VO 里直接用String类型存 ID。4.3 下单扣库存的防超卖库存是最不能出错的地方。查一次库存再更新一次的写法在并发下必然超卖因为检查和更新之间有时间窗口。正确做法是把判断塞进 SQL 的where里让数据库的行锁保证原子性。-- 扣减库存条件更新影响行数为 0 说明库存不足或商品不存在 UPDATE goods_stock SET stock stock - #{num}, update_time NOW() WHERE goods_id #{goodsId} AND stock #{num};这条语句的影响行数就是判断依据。Java 侧拿int affected判断等于 0 就抛业务异常回滚事务无需先查再比。stock #{num}放在where里MySQL 会在行锁内完成比较和更新两个并发请求只有一个能拿到锁另一个看到的已经是扣减后的值。索引必须建在goods_id上否则这条update会扫全表并锁住大量行高并发下直接把库拖死。事务边界要压在 service 方法上并且只包住「扣库存 写订单」这两步别把发消息、写日志也包进去长事务会持有行锁直到提交吞吐掉得很快。Transactional(rollbackFor Exception.class) // 显式指定 Exception否则受检异常不回滚 public Long createOrder(Long userId, Long goodsId, int num) { int affected stockMapper.deduct(goodsId, num); if (affected 0) { throw new BizException(库存不足); } Order order new Order(); order.setOrderNo(IdWorker.nextId()); // 订单号在事务内生成 order.setUserId(userId); order.setGoodsId(goodsId); order.setNum(num); orderMapper.insert(order); return order.getId(); }rollbackFor Exception.class不能省Spring 默认只在RuntimeException和Error时回滚抛受检异常时事务会提交留下「库存扣了但订单没写」的脏数据。IdWorker.nextId()放在事务内生成保证同一事务里订单号唯一如果放到事务外再重试可能生成重复号。真实场景里还要加一层 Redis 预扣做流量削峰但先保证数据库这层不出错再谈优化。5. 部署与联调避坑五个把上线卡住的问题5.1 环境与启动阶段的三个坑现象java -jar启动后一秒退出日志里什么都没有。原因多半是内存不够被系统杀了或者是--spring.profiles.active指定的 profile 文件根本不存在Spring 启动时找不到配置直接终止。先看dmesg | tail -20有没有 OOM 记录再看ls一下application-prod.yml到底在不在resources下两者都没有问题时把 JVM 堆压到 512m 再试。现象数据库连上了但查出来的中文全是问号。原因在建库或连接串的字符集上utf8和utf8mb4混用是重灾区。解决分三步查SHOW VARIABLES LIKE character_set%看服务端连接串里看有没有characterEncodingutf8最后SHOW CREATE TABLE goods确认列级字符集。三处都统一成utf8mb4才彻底解决只改一处往往还有残留。现象Nginx 转发后接口全是 502但curl 127.0.0.1:8080是通的。原因是proxy_pass指向了localhost而服务只监听了 IPv4或者后端配了server.address127.0.0.1而 Nginx 跑在容器里。解决是把proxy_pass写成明确的http://127.0.0.1:8080并确认 Nginx 和后端在同一网络命名空间内容器化部署时两者要用同一个 Docker 网络不能一个 host 网络一个 bridge。5.2 业务与数据层面的两个坑现象用户 A 偶尔能看到用户 B 的购物车。原因是拦截器里用ThreadLocal存了用户 ID但afterCompletion没写remove()线程复用导致串号。解决是在afterCompletion里无条件remove()并且在网关或过滤器层加一道兜底清理。这类问题在压测时才会暴露单机点几下永远复现不了。现象下单接口偶发「库存不足」但实际库存还有几百。原因是扣库存 SQL 没走索引where goods_id ?扫全表拿的是间隙锁并发事务互相阻塞后超时重试重试时库存已被别的事务扣走。解决办法是给goods_id建唯一索引EXPLAIN确认typerange或eq_ref同时把事务里的非必要操作全部挪出去缩短持锁时间。5.3 出问题时的排查顺序线上出问题最忌讳东看一点西看一点。我固定按这个顺序走先curl健康检查确认进程活着再看ss -lntp确认端口在听然后tail应用日志找异常堆栈接着看 MySQL 的SHOW PROCESSLIST有没有长事务和锁等待最后才怀疑 Redis 和网络。这个顺序是从「最容易出问题且最容易验证」往「最难定位」排的八成问题在前两步就能收敛。6. 二次开发在这套骨架上加一个促销模块并验证想在这套商城骨架上做二次开发最省事的切入点是加一个独立业务域而不是直接改商品和订单。促销满减、折扣就是个合适的例子它需要读商品和订单但不改它们的表结构边界清晰改坏了也容易回滚。第一步在sql/下新建promotion表字段只留id、rule_type、threshold、discount、start_time、end_time、status其余扩展放 JSON 字段里避免一开始就把表设计死。第二步在service模块建PromotionService对外只暴露两个方法matchRule(goodsId, amount)返回命中的规则列表calcDiscount(rules, amount)返回优惠金额。第三步在订单创建的 service 里加一行调用注意要放在扣库存之前因为优惠后金额才是最终要校验的。改造点放置位置注意促销表新建独立表不改订单表订单表加discount_amount字段即可规则计算service模块新包promotion不依赖web保证可单测订单接入下单 service 内扣库存前计算异常要降级为无优惠不能阻断下单缓存规则按 ID 缓存TTL 5 分钟规则变更走删除缓存验证方法我一般写一个集成测试把「金额正好等于门槛」「差一分达不到门槛」「规则已过期」三种情况各跑一遍断言优惠金额和最终应付金额。比手工点页面靠谱因为促销这类逻辑边界条件特别多手工根本覆盖不全。改造过程中最容易犯的错是把促销逻辑直接写进订单的 Controller 里图省事一个方法三百行后面想加个「新人专享」就得动主流程。我个人的习惯是任何新业务都先问一句「它能不能只依赖 api 模块的接口完成」能就独立成服务不能才考虑放进去。从那以后我每次加新模块前都会先在pom.xml里检查一遍依赖方向确认没有反向引用才动手写第一行代码。希望帮到你。本文还有配套的精品资源点击获取
