企业官网建设流程全解析

简介：这是一份基于 SpringBoot 的电商商城前后端完整工程，整合 Redis 缓存、MyBatis 持久层、JWT 鉴权以及 Vue 全家桶技术栈，面向需要完整项目参考的 Java 全栈学习者、毕业设计者与二次开发人员。项目包含 PC 端商城界面与后台管理系统，覆盖用户管理、商品管理、店铺管理、订单管理、促销与统计等完整业务模块，压缩包内附带 SQL 建表及初始数据脚本，解压配置后即可快速搭建运行环境。资源共 1598 个文件，压缩后 125.68MB，java 源码与 class 文件对应后端业务逻辑，js/css/html 以及 png/jpg/gif 支撑前端页面与交互，ftl 模板和 xml 映射配合 MyBatis 完成数据库操作，jar 包收录第三方依赖，整体目录按功能拆分，便于逐模块阅读与调试。已有 1170 人浏览学习，适合想梳理前后端分离架构、理解购物车与订单核心流程的开发者，具备较高的实践参考价值。

1. 一个压缩包就是一整套商城：先认清它解决什么问题

springboot商城(前后端代码+sql脚本).zip这个压缩包，听起来就是一个普通资源包，但打开之后你会发现它是三件套：Spring Boot 后端工程、前端页面源码、初始化数据库的 SQL 脚本。它的价值在于，你不需要从零搭框架、写表结构、调权限，解压后理论上能直接把一个商城雏形跑起来。它适合三类人：想做 Java 毕设的学生，需要一个能演示、能改的完整项目；小团队想快速搭私域商城做二次开发；运维或后端新人想研究一套真实项目的代码组织方式。不过别高兴太早，这类包最常见的翻车点不是代码本身，而是你不知道怎么把它从压缩包状态变成运行状态。下面按我自己的习惯，从解压盘点到跑通实测，再到改造上线，一步步讲清楚。

2. 解压后先别急着跑：用文件指纹确认技术栈和前后端边界

2.1 先盘目录：一眼分清后端、前端和脚本的位置

我拿到这类压缩包的第一件事，不是解压然后双击启动类，而是先看压缩包里面的目录结构。用 unzip 命令先扫一遍：

unzip -l shop.zip | head -60

-l是 list 模式，不解压直接列出压缩包内容，head -60只看前 60 行，足够判断顶层目录长什么样。如果看到pom.xml、src/main/java、src/main/resources这三个标志，后端就是标准的 Maven 工程；如果看到package.json、src/views、src/api这类目录，前端就是独立的 Node 工程。这是前后端分离项目的典型结构。

但这里有个坑：很多压缩包解压后是多层嵌套目录，比如shop/shop-admin/shop-server。所以我会再执行一次 find，把工程文件的位置一次性找出来：

find . -maxdepth 3 -type f \( -name "pom.xml" -o -name "build.gradle" -o -name "package.json" -o -name "*.sql" \) | sort

maxdepth 限制在 3 层，避免把target、node_modules里的垃圾文件也扫进来；sort让输出按路径排序，方便看清每个工程文件的归属。这一步做完，你就能画出这个包的结构图：哪个目录是后端、哪个目录是前端、SQL 脚本放在哪里。

2.2 从 pom.xml 判断后端技术栈和 Spring Boot 版本

找到pom.xml之后，直接看依赖，这决定了你本地环境要装什么软件、用哪个 JDK 版本：

grep -E "artifactId|groupId" pom.xml | head -80

重点看几个关键依赖：spring-boot-starter-web是必须的；mybatis-spring-boot-starter说明数据层用的是 MyBatis，SQL 写在 mapper XML 里；spring-boot-starter-data-redis说明缓存和验证码很可能依赖 Redis；spring-boot-starter-security或jjwt说明登录鉴权用的是 Spring Security 或 JWT 拦截器。还有spring-boot-starter-parent里的版本号，2.7.x 分支可以用 JDK 8 或 11，3.x 分支就必须 JDK 17 起步。这一步不确认，后面大概率要翻车。

我见过不少新手拿着 Spring Boot 3.x 的商城包，本地却装的是 JDK 8，启动直接报UnsupportedClassVersionError，还以为是代码缺了什么依赖。先看清楚版本，能省掉一整晚的排查时间。

2.3 从 package.json 判断前端形态和启动方式

后端确认完看前端，用cat package.json看启动脚本：

cat package.json | head -40

scripts里的dev和build字段决定了前端怎么跑。如果devDependencies里有vite，说明是 Vue 3 + Vite 的新工程；如果是vue-cli-service，说明是 Vue 2 或 Vue 3 + Webpack 的旧工程。这两者的代理配置写法完全不同，Vite 用server.proxy，Vue CLI 用devServer.proxy，后面联调阶段要区分。

