企业官网建设流程全解析

这套二手车交易管理系统，是我最近完整做完并跑通的一个全栈项目。从需求梳理到数据库设计，再到SpringBoot + Vue + MyBatis + MySQL这套组合的落地实现，中间踩了不少坑，也积累了一些比较实用的经验。如果你正打算做毕业设计、个人全栈项目，或者想拿二手车业务练手，这篇文章会非常合适。我不打算讲一堆空泛的理论，而是直接告诉你这个系统怎么拆、表怎么建、接口怎么写、前端怎么对接、最后怎么打包成可运行的jar，同时把容易出问题的地方全都标注清楚。读完你收获的不只是一份源码，而是一套可以自己动手复现的思路。

1. 这套二手车系统要解决什么问题，为什么选这套技术栈

1.1 业务场景与功能范围

二手车交易和普通电商不一样，它的商品是非标的。每台车的车况、里程、排放标准、变速箱类型都不同，而且交易过程里还有线下看车、过户、付款这些环节，单纯套用一个商城系统肯定别扭。管理系统的核心目标，是把车源信息数字化、把订单流转管起来、把买卖双方的沟通留痕，减少“信息全部靠人工”导致的差错。

从我实际梳理的需求看，这个系统至少要覆盖三类角色：普通买家、车商/卖家、平台管理员。买家有注册登录、浏览车辆、多条件筛选、查看详情、收藏车辆、下订并跟踪订单状态这些操作；卖家需要发布车源、管理自己名下的车辆上下架；管理员则要审核并管理车源、处理用户和订单、维护品牌数据。项目一开始如果不把权限边界理清楚，后面写角色判断时会非常痛苦。

而车辆信息的筛选是二手车系统里最核心的功能之一。买家通常会按品牌、价格区间、车龄、里程、变速箱、排放标准来过滤车源，前后的排序还可能包含发布时间、价格高低。改造成本最低的做法就是前端传查询条件，后端用动态SQL拼过滤条件，既不牺牲灵活性，也不会因为场景简单而去过度设计。

1.2 技术选型：每一样东西为什么出现在这里

SpringBoot，说白了就是把Spring繁琐的配置自动化，起步依赖帮你把常用的组件拉齐，内嵌Tomcat也省去了单独部署Servlet容器的麻烦。Vue负责页面交互，组件化以后车辆的列表页、详情页、发布表单都能拆成独立文件，改起来不连累其他页面。MyBatis是一个轻量级持久层框架，它的XML配置方式让我能精确控制SQL，二手车这种筛选条件多、查询动态变化大的场景，写动态SQL非常灵活。MySQL则是免费、稳定、社区资料极多的关系型数据库，对于中小规模的管理系统完全够用。

这套组合选型的基本逻辑是：前端要快速迭代，后端要易于维护，SQL要可控。如果换成JPA，虽然实体映射写起来省事，但复杂查询和多表关联反而要多写“绕路”代码；如果换成MyBatis-Plus，也完全可行，它封装了很多单表CRUD，适合快速开发，但定制化SQL能力仍然需要依赖XML。对于我这种要求“每个查询逻辑都看得明白”的人，原生MyBatis反而用得最顺手。

版本方面，建议直接使用Spring Boot 2.7系列或3.x系列，JDK对应17以上。新手要注意的是，Spring Boot 3.x和Spring Boot 2.x在依赖坐标、javax到jakarta命名上都有差异，照着旧教程配置容易报错。个人项目我推荐Spring Boot 2.7 + JDK8/11，资料最多，踩坑成本最低；如果你的机器已经是JDK17或者想用更新特性，再上Spring Boot 3。

2. 从表结构开始：先把数据模型铺平，后面实现才不别扭

2.1 核心数据表与字段设计

数据库设计是整个系统最容易返工的环节。我在第一次做的时候直接按照页面原型建表，结果订单状态一变，发现很多字段设计成固定列，根本撑不住业务变化。后来我把核心表控制在六张：用户表、品牌表、车辆表、订单表、收藏表、公告表，把角色字段和状态字段都设计成可扩展的int类型，后面新增状态时只需要加数字约定，不需要改表。

车辆表是信息最密集的一张表，大致字段可以这样规划：

订单表我特意把amount单独拎出来，不直接读车辆表的price。这样即使卖家中途改价，已生成的订单仍然保留了下单那一刻的成交价格，历史数据不会跟着翻。status用0待支付、1已完成、2已取消，以后需要增加“交易中”“已退款”状态，直接加数字就行，不用改字段结构。

外键我在实际项目里用得比较少，更多是保留逻辑关联字段，比如order表里有user_id和car_id，但我不在数据库层面强制建外键约束。原因很简单：项目迭代过程中，逻辑外键足够保证开发效率，也避免了外键约束带来的插入、删除顺序限制。真正保障一致性的地方放在service层事务里处理，这也更符合现在Spring Boot项目的常见做法。

2.2 下划线字段与驼峰映射：一篇配置省下大半麻烦

MySQL的表字段我习惯用snake_case命名，比如create_time、owner_id，而Java实体类用驼峰命名，比如createTime、ownerId。MyBatis里开启一项配置后，就能自动完成下划线到驼峰的映射，不用每个字段都写resultMap，代码会干净很多。

在application.yml里，这个配置长这样：

mybatis: configuration: map-underscore-to-camel-case: true mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.secondhand.entity

有了map-underscore-to-camel-case: true之后，select * from car查询出来的create_time就能直接赋给Car实体里的createTime属性。mapper-locations则告诉Spring Boot去哪找XML文件，这个路径一旦写错，启动就会报Invalid bound statement (not found)，是我见过最高频的启动报错之一。

实体类我强烈建议加Lombok，用@Data注解省略getter/setter。这套系统里面实体字段多，手写getter/setter真是白费时间，而且一旦改动字段，漏改某个getter的问题也不好查。有了Lombok，实体类瞬间缩减到字段+注释，可读性高很多。

2.3 状态字段与索引：前期约定，后面少踩坑

车辆表和订单表都有status字段，这里有一个习惯值得养成：状态字段不要用字符串存中文，比如“上架”“已售”，而应该用数字映射。原因有两个，一是中文受字符集影响，换库容易乱码；二是数字做查询和索引都比字符串更快。项目里甚至可以专门写一个枚举类，把1、2、3映射成业务含义，在代码里写清楚，别人接手也看得懂。

索引也不能马虎。我实际查询最频繁的字段是status、brand_id、price和create_time。单表数据量还小的时候，全表扫描没什么感觉，但车源一旦上千条，每次筛选都扫全表就会拖慢时间。我给status和brand_id建了普通索引，给price和create_time建了组合索引，查询速度明显提升。这里不必过度设计，对二手车系统来说，两三个有效索引已经足够。

还有个细节很容易忽略：car表里images字段我用TEXT存储多张图片地址，查询详情时前端拿到逗号分隔字符串，再split成数组渲染即可。数据库本身不建议存JSON，但在小型管理系统里，把图片列表这种不常参与查询的数据聚合存储，反而减少了大量关联表查询，是实用取向的做法。

3. 后端实现：SpringBoot + MyBatis 如何写业务接口与事务

3.1 SpringBoot工程结构与关键配置

后端我按标准的controller、service、mapper、entity四层去组织。Controller只负责接收参数、校验参数格式、返回统一结构，Service里放业务规则，Mapper和XML管SQL。有的项目喜欢再包一层DTO和VO，但对于二手车管理系统，把请求参数用Map或者简单POJO接收就能解决问题，强行加中途层反而增加理解成本。

统一返回结构这一点，一定要在一开始就定好。我定义了一个Result类，包含code、message、data三个字段，所有接口都返回这个结构。前端一起封装的axios拦截器，只需要判断code是否等于200即可，异常信息通过message展示给用户。这个结构看起来简单，但真的能避免前后端联调时各写各的格式，是我强烈建议保留的做法。

application.yml里还要写数据源配置。MySQL 8.x版本下，我推荐这样配：

spring: datasource: url: jdbc:mysql://localhost:3306/secondhand?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver

url里的serverTimezone和allowPublicKeyRetrieval是最容易出问题的两个参数。时区不写，连接MySQL 8会报server time zone的异常；allowPublicKeyRetrieval不写，某些MySQL 8连接方式会报Public Key Retrieval is not allowed。这两条都是无数新手卡的经典问题，先写上去能省很多排查时间。

3.2 MyBatis XML里最常用的查询写法

筛选条件多的时候，MyBatis的XML动态SQL是我最喜欢的一部分。比如车辆列表接口，前端可能传来brandId、minPrice、maxPrice、keyword、gearbox这些参数，每一次用户选择的组合都不同。如果用Java代码拼SQL，不仅代码烦琐，还可能遗漏判断；而XML里用 和 组合，逻辑一目了然。

下面这段是我在实际项目里的典型写法：

<select id="selectCarList" resultType="com.example.secondhand.entity.Car"> select * from car <where> <if test="brandId != null"> and brand_id = #{brandId} </if> <if test="keyword != null and keyword != ''"> and title like concat('%', #{keyword}, '%') </if> <if test="minPrice != null"> and price &gt;= #{minPrice} </if> <if test="maxPrice != null"> and price &lt;= #{maxPrice} </if> <if test="gearbox != null"> and gearbox = #{gearbox} </if> and status = 1 </where> order by create_time desc limit #{offset}, #{pageSize} </select>

这里有几个值得注意的点：like查询记得用concat拼接百分号，不要自己在前端拼好再传过来，否则容易引发SQL注入；price的“>=”和“<=”在XML中要写成>=和<=，否则XML解析不过；手动分页用limit offset, pageSize，简单可控。分页插件PageHelper我也用过，确实是好用的工具，但个人项目里手写分页更透明，也不会遇到插件和Spring Boot版本不兼容的烦恼。

如果查询结果需要返回两个id字段名完全一样的关联数据，比如车辆表和品牌表都有name，这时候就别偷懒了，老老实实写 或者给字段起别名，否则MyBatis映射时必然混淆。很多“车源列表品牌名称显示不对”的问题，根源就在这。

3.3 下订单接口：事务和并发控制一起说

下订单是系统里业务逻辑最重的接口，也是必须加事务的地方。完整流程是：用户请求下单接口，后端先判断车辆是否存在且status等于1，然后把status改成3锁定，避免别人再下订，接着生成订单号并计算成交价格，最后把订单插入order表。

为什么要用@Transactional？因为“改车辆状态”和“插入订单”是两个独立的数据库操作，中间任何一个失败，都可能出现车被锁了但订单没创建的尴尬情况。加上事务之后，两步操作要么都成功，要么都回滚，数据一致性才有保障。我在Service方法上这么写：

@Transactional(rollbackFor = Exception.class) public void createOrder(Long userId, Long carId) { Car car = carMapper.selectById(carId); if (car == null || car.getStatus() != 1) { throw new BusinessException("车辆不存在或已下架"); } int updated = carMapper.lockCar(carId); if (updated == 0) { throw new BusinessException("该车已被预订，请看看其他车源"); } Order order = new Order(); order.setOrderNo(generateOrderNo()); order.setUserId(userId); order.setCarId(carId); order.setAmount(car.getPrice()); order.setStatus(0); orderMapper.insertOrder(order); }

这里的carMapper.lockCar方法在SQL层面执行update car set status = 3 where id = #{id} and status = 1。靠where status = 1来保证更新的行数是0还是1，是一种最简单也最可靠的行级并发控制手段。两个用户同时下单同一辆车时，数据库的行锁会保证只有一个update执行成功，另一个updated为0，自然就抛异常了。这比先查再改的“检查再操作”模式安全得多，后者在并发下很容易出现超卖。

订单号我直接用时间戳加随机数生成，比如yyyyMMddHHmmss加四位随机数，够用且不会太复杂。生成前要记得判断重复，虽然概率极低，但订单号重复会造成业务上的严重事故。

3.4 登录鉴权与密码处理

登录鉴权我没有引入复杂的Spring Security，而是用一个轻量方案：JWT加拦截器。用户登录成功后，后端生成一个携带用户id和角色的token返回给前端，前端保存到localStorage，之后的每个请求都在请求头带上Authorization。后端写一个拦截器，解析token并把用户信息放进请求上下文，HandlerInterceptor大几百行就能写完，足够支撑这个系统的权限需求。

密码存储必须用BCrypt加密，绝对不要明文存库。开发库和生产库一旦泄露，明文密码就是整个系统的灾难。Spring Boot里引入spring-security-crypto这个依赖，只使用里面的BCryptPasswordEncoder来加密和校验密码，不需要启动完整的Security过滤链，使用成本很低。我以前为了省事存过MD5，后来发现撞库太容易，后悔得很。

角色区分用user表里的role字段，0表示管理员，1表示普通用户。管理员接口上用一个@RequireAdmin注解配合拦截器判断角色，没有权限直接返回code 403。这套过滤逻辑虽然不如Spring Security完善，但胜在容易理解，对于相关的教学和个人项目，够用且好维护。

4. 前端页面与接口对接：Vue组件、路由和请求封装

4.1 Vue工程搭建与路由设计

前端我用Vue 3加Vite构建。Vite的启动速度比Webpack快太多，改代码热更新几乎是即时的，开发体验对提高效率很有帮助。组件库选择Element Plus，表格、表单、对话框这些后台管理常用组件都有现成的，能节省大量写CSS的时间。

创建工程很简单：

npm create vite@latest frontend -- --template vue cd frontend npm install npm install vue-router axios element-plus

路由我用createWebHistory模式，页面路径比较干净。但history模式有一个典型代价：用户在前端路由里刷新页面时，如果部署环境没有做“所有路径都指向index.html”的兼容，会返回404。我在开发时更推荐hash模式，也就是createWebHashHistory，URL带#号但绝不会刷新404，适合个人项目和教学演示。如果你坚持要漂亮的路径，那生产环境一定要配合后端或者Nginx做好fallback，后面部署章节会重点提。

路由守卫是权限控制的前端入口：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.path !== '/login' && !token) { next('/login') } else { next() } })

这段逻辑让未登录用户不管怎么跳转，最终都会被带到登录页。后端拦截器再兜底一次，前端路由守卫主要是提升交互体验，真正验证token是否有效还是后端说了算。

4.2 axios封装与跨域调试

axios如果不封装，每个页面里都直接写请求路径和错误处理，代码会迅速失控。我一般建一个request.js文件，实例化一个axios对象，设置baseURL为/api，再添加请求拦截器和响应拦截器。

import axios from 'axios' import { ElMessage } from 'element-plus' import router from '@/router' const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = 'Bearer ' + token } return config }) request.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.message) return Promise.reject(new Error(res.message)) } return res.data }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') router.push('/login') } ElMessage.error('网络请求失败，请稍后再试') return Promise.reject(error) } ) export default request

开发阶段，前后端端口不同，跨域问题几乎必然出现。最常见最省心的办法是让Vite把请求代理到后端端口，在vite.config.js里做如下配置：

server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

这里的前缀必须和后端Controller的统一路径前缀保持一致。我在后端所有接口都加了/api前缀，比如@PostMapping("/api/auth/login")，这样前端请求/api/login会由代理转到后端地址，又不会和页面路由冲突。代理的好处是浏览器看到的请求是同源的，根本没有跨域报错的机会，比后端配CORS更加省心。

4.3 几个典型页面的实现思路

车辆列表页是前端最典型的一个页面，整体结构是筛选栏加卡片列表加分页。筛选栏绑定一个searchForm对象，点击搜索时重新请求第一页数据。车辆卡片用Element Plus的el-card展示封面图、标题、价格、里程、上牌年份信息，每张卡片下方放“查看详情”和“收藏”按钮。数据的获取全部通过上面封装好的request.get('/car/page', { params: searchForm })，后端返回的数据结构是{total, list}，前端塞进el-pagination即可。

车辆发布页和后端的上传接口配合紧密。上传图片我用el-upload组件，action指向后端/api/upload接口，上传成功后把返回的图片路径存到表单的coverImg或images字段里。表单提交时，把el-upload里的fileList转换成字符串再传给后端，后端存入TEXT字段。这里有个常见坑：提交时如果直接提交fileList对象，后端只会收到一堆无用的临时文件名，因为Vue的fileList是组件内部维护的对象数组，不是最终的存储路径。

车辆详情页的逻辑重点是订单按钮的交互。页面加载时先根据路由参数里的id获取车辆详情，点击“立即下订”时确认当前车辆status是否为1。如果后端已经在这种状态下返回“已锁定”或“已售”，前端要正确展示对应按钮的禁用态。这个状态判断，最好在后端做，因为用户完全可能绕过前端直接调接口。

5. 联调、打包与部署：把前端放进SpringBoot生成可运行jar

5.1 两种部署方式：静态资源托管和反向代理

后端开发完成后，本地联调已经通畅，接下来要考虑怎么部署。最省事的一种方式，是把前端构建出的dist目录复制到后端项目的src/main/resources/static下，让SpringBoot同时充当API服务和静态Web服务器。这样最终只需要部署一个jar包，不存在跨域，也不存在两个进程分别维护的问题。

实际操作步骤并不复杂：前端执行npm run build生成dist目录，把里面的index.html和assets、favicon等文件一并复制到后端的resources/static目录下，然后执行mvn clean package打包，最后java -jar运行。启动完成后直接访问localhost:8080，看到的就是前端首页。请求/api路径时，SpringBoot返回接口数据；请求其他路径时，从static里找静态资源。

这种单jar部署非常适合个人项目和小团队，但是有个细节要特别留意：如果前端用了history模式路由，刷新某个子页面比如/home时，后端static目录里只有index.html，没有home.html这样的物理文件，就会404。解决办法是让后端把所有找不到的路径都转发到index.html，交给前端路由接管：

@Controller public class ViewController { @GetMapping(value = {"/", "/home", "/car/**", "/user/**"}) public String index() { return "forward:/index.html"; } }

注意这个转发不能覆盖/api前缀的接口路径，否则会拦截掉正常请求。所以后端接口统一加/api前缀，在这里就显得相当重要。如果不想折腾这个，直接把前端路由改成hash模式，这个问题天然就不存在。

另一种方式是前端独立部署到Nginx，Nginx监听80/443端口，把/api下的请求反向代理到后端的8080端口。Nginx配置核心就一段：

location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; }

try_files保证了history模式下刷新子路径不会404，proxy_pass把API请求转发给后端。这种部署方式更适合前后端需要各自扩展的场景，缺点是服务器上多一个Nginx进程，运维成本稍高一些。我个人觉得，小项目用第一种方式更舒服，端口少、管理简单、问题少。

5.2 初始化数据库与环境检查

部署前数据库初始化是不可跳过的一步。我用一个schema.sql加上几个测试数据，通过Navicat或者命令行执行。执行前要确认数据库版本和字符集，推荐使用utf8mb4字符集，它能完整显示生僻汉字和一些特殊符号，utf8在这点上是不够全的。

字符集检查结果往往在部署后才暴露问题：中文乱码、问号或者出现乱码符号，多数都是连接串没指定characterEncoding，或者数据库字符集不是utf8mb4。我在Spring Boot连接串里已经写了characterEncoding=utf8，实际上这个值在MySQL驱动里会自动映射为utf8mb4，但数据库建库时还是建议显式声明：

CREATE DATABASE IF NOT EXISTS secondhand DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_general_ci;

数据库导入完成后，建议先写个最简单的接口测试连通性，比如查品牌表返回一个JSON数组。如果这一步报错，优先检查账号密码、网络端口和防火墙，而不是急着去跑完整前端页面。

5.3 Maven打包中容易忽略的细节

Maven打包时，前端文件已经在static目录下，正常执行mvn clean package就能打出一个包含前端资源的jar。但如果你的构建顺序是先打包后端、再把前端复制进来，要格外注意复制文件的时机和路径。很多人习惯直接在IDEA里点package，结果打包出来的jar没有页面，就是因为前端dist没有在打包前放到正确位置。

有一种更自动化但稍微复杂的做法，是借助Maven的frontend-maven-plugin在构建后端前自动执行npm install和npm run build。这个插件能把前端构建流程纳入Maven生命周期，以后打包一次就全做完了。但对初学者来说，手动复制dist是最直白的，也能让你理解最终jar里到底有什么。

打包完成后，在命令行运行java -jar target/app-name.jar。遇到jar无法启动，可以先看日志里有没有Invalid bound statement、端口被占用、数据库连不上三类经典问题，这些我都会放在最后的速查表里。检查无误后，浏览器访问http://localhost:8080，整个二手车系统就上线了。

6. 常见问题速查与踩坑记录

6.1 高频报错速查表

我把自己在实际开发过程中遇到的高频问题整理成一张表，方便你遇到对应报错时迅速定位。

这些坑里面，Invalid bound statement和前端刷新404是我见过出现频率最高的。它们其实都不是复杂问题，但错误信息一开始看不懂，往往会卡住很长时间。建议碰到之后，先检查路径和拼写，再检查版本兼容性，往往比漫无目的地搜博客更快。

6.2 我再补充几个隐蔽的坑

第一个隐蔽问题是MySQL驱动版本。如果你是Spring Boot 2.7加MySQL 8.x，项目里默认引入的是com.mysql.cj.jdbc.Driver，而不是老教程里的com.mysql.jdbc.Driver。如果复制了旧配置，启动时会连驱动类都找不到。直接用com.mysql.cj.jdbc.Driver，适配MySQL 5.7和8.x都能稳定运行。

第二个隐蔽问题是MyBatis的多参数方法。Mapper接口如果写的是List selectList(String keyword, Integer brandId);，XML里直接引用#{keyword}和#{brandId}会报参数无法解析的错误。这是因为MyBatis无法直接判断参数名，解决方法是加@Param注解，或者在编译时加上-parameters参数才会被自动识别。建议所有Mapper方法都规范地写@Param，不要偷懒。

第三个和MyBatis缓存相关的问题，我一直放到最后说。默认情况下MyBatis会在同一个SqlSession里开启一级缓存，二级缓存默认关闭。个人项目里不建议开启二级缓存，因为开启后要处理实体序列化，还要应对缓存和数据库不一致的问题。除非你已经深刻理解缓存失效场景，否则老老实实每次查询数据库，对二手车管理系统这个数据量来说完全够快。缓存优化应该是出现性能瓶颈之后再做的事，而不是项目一开始就要去折腾的炫技点。

回到这个系统本身，一套完整跑通的二手车交易系统，难点很少在某个单独技术上，更多是业务链路的闭环：用户发车、别人看到、下订单、状态流转、后台管理。你用第二部分提到的方案把表和状态约定好，再用第三部分的接口设计把每个环节串起来，前端只是把这些能力变成一个可点击可操作的门面。先让链路闭合，再谈优化外观和性能，这个顺序千万别搞反。

最后再分享一个小技巧。我在给车辆列表写排序时，如果搜索条件里加了一个sortBy参数，直接用参数去匹配固定的排序字段白名单，比如只允许createTime、price、mileage这几个值，而绝不直接拼接用户传来的字符串。这样既支持列表排序，又不会留下SQL注入的口子。很多隐藏得很深的安全问题，其实就是在这种看似不起眼的小地方埋下的。把这类细节养成本能，比修完一个Bug更有价值。