企业官网建设流程全解析

简介：这套资源是CRMEB Java版单商户商城系统v2.0.1完整源码包，适合需要部署、二次开发或学习Spring Boot商城架构的Java开发者和运维人员。包体共2000个文件，其中1069个Java源码覆盖后端业务模块，335个Vue及210个JS、16个SCSS构成管理端和移动端界面，另含SQL、XML、YML、shell脚本等配置与部署文件，整体压缩后约26.64MB，目录结构清晰。修复内容包括pom构建插件提示、启动停止脚本、文件导出、推广人列表、默认地址、秒杀查询、小程序模板消息、富文本光标等问题，并优化了历史日志清理、城市数据渲染与分类模板销量展示。已有683人学习下载，适合作为商城系统源码分析、环境搭建及二次开发的重要参考。

1. 一个基于SpringBoot的单商户商城：CRMEB Java版v2.0.1到底能解决什么问题

CRMEB Java版单商户商城系统v2.0.1（CRMEB_JAVA_SY_v2.0.1，20220214发行）给我的第一印象是：一个把「商品、订单、支付、营销、分销」都装进去的SpringBoot单体商城，后端一套Java代码，跑起来就能同时支撑管理后台和H5/小程序两端。我帮线下门店做过几个这类交付，最直观的感受是它对单商户场景抓得很准，能省掉从零写权限、写订单状态机的大量时间；但如果你把它当成「解压就能跑」的成品，大概率会在数据库初始化、支付回调、图片存储这类环节里搭进去一晚上。

所以这篇文章的定位很直接：从本地部署开始，一路讲到模块结构、下单支付退款这条核心链路，最后把那些让人摔跟头的坑一个个拆开。适合两类人。一类是刚接单、要用开源Java商城快速交差的独立开发者；另一类是团队里负责商城模块、想搞懂后端调用链和参数配置的Java开发。所有配置和代码按简化演示处理，流程和判断方式可以直接复用到你的项目里，落到具体版本时以发行包里的实际结构为准。

多说一句：v2.0.1这个版本号意味着它处在这套系统的稳定期内，功能上已经具备了单商户商城的基本盘，也保留了不少二开痕迹。你不需要有搭建过商城的经验，但最好懂SpringBoot基础、知道MySQL和Redis怎么启动，接下来就顺了。

2. 从拉代码到看到登录页：CRMEB Java版v2.0.1本地部署与最小启动配置

2.1 部署前的环境要求与JDK/MySQL版本取舍

先把环境对齐，避免后面把所有时间花在「启动报错-搜错误-改配置-再报错」的循环里。常见做法是准备这样一套本地环境：

• JDK：1.8（推荐；别用11或17，兼容性折腾）
• Maven：3.6以上，用来打包
• MySQL：5.7最省心，8.0也可以但驱动要换
• Redis：必须有，登录凭证、购物车、部分缓存都靠它
• 操作系统：Windows和Linux都行，配置差异集中在文件路径写法上

版本取舍上，我一般会直接选JDK8 + MySQL5.7。这套发行版在JDK8下的启动时间、反射调用、JSP和Tomcat兼容性都正常，换到高版本JDK反而容易碰到模块化限制带来的运行时异常。MySQL8能用，但数据库连接驱动得切换成带cj的版本，并且URL里要多加几个参数，这个坑在第5章单独讲。

Redis是很多人会漏的一环。单商户商城虽然叫「单商户」，但并发情况下对Redis的依赖很重，秒杀、优惠券、登录Token都会命中Redis。先确认本机Redis能通过redis-cli ping返回PONG，再往下走。

2.2 数据库初始化与最小配置

拿到发行包后第一件事是建库和导表。不要在可视化工具里手动挨个建表，直接用发行包里的SQL脚本跑一遍更稳。

-- 建库，注意字符集，商品标题里的emoji和生僻字全靠它 CREATE DATABASE IF NOT EXISTS `crmeb_java` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE crmeb_java; -- 执行发行包自带的完整初始化脚本，路径以实际包为准 -- mysql -uroot -p < 你的解压目录/sql/init.sql -- 确认核心表已经建好，防止脚本悄悄失败 SHOW TABLES LIKE 'eb_%';

这段的先建库再导脚本，顺序不能反。如果你在连接工具里先选中了别的库再执行脚本，表会建到错误库下面，后台登录时一脸懵。字符集必须显式指定utf8mb4，否则商品名里的特殊字符会变成乱码。SHOW TABLES LIKE 'eb_%'用来验证表前缀，这套系统的表基本是eb开头，表数量在几十张左右，如果只出现零星几张，说明脚本执行中断过，重导一遍更稳妥。

数据库就绪后，改配置。最小配置只需要动一个文件，数据源、Redis、上传路径都集中在这里。

server: port: 8080 spring: datasource: url: jdbc:mysql://127.0.0.1:3306/crmeb_java?useUnicode=true&characterEncoding=utf-8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: your_password driver-class-name: com.mysql.jdbc.Driver redis: host: 127.0.0.1 port: 6379 password: "" database: 0 crmeb: upload: # 本地存储路径，Linux写成 /data/www/upload，Windows写 D:/upload path: /data/www/crmeb/upload url: /upload

参数说明：serverTimezone=Asia/Shanghai必须加，否则时间字段和数据库默认时区对不上，订单时间会差8小时；useSSL=false是本地联调省事，生产环境如果有SSL证书再打开。Redis的password保持和实际Redis一致，本地如果没设密码就留空字符串，设了密码不填的话，首次登录接口会直接报连接异常。crmeb.upload.path是上传文件落盘目录，url是访问前缀，这两个值必须和后面的静态资源映射对上，不然商品图片会上传成功但页面加载不出来。

配置改完，开始打包启动。用Maven多模块构建，直接切到后台管理模块打包：

# 构建并启动后台管理服务 mvn clean package -DskipTests -pl crmeb-admin -am # 启动，profiles指定使用上面的prod配置 java -jar crmeb-admin/target/crmeb-admin.jar \ --spring.profiles.active=prod \ --server.port=8080

-pl crmeb-admin表示只构建后台管理这个模块，-am表示同时构建它依赖的公共模块，少了这个参数会报找不到依赖包。-DskipTests跳过测试，本地联调没必要把单元测试跑一遍。启动参数里覆盖了server.port，意思是就算配置文件写的别的端口，也会以这个为准。

启动成功的标志是日志里出现「Started ... in xxx seconds」以及Tomcat监听的端口号。浏览器访问http://localhost:8080/admin应该能打开后台登录页，账号密码来自初始化SQL里的预置管理员数据，不在这篇文章的讨论范围内，拿到包之后先进后台把密码改掉。

2.3 前端联调：接口地址与代理配置

后台跑通后，还要把H5端或小程序端连到本地后端。常见做成是前端工程里单独维护一个环境配置，H5端通常在config/env.js这类文件里，小程序端一般在根目录的config/index.js或utils/request.js里定义baseUrl。

// 本地联调指向本机后端，上线改为https域名 const baseUrl = 'http://localhost:8080';

改完这个变量，小程序工具里勾选「不校验合法域名」才能在本地访问localhost接口。H5端则要解决浏览器跨域，后端一般已经做了跨域放行，如果本地联调时请求发不出去，优先看浏览器Console里的CORS报错，再确认是不是前端用了80端口而后端是8080导致端口不一致。

这里要提醒一个习惯：联调阶段先把商品管理、会员、订单这些基础页面跑通，再开支付。支付需要真实商户号和回调地址，本地环境通常要配合内网穿透才能完成闭环，放在第4章细说。

3. 读透项目分层：这套商城的模块划分与两个关键配置文件

3.1 模块划分：admin端、api端与公共层

拿到代码第一件事是搞清模块结构，否则后面找接口、改逻辑全靠全局搜索，效率极低。CRMEB Java版是典型的多模块Maven工程，模块边界大致是这样的：

crmeb_java_sy_v2.0.1/ ├── crmeb-common # 通用返回结果、常量、工具类、异常定义 ├── crmeb-framework # 拦截器、安全配置、全局异常处理、JWT配置 ├── crmeb-admin # 后台管理端接口，给管理后台调用 ├── crmeb-api # 商城对外接口，给H5/小程序调用 └── crmeb-service # 业务逻辑层，两边共用

为什么要分成admin和api两个接口模块？因为面向的对象完全不同。后台管理端的调用者是运营人员，接口要带操作日志、数据权限、更严格的后台Token校验；商城端的调用者是普通用户，接口要面对高并发、需要友好的错误提示，Token失效时要自动跳登录。把两边接口拆开，各自的拦截器逻辑才能独立演化，不会互相踩到。

但业务逻辑不拆。订单创建、商品查询、优惠券计算这些核心逻辑放在crmeb-service里，后台和商城都调同一套Service，避免出现「后台改了个状态，但商城端查的还是旧逻辑」这种经典翻车现场。改代码时记住这一个原则：涉及核心业务，只改Service层；涉及接口暴露方式和权限，才动Controller层。

3.2 登录与Token：JWT如何串联后台和商城两端

看接口之前要先懂鉴权。这套系统用的是JWT Token，登录成功后台生成一段带签名的Token，前端每次请求放到Header里，后端拦截器解析出用户ID放到请求上下文。下面是登录接口的简化演示：

@PostMapping("/api/login") public Result<LoginVo> login(@RequestBody LoginDto dto) { // 1. 按账号查后台用户 SysUser user = sysUserService.findByAccount(dto.getAccount()); // 2. 密码用BCrypt加密存储，核对原文和密文 if (user == null || !passwordEncoder.matches(dto.getPassword(), user.getPassword())) { return Result.fail("账号或密码错误"); } // 3. 生成Token，过期时间单位是秒 String token = jwtUtil.createToken(user.getId(), user.getAccount(), 7 * 24 * 3600); return Result.ok(new LoginVo(token, user)); }

逻辑说明：先根据账号查用户，查不到或者密码校验不过就返回统一失败结果，不暴露具体是账号错还是密码错。密码用BCrypt而不是MD5，因为MD5可查表碰撞，BCrypt自带随机盐，这是做商城的基本安全意识。生成Token时把用户ID和账号放进去，过期时间这里演示的是7天，适合商城端用户保持登录的体验。

拦截器那边做的事情更纯粹，每个需要登录的接口都过一遍：

public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token = request.getHeader("Authorization"); // 解析失败或过期，返回401让前端跳登录 Long userId = jwtUtil.parseToken(token); if (userId == null) { response.setStatus(401); return false; } request.setAttribute("userId", userId); return true; }

参数说明：Token从Authorization头取，这是前后端约定的标准做法。jwtUtil.parseToken内部会校验签名和过期时间，密钥配在application.yml里。踩过的坑是有人把密钥改成空字符串，结果任何人都能伪造Token，后台被扫到直接脱库；也有人把过期时间改成了30天，结果运营账号泄露后半个月才被发现。后台Token建议压到2小时以内，商城端按业务需要放宽。

3.3 两个关键配置文件：数据源与文件存储

配置文件真正需要人盯的，除了数据源就是文件存储。数据源参数在第2章已经覆盖，这里重点讲文件存储的选型。

文件存储常见有本地存储和对象存储两种，这套系统都支持，参数通常在crmeb.upload节点下切换。二者对比看这张表：

我一般做开发联调直接用本地存储，上线时再切对象存储。切的时候要注意，历史数据已经存在本地磁盘的不会自动迁移到对象存储，图片URL全都会变。有个项目就是上线前临时切换，结果老商品图全裂，最后写了个脚本把本地目录下的文件按日期批量传到对象存储，才把历史数据补齐。

文件存储还有一个隐藏配置：本地存储路径和URL前缀的映射。path是物理磁盘路径，url是浏览器访问前缀，二者通过一个资源映射配置关联。如果你发现图片上传返回了路径，但浏览器访问404，八成是这两个值一个写/data/upload一个写http://localhost:8080/upload，前后缀没对齐。这类问题归到第5章统一展开。

4. 下单、支付到退款：CRMEB Java版v2.0.1核心业务流与参数设置

4.1 订单创建：库存扣减与订单号生成

商城最核心的一条链路就是下单到退款。先看下单。订单创建涉及三个动作：校验商品、生成订单号、扣减库存。简化代码如下：

@Transactional(rollbackFor = Exception.class) public OrderVo createOrder(Long userId, Long skuId, Integer num) { // 1. 查商品SKU，带行锁防止超卖 Sku sku = skuMapper.selectByIdForUpdate(skuId); if (sku == null || sku.getStock() < num) { throw new BizException("库存不足"); } // 2. 生成订单号：时间戳 + 随机数，避免并发重复 String orderNo = "CR" + System.currentTimeMillis() + String.format("%04d", ThreadLocalRandom.current().nextInt(9999)); // 3. 扣库存 skuMapper.deductStock(skuId, num); // 4. 写订单主表和订单明细表 Order order = new Order(); order.setOrderNo(orderNo); order.setUserId(userId); order.setAmount(sku.getPrice().multiply(BigDecimal.valueOf(num))); orderMapper.insert(order); return buildOrderVo(order); }

逻辑说明：selectByIdForUpdate是悲观锁的写法，事务内锁定这行SKU直到提交，并发下单时后到的请求会等锁。对单商户的体量来说，这种锁粒度够用，不会出现超卖。订单号用时间戳加四位随机数，单商户并发量下基本够用，真不够再加个用户ID后缀。@Transactional保证扣库存和写订单同生共死，任何一步失败都整体回滚。

这里有个业务取舍：减库存的时机。这套系统常见做法是下单即减，好处是避免「支付了但没库存」的纠纷，坏处是用户下单后不支付会占用库存，所以配套会有超时未支付自动关闭订单的定时任务，把库存加回来。做二开时不要轻易改成「支付才减库存」，涉及到的定时任务、库存记录表都得联动改。

4.2 支付配置：回调URL与证书路径

支付环节是整个商城上线时最容易出问题的部分。先理清调用链：小程序端调起支付 → 后端向微信支付平台发起统一下单 → 拿到支付参数返回给前端 → 用户确认支付 → 微信服务器异步回调后端接口 → 后端验签并改订单状态。

真正需要人工配的参数集中在这几个：

支付回调的处理逻辑长这样：

@PostMapping("/pay/notify") public String wxNotify(@RequestBody String xmlData) { // 1. 先验签，防止伪造回调 boolean signOk = wxPayService.verifySign(xmlData); if (!signOk) { return "FAIL"; } // 2. 解析订单号和支付金额，注意金额单位是分 String orderNo = parseOrderNo(xmlData); Integer amount = parseAmount(xmlData); // 3. 幂等处理：订单已是已支付状态就直接返回成功，防止重复回调 Order order = orderMapper.selectByNo(orderNo); if ("PAID".equals(order.getStatus())) { return "SUCCESS"; } // 4. 核验金额一致后更新订单状态 if (order.getAmount().multiply(BigDecimal.valueOf(100)).intValue() == amount) { orderMapper.updateStatus(orderNo, "PAID"); return "SUCCESS"; } return "FAIL"; }

逻辑说明：微信支付回调有两个硬性要求，一是必须快速应答，返回非SUCCESS微信会重试多次；二是要做幂等，因为微信可能在极端情况下重复推送同一个支付结果。第3步的判断就是在防重复，订单已经是已支付就直接返回成功，不再改库。金额校验必须做，曾经有人只验签没验金额，结果被改单攻击，回调里把金额改小了也照样入库。

参数说明里最容易翻车的是两个点：notifyUrl必须和外网可访问的地址完全一致，并且域名要和微信支付平台配置的授权域名匹配；certPath在Windows联调时写的盘符路径到了Linux服务器上必须换成绝对路径，不然启动时找不到证书直接抛异常。本地联调阶段，常见做法是用内网穿透把回调地址映射到本机，这样才能在IDE里打断点看回调报文。

4.3 退款：状态机与幂等控制

退款比支付更敏感，因为它涉及资金从商户账户往外走。退款入口不在用户端，而是后台管理端的订单详情页。简化逻辑是：管理员发起退款 → 后端调微信退款接口 → 微信异步返回退款结果 → 更新退款单和订单状态。

退款的状态流转可以用这张表理解：

退款业务里最容易忽略的是幂等。同一个退款单被管理员手抖点两次提交，如果没有退款单号去重，资金会退两次。常见做法是退款前查退款表，同一个原订单号如果已经存在处理中的退款单，直接提示「退款处理中，请勿重复操作」。同时注意订单退款后要恢复库存，这个动作也要放在同一个事务里，别退款成功了库存忘记加回来，导致财务对不上。

这章看完你应该对核心链路有把握了。一个用户从下单到退款，后端所有状态变化基本被上面三块覆盖，二开新增支付方式时，照着微信这套回调流程扩展支付宝或云闪付即可。

5. CRMEB Java版v2.0.1避坑指南：数据库、静态资源与支付回调的5个坑

5.1 MySQL8驱动报错：ClassNotFoundException和Unknown database

现象：本地装的是MySQL8，启动时日志抛出找不到驱动类，或者报Unknown database 'crmeb_java'，但数据库明明建好了。

原因：发行包默认驱动是com.mysql.jdbc.Driver，这是MySQL5.x时代的类名，MySQL8的驱动包已将它移除；同时MySQL8默认认证插件是caching_sha2_password，旧连接串没带对应参数会认证失败。

解决：把驱动类改成com.mysql.cj.jdbc.Driver，连接串里追加allowPublicKeyRetrieval=true。改完这两处，MySQL8基本都是秒连。如果还想少改一处，直接把数据库降到5.7，用默认驱动不用动配置。

5.2 Redis连不上：报错集中在登录、购物车和点赞

现象：后台页面大部分能开，但登录、购物车、点赞这类接口报RedisConnectionFailureException。更迷惑的是启动过程不报错，只有业务请求才炸。

原因：Redis配置的密码或database与本地实际环境不一致。比如Redis设了密码，配置里却是空的；或者配置连的是默认database 0，而你的键都写在database 1。

解决：先撇开Java，用命令行验证Redis本身通不通。redis-cli -a 密码 ping返回PONG再回头看配置。把spring.redis.password和spring.redis.database对齐本地。这个坑四十秒能排查完，前提是你别在IDE里翻半天日志，直接查配置对比最快。

5.3 图片上传成功但页面不显示

现象：上传商品图接口返回200，文件也确实落在磁盘目录里，但前端<img>标签的地址访问404。

原因：crmeb.upload.path（物理路径）和crmeb.upload.url（访问前缀）两个配置没对上。比如物理路径是/data/www/upload，访问前缀写成/upload，但代码里映射静态资源的规则是path直接对外，导致请求/upload/xxx.jpg映射不到正确目录。

解决：统一成一套前缀。把url写成http://localhost:8080/upload对应的含义，保证浏览器访问/upload/1.png时，后端映射到磁盘/data/www/upload/1.png。这个配置属于典型的「改完不生效就怀疑代码，其实只是路径拼接规则没理解」的坑，静态资源映射代码一般不需要动。

5.4 支付回调收不到或验签失败

现象：用户在小程序里支付成功，微信账单也扣款了，但商城后台订单还是「待支付」。

原因：三类情况最常见。一是notifyUrl配的是http://，微信支付要求https且域名需备案。二是商户证书路径在Linux服务器上不存在，进程启动时某些模块懒加载所以没立刻报错，直到收到回调才抛异常。三是回调接口没有放在免登录白名单里，被拦截器拦下返回401。

解决：本地联调用内网穿透把https://xxx.穿透域名/pay/notify指到本机，看IDE里的回调日志；验签失败时打印完整报文和本地重算签名做对比，基本一眼能看出是密钥长度不足还是证书路径不对。上线前用微信支付平台的「回调测试」功能，直接往你的接口发一条测试报文，这个步骤能省掉上线后半小时的慌张排查。

5.5 带前缀部署后接口404和502

现象：用Nginx把商城部署到二级目录，比如访问https://域名/crmeb/admin，结果登录接口302、静态资源404，部分接口502。

原因：Nginx反代时把/crmeb前缀带到了后端，而后端接口路径本身是/admin开头，两级拼接变成/crmeb/admin，后台接口找不到。502则是反向代理地址配错，比如proxy_pass少写了端口。

解决：明确区分「有前缀」和「无前缀」两种部署形态。无前缀最简单，location / { proxy_pass http://127.0.0.1:8080; }即可。有前缀时后端代码通常要加server.servlet.context-path=/crmeb，Nginx里用proxy_pass http://127.0.0.1:8080/（注意末尾斜杠）剥离前缀。这个坑的症状特别像后端代码问题，但根因基本都在Nginx转发规则，排查时先看后端访问日志里实际收到的路径是什么。

6. 上线前的一小时：多商户改造思路与性能检查清单

6.1 上线前检查清单

最后这一小时不只是看看功能，我一般按下面这张表逐项过一遍，通过了才敢切生产：

6.2 多商户改造：从单商户到多商户的最小改动

如果你后续想把单商户商城升级为多商户平台，不要推翻重来。最小改动方案是：在用户表加merchant_id字段，订单表加merchant_id并建普通索引，商品表同理；Service层每个写入操作都显式带上当前商户ID，查询用merchant_id过滤。真正的工作量在于后台管理端需要加一个「商户维度」的筛选和结算模块，这部分建议在单商户稳定运行后再演进，不要一上来就两边同时动。

6.3 压测与慢SQL验证

上线前压一下核心接口，至少要知道这台服务器的极限在哪。简单的做法是用ab工具打商品列表接口：

ab -n 1000 -c 50 http://localhost:8080/api/goods/list

关注两个指标：Requests per second和Failed requests。如果吞吐量低得离谱，开MySQL慢日志看是不是有全表扫描：

SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 1;

再看慢查询记录里哪些SQL走了全表，给高频查询字段补上索引。

最后说件真实吃过亏的事。帮人维护一个用这套系统搭的商城，上线当天没清掉测试环境产生的脏数据，结果客户第一眼看到后台里几十条乱码订单，印象分直接清零。从那以后我养成了习惯：每次上线前一小时，第一件事是核对数据库里核心表的数据量，先确认是干净的生产数据再开流量。这个习惯帮我挡掉了不少丢人的场面。做交付的朋友，可以先把这条记下来。希望帮到你。

本文还有配套的精品资源，点击获取