这里还有个容易忽略的情况：如果解压后根本没有package.json，只有src/main/resources/templates和static目录，说明这个包不是前后端分离项目，而是 Spring Boot 直接渲染 Thymeleaf 模板或静态页面的单体项目。这时候不要去找前端启动方式，直接启动后端，然后用浏览器访问 8080 端口就行。

2.4 检查 SQL 脚本的编码和导入形式

最后过一遍 SQL 脚本，用 file 命令确认编码：

file sql/*.sql

输出会告诉你脚本是 UTF-8 还是 GBK。这一步非常重要，很多老项目是 GBK 编码，在 Windows 上打开正常，直接导入 MySQL 后所有中文全变问号。确认编码之后，再用 head 看脚本开头：

head -30 sql/*.sql

如果开头有CREATE DATABASE shop和USE shop，说明脚本自带建库逻辑，你要么有库权限，要么提前手动建好同名字库；如果直接就是CREATE TABLE，那得先手动建库再导入。

3. 把商城跑起来：数据库导入、后端启动、前端联调的完整顺序

3.1 先导 SQL 脚本：用 source 而不是 GUI 导入

我习惯用命令行导入脚本，不用 Navicat 的“运行 SQL 文件”功能，因为命令行能看到每一步的报错，而且编码控制更直接：

mysql -h 127.0.0.1 -P 3306 -u root -p \ --default-character-set=utf8mb4 \ -e "source /path/to/解压目录/sql/shop.sql"

-h指定主机，-P指定端口（注意大写），-p回车后输入密码；--default-character-set=utf8mb4让客户端以 utf8mb4 编码传输，避免中文乱码；source是 MySQL 客户端的内部命令，适合执行包含多语句的脚本。如果你用的是 MySQL 8.0，密码认证默认是caching_sha2_password，而老项目驱动可能只支持mysql_native_password，导入成功后连接时还要留意驱动版本。

导入完成后别急着关终端，先登录 MySQL 确认表数量：

mysql -u root -p -e "USE shop; SHOW TABLES;"

正常一个商城项目会有 20 到 40 张表，核心表包括sys_user、product、product_category、order、order_item、cart_item、shipping_address、payment_log。如果你只导入成功了几张表，说明脚本中途报错停掉了，要从上一个报错点回去查。

3.2 改配置文件：这 3 处不改成不了一个好项目

后端启动前必须改application.yml（有些包是application.properties），不改的话要么连不上数据库，要么 Redis 连不上，要么端口冲突。最常见的三段配置长这样：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/shop_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 database: 0

url里的serverTimezone=Asia/Shanghai是必改项，MySQL 8.0 以上不写会报时区错误；useSSL=false是本地开发的常规选择，生产环境再按需开启；driver-class-name用com.mysql.cj.jdbc.Driver（8.0 驱动），如果包里的配置写着com.mysql.jdbc.Driver，说明它按 MySQL 5.x 写的，升级驱动后记得同步改掉。password一定改成你自己数据库的密码，这一步漏了是新手最常见的“启动即失败”。

Redis 段也要注意：如果项目登录用 JWT，Redis 可能只用来存验证码和购物车；如果它用了 Spring Session，Redis 挂了整个登录链路都起不来。本地没有 Redis 的话，先去装一个，稍后细说。

3.3 后端启动：先 Maven 打包再运行，避免 IDE 玄学问题

配置改完后端就有两种启动方式，简单粗暴的是在 IDEA 里直接运行main方法，但更可控的方式是命令行 Maven 打包：

mvn clean package -DskipTests

clean清掉上次的编译产物，package打成可执行 jar，-DskipTests跳过测试。如果你本地 Maven 拉依赖特别慢，八成是没配国内镜像，在~/.m2/settings.xml的mirrors节点加一段阿里云镜像：

<mirror> <id>aliyun</id> <url>https://maven.aliyun.com/repository/public</url> <mirrorOf>central</mirrorOf> </mirror>

打包完成后启动：

java -jar target/shop-1.0.0.jar --spring.profiles.active=dev

--spring.profiles.active=dev是可选参数，如果包内有application-dev.yml才会生效，没有的话去掉即可。启动日志刷完之后，看到Started Application in xx seconds就算后端起来了。

3.4 前端启动：npm install 之后别忘代理配置

前端是 Vue 工程的话，进入前端目录执行：

npm install --registry=https://registry.npmmirror.com

--registry指定 npm 镜像源，国内下载依赖能快很多。装完之后跑开发服务器：

npm run dev

启动日志会显示访问地址，一般是http://localhost:5173。但前端页面能打开不代表能登录，前后端联调需要把 API 请求代理到后端 8080。以 Vite 工程为例，在vite.config.js里配置：

export default defineConfig({ server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } })

/api是前端请求的统一前缀，target指向后端地址，changeOrigin: true是让后端收到的请求头里的 Host 变成后端地址，避免某些拦截器误判。如果后端接口本来就没有/api前缀，代理也要跟着改，比如前端请求的是/product/list，那 proxy 的 key 就写/product。这一步不做，前端会一直报 404 或 CORS 错误。

4. 启动阶段的五个高频避坑点：从乱码到端口冲突的排查记录

4.1 SQL 脚本导入后中文全是问号

现象：source导入没有任何报错，但打开表一看，商品名称、分类名称全是???。

原因：脚本文件本身是 GBK 编码，或者连接字符集没有设置成 utf8mb4。如果你在 Windows 上用记事本打开文件正常，但 Linux 终端下看到乱码，基本就是编码问题。

解决：先确认编码再导入，用file命令判断，如果是 GBK，先转码：

iconv -f GBK -t UTF-8 shop.sql > shop_utf8.sql

转换后再按前面提到的方式导入，并保持--default-character-set=utf8mb4。导入后抽查一张表，确认中文正常再继续。

4.2 后端启动后立刻退出：端口占用

现象：启动日志最后一行报Web server failed to start. Port 8080 was already in use，进程直接退出。

原因：本机有其他服务占了 8080。Spring Boot 并不会自动换个端口，它只会抛异常退出。

解决：Windows 下用netstat -ano | findstr 8080找到占用进程的 PID，再在任务管理器里结束它；Linux 下用lsof -i:8080查看。不想动现有服务的话，直接改配置文件里的server.port，比如改成 8081。改完之后前端代理的target也要同步改，否则前端还是往 8080 发请求。

4.3 Redis 没启动，登录接口一直超时

现象：后端启动成功了，前端也能打开，但点击登录后接口转圈几十秒，最后报连接超时；后端日志里出现JedisConnectionException或Unable to connect to Redis。

原因：商城的验证码、Session 或购物车数据放在 Redis，但本地 Redis 服务没启动，或者配置里的密码和本地不一致。

解决：本地先执行redis-server启动默认的 Redis 服务，确认端口 6379 正常监听。如果 Redis 设置了密码，application.yml里要写spring.redis.password，否则客户端连接直接被拒。这一步做完后重启后端，验证码接口就能正常返回。

4.4 MyBatis 报 Invalid bound statement

现象：项目正常启动，但一调用商品查询接口，后端日志报Invalid bound statement (not found): com.shop.mapper.ProductMapper.selectList。

原因：Mapper 接口编译进了 target/classes，但 mapper XML 没有一起打进去。很多商城包的 mapper XML 写在src/main/java目录下，Maven 默认不打包java目录里的 XML 文件。

解决：检查 target/classes 下的 mapper 目录是否有 XML 文件，没有的话在 pom.xml 增加资源配置：

<build> <resources> <resource> <directory>src/main/java</directory> <includes> <include>**/*.xml</include> </includes> </resource> </resources> </build>

加上这段之后重新mvn clean package。这个坑非常隐蔽，因为 IDE 里直接跑往往没问题，打包后才暴露。

4.5 前端登录成功但业务请求全是 CORS 报错

现象：浏览器控制台报No 'Access-Control-Allow-Origin' header is present，前端页面能打开，但所有 API 请求全被浏览器拦截。

原因：前后端分离项目，前端页面在 5173 端口，后端在 8080 端口，跨域了。商城项目里登录接口可能单独加了跨域放行，但商品列表、购物车等接口没有。

解决：开发环境最省事的做法是配前端代理（前面提过的 Vite proxy 配置），而不是在后端加“允许所有来源”的万能跨域。我见过有人为了省事在后端加全局 CORS 配置，结果线上接口被任意来源调用，这是安全漏洞，别这么干。

5. 改造成自己的项目：登录、支付、数据字典这三个地方先动刀

5.1 登录鉴权改造：从“能跑”到“自己的账号体系”

商城项目跑起来之后，第一件事是换掉默认的管理员账号。这类项目默认账号一般是admin，密码在 SQL 脚本里写死，像我见过有的直接明文123456，有的用$2a$10$...这种 BCrypt 密文。明文密码必改，密文密码也要知道明文是什么才方便后续操作。

改造的最小路径是保留原有登录逻辑，只替换用户表和密码加密方式。以 Spring Security + BCrypt 为例，注册或重置密码的代码里用加密器：

@Autowired private PasswordEncoder passwordEncoder; // 新密码加密后入库 String encodedPassword = passwordEncoder.encode("你的新密码");

passwordEncoder在 Spring Boot 里通常由SecurityConfig注入一个BCryptPasswordEncoder实例。确认项目里用的是这一套，然后把 SQL 脚本里的初始化密码替换掉：

UPDATE sys_user SET password = '$2a$10$...' WHERE username = 'admin';

这里的$2a$10$...是你用加密器生成的密文，必须先运行一次注册或重置密码的代码拿到真实值再替换。如果项目用的是 JWT 拦截器而不是 Spring Security，那就找到LoginController或AuthController里校验密码的地方，确认用的是matches(rawPassword, encodedPassword)而不是equals。

5.2 支付模块摸底：别等上线才发现是写死的假成功

商城项目的支付模块是最需要警惕的部分。很多演示项目没有对接真实支付，所谓支付成功就是把支付状态字段直接置为“已支付”，这在自己玩的时候没问题，但如果你要拿来接真实业务，必须先摸清支付接口的实现。

先找PayService接口和实现类，看支付回调是怎么处理的。真实支付链路通常是：下单 → 调支付网关生成支付链接 → 用户支付 → 网关回调 → 修改订单状态和支付流水。演示项目最常见的偷懒写法是：前端点“确认支付”→ 后端直接返回支付成功 → 订单状态改成已支付。判断方法很简单，搜索代码里有没有alipay或wxpay之类的 SDK 依赖，以及有没有回调地址相关的 controller。没有的话，要么接入真实支付网关的沙箱环境，要么先改造出本地收银台记录流水，保证订单状态流转是真实的。

这里有个原则：只要涉及退款、对账、订单超时未支付关闭，假支付逻辑一定会漏出破绽。哪怕只是为了答辩或演示，也建议至少把支付流水表的数据写真实，否则演示到一半系统状态对不上，反而更尴尬。

5.3 数据字典和演示数据：把轮播图、分类、商城配置全换掉

SQL 脚本里的初始化数据一般是演示性质，轮播图是别人的商品图，分类是别人的类目，商城标题可能写的是另外的品牌名。这些东西影响很大：前端首页默认调用banner表和product_category表，如果你不换，访客打开你的商城会觉得这就是一个别人用过的模板。

我一般会先清掉这几类数据再重新导入自己的：

-- 清空演示数据并重置自增ID TRUNCATE TABLE banner; TRUNCATE TABLE product_category; TRUNCATE TABLE product; -- 插入自己的类目 INSERT INTO product_category (id, name, sort_order) VALUES (1, '数码家电', 1); INSERT INTO product_category (id, name, sort_order) VALUES (2, '服饰鞋包', 2);

TRUNCATE比DELETE好在会重置自增主键，避免新数据从很大的 ID 继续增长。同时检查sys_config或mall_config表，把商城名称、客服电话、首页标题、ICP 备案这类展示字段也替换掉。这些数据虽然不影响代码运行，但影响项目展示出来的专业度，尤其是拿去做毕设演示时，评委会很在意这些细节。做完这三步，这个包才算从“别人家的商城”变成“能交差的商城”。

6. 部署前的一小时体检：用探活脚本验证商城真的能跑

项目改完准备交付或部署前，我习惯做一轮接口探活，而不是打开浏览器点两下就算完。探活脚本很简单，直接用 curl 验证三条核心链路：登录、商品列表、订单查询。

# 1. 登录接口，拿到 token curl -s -X POST http://localhost:8080/api/login \ -H "Content-Type: application/json" \ -d '{"username":"admin","password":"你的密码"}' # 2. 带 token 查询商品列表 curl -s http://localhost:8080/api/product/list -H "Authorization: Bearer 粘贴上一步返回的token" # 3. 查询订单（预期返回订单列表或空列表） curl -s http://localhost:8080/api/order/list -H "Authorization: Bearer 粘贴上一步返回的token"

这三条命令分别验证了登录鉴权链路、数据库读链路、Redis 缓存链路。如果登录成功但商品列表返回 500，说明 MyBatis 或数据库有问题；商品列表正常但订单报错，说明订单相关表没导全或权限配置没放开。

上线前还要看一眼启动日志里的关键字，我列一个最简单的检查清单：

这套体检做完，我会把探活命令存成一个check.sh，和 SQL 脚本放同一个目录。以后每次改动依赖或配置，先跑一遍脚本再汇报进度，省得反复被问“到底跑起来没有”。

这类项目和资源包我前后接手过不少，最早也遇到过打开就报错、表格全乱码的情况。后来养成一个习惯：拿到任何新项目，先花二十分钟确认技术栈和边界，再动手改配置。前面省下的时间，后面都会加倍还给你。希望帮到你。

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