做二手车销售管理系统这个项目的时候，我第一反应不是急着建工程、写接口，而是先想明白一个问题：这类系统跟普通进销存到底差在哪。二手车行业最核心的资产是车辆信息，但真正决定成交的其实是客户的跟进过程。一辆车从收进来到卖出去，中间要经历入库、定价、拍照上架、客户咨询、预约看车、议价、成交过户，链条特别长，而且每一环都依赖销售人员的线下动作。如果系统只做车辆登记和展示，那跟Excel表格没什么区别，没法解决管理问题。
所以这个系统的关键，不是做出多少页面，而是能不能把业务链条完整串起来：车源信息存下来，客户线索跟着走，销售跟进留痕，成交数据可回溯。用Spring Boot做后端服务，MySQL存业务数据，几乎是这类项目最稳妥的组合。Spring Boot的自动配置和starter机制能快速搭出可运行的工程，MySQL关系型模型天然适合描述车辆、客户、订单之间的关联关系。
这篇文章我会从需求分析、表结构设计、核心接口实现到部署踩坑，完整复盘整个系统的搭建过程。不管你是拿它做毕业设计、课程设计，还是公司内部真要落地一套二手车销售管理工具，里面的设计思路和实现细节都可以直接参考。
1. 需求梳理：二手车销售系统到底要管什么
1.1 业务场景与核心痛点
先还原一下二手车行的日常。店里收了一台车，评估师记录车况、给出收购价，行政人员拍照录入系统，销售顾问开始对外发布车源信息。接下来客户通过网站、门店、朋友介绍等各种渠道来咨询，销售得记下客户意向、定期回访、约看车、谈判价格，最后成交过户，财务收款开票。
这中间最痛的点有三个。第一，车辆信息分散。这台车什么配置、什么车况、收购价多少、挂售价多少、放了多久，如果靠人记或者靠Excel管理，很容易出错，尤其车多了以后，库存情况根本摸不清。第二，客户跟进全凭自觉。销售手头几十个客户，哪个该回访了、哪个有强烈意向、哪个已经跟丢了，没有系统提醒和记录，完全依赖个人习惯，公司层面无法管控。第三，经营数据不透明。老板想知道这个月卖了几台车、毛利是多少、哪款车卖得快，如果靠月底人工汇总，既慢又容易漏。
针对这些痛点，这个系统的功能边界就很清晰了：车辆全生命周期管理、客户线索管理和跟进记录、销售数据统计。再往细了拆分，就是车源登记、车辆上下架管理、客户信息维护、跟进记录写入、预约看车安排、成交订单生成、基础数据报表这几大块。
1.2 功能模块拆解与优先级
我习惯先把功能按优先级分层，优先保证核心闭环跑通，再做辅助功能。
第一优先级是车辆管理和客户管理。车辆管理要支持录入车辆基础信息（品牌、车型、年份、里程、排量、变速箱、颜色、收购价、销售价、车况描述）、上传车辆图片、修改车辆状态（在库、已预约、已售、下架）。客户管理要记录客户姓名、电话、意向车型、意向预算、客户来源（网站咨询、门店到访、老客转介绍），同时给客户打上意向等级标签，方便销售重点跟进。
第二优先级是跟进和预约。跟进记录是销售过程管理的核心，每次电话、微信聊天、到店接待都要留下记录，并且设置下次跟进时间。预约看车要关联客户和车辆，安排具体时间，支持反馈看车结果。
第三优先级是订单和统计。客户成交后生成销售订单，记录最终成交价、合同编号、经手销售。统计报表至少要有：本月销量、本月销售额、库存车辆数、各品牌销售占比、各销售员业绩排名。
至于用户权限，简单一点就分两个角色：管理员和销售员。管理员可以看全部数据、管理车辆上下架、调整价格；销售员只能看自己录入的客户和跟进记录，可以新增车辆信息但不能下架车辆。这个权限模型在课程设计和中小型企业内部都够用了。
2. 技术选型与项目分层设计
2.1 为什么是Spring Boot + MySQL + MyBatis-Plus
技术选型这块不追求新，追求稳。
Spring Boot我用的2.7.18。这是Spring Boot 2.x最后一个稳定版本，坑少、资料多、兼容性好。Spring Boot 3虽然已经出来很久，但对JDK版本有要求（必须17+），很多教学环境和服务器上的JDK还是1.8，没必要给自己挖坑。如果公司环境允许，用3.x也没问题，但2.7.18做这类管理系统绰绰有余。
持久层框架选了MyBatis-Plus。为什么不用原生MyBatis？因为这个项目里有大量单表CRUD操作，用原生MyBatis要写一堆重复的Mapper XML，效率低。MyBatis-Plus提供BaseMapper，内置了insert、selectById、updateById等常用方法，分页插件也成熟，复杂的多条件查询再用自定义SQL解决。两者结合，开发速度提升一大截。
数据库用MySQL 8.0。MySQL 5.7目前已经停止官方维护，新项目没必要再用老版本。8.0在性能、JSON支持、窗口函数等方面都有明显优势，而且安装配置资源多，遇到问题容易搜到答案。数据库连接池用HikariCP，Spring Boot 2.x默认集成，性能好、配置简单，不用额外引入Druid。
前端这块，如果做纯后端管理系统的项目，我建议用Thymeleaf模板引擎加Bootstrap，服务端渲染，开发效率高，不用单独搭前端工程。如果公司有专门的前端资源，那可以拆成前后端分离，Spring Boot只提供RESTful API，前端用Vue或React。本文后面讲的是单体方案，更适合个人开发者或者小团队自己维护。
2.2 项目结构规划与分层职责
项目结构我按经典的分层架构来拆，controller、service、mapper、entity四层，再加config、common、dto几个辅助包。这样的好处是职责清晰，后期维护不迷路。
src/main/java/com/example/carsales/ ├── controller/ # 接口层，接收请求、参数校验、返回结果 │ ├── CarController.java │ ├── CustomerController.java │ ├── FollowUpController.java │ ├── OrderController.java │ └── UserController.java ├── service/ # 业务逻辑层，核心业务判断都在这里 │ ├── CarService.java │ ├── CustomerService.java │ └── ... ├── mapper/ # 数据访问层，MyBatis-Plus的Mapper接口 ├── entity/ # 实体类，对应数据库表结构 ├── dto/ # 请求/响应对象，避免实体类直接暴露 ├── config/ # 配置类（拦截器、跨域、MyBatis-Plus分页插件等） ├── common/ # 通用结果封装、异常处理、工具类 └── CarsalesApplication.java分层的核心原则是：Controller只做参数接收和结果返回，不写业务逻辑；Service承载业务规则；Mapper只做数据读写。比如车辆下架操作，Controller拿到车辆ID后调Service，Service里先查车辆是否存在、当前状态是否允许下架、再执行更新，最后返回统一结果对象。如果有人图省事把业务判断写在Controller里，短期看代码量少，后期一旦加需求就会非常痛苦。
统一返回结果这个细节很多人会忽略。我建议定义一个Result 类，包含code、message、data三个字段，成功返回200，失败返回具体错误码。这样前端或者调用方只需要判断code就能知道请求是否成功，不用每次解析HTTP状态码。异常处理统一用@RestControllerAdvice做全局异常捕获，业务异常、参数校验异常、未知异常分别处理，避免把异常堆栈直接抛给调用方。
3. 数据库设计：7张表撑起整个业务
3.1 核心数据表结构与设计思路
数据库设计是整个系统的地基。我每设计一张表都会想一个问题：这张表要回答什么业务问题？
用户表sys_user，存登录账号和权限信息。密码字段用BCrypt加密存储，不要明文存，这是最基本的底线。角色字段用字符串区分admin和staff，简单直白，不引入复杂的权限框架。
CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, real_name VARCHAR(50), role VARCHAR(20) DEFAULT 'staff', status TINYINT DEFAULT 1, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );车辆表car_info是系统最核心的表，字段多而且关键字段要建索引。品牌、车系、年份、里程、排量、变速箱、颜色、收购价、销售价、车辆状态、上架时间、描述、图片地址。状态字段用TINYINT，0表示在库，1表示已售，2表示下架，用数字比用字符串状态更高效，也方便做条件筛选。
客户表customer存客户基础信息和意向信息。电话字段一定要建索引，因为销售查客户基本都是按电话号码搜。意向等级level字段用1到3表示高、中、低，方便销售按重要程度排序跟进。
跟进记录表follow_up每一条记录关联一个客户和一个销售员，记录跟进内容、下次跟进时间。这个表的数据量会比较大，所以要建联合索引(customer_id, create_time)，查某个客户的跟进历史时性能有保障。
预约看车表appointment关联客户和车辆，记录预约时间、状态（待确认、已到店、已取消、已完成）。
销售订单表sale_order记录成交信息。订单编号order_no要唯一，建议用业务规则生成，不用自增ID。成交价deal_price单独存，因为实际成交价往往低于挂牌价，这部分差价就是议价空间。
车辆调价记录表price_log：每次车辆价格变动都记录旧价、新价、操作人、原因。这个表特别重要，二手车价格波动频繁，如果调价没有记录，后面对账时会说不清楚。
3.2 字段设计中的细节与索引规划
字段类型的选择容易踩坑。价格字段不要用FLOAT或DOUBLE，准确性问题会在金额计算时暴露，必须用DECIMAL(10,2)。里程字段用INT，单位统一为公里。日期时间字段用DATETIME，注意连接参数里要设置serverTimezone=Asia/Shanghai，避免时区偏差。
图片字段存储我建议只保存图片URL地址，不要用BLOB把图片二进制塞进数据库。原因很简单：BLOB字段会让表体积膨胀，查询性能下降，而且应用服务器和数据库之间的网络传输压力会大。图片文件存在本地磁盘或OSS对象存储上，数据库只保存资源路径。
索引规划上，car_info表给brand、status建索引，高频查询是按品牌和状态筛选。sale_order表给sale_date和user_id建索引，月度统计和按销售员排名的查询会用到。customer表给phone建唯一索引。建索引要克制，不要给每个字段都建，MySQL里索引不是越多越好，写操作会被拖慢，而且占磁盘空间。
有一类典型问题：查询慢。排查思路是先EXPLAIN看执行计划，看有没有走索引、扫描了多少行。我记得做过一个统计报表接口，按月份分组统计销量，数据量才几千条就要几百毫秒。EXPLAIN一看发现查询条件里的状态字段没走索引，因为表里建了索引给的是status+TINYINT，但SQL里用了status != 1，导致全表扫描。改法是把不等值条件改写为等值条件，或者直接建覆盖索引。
4. 核心业务逻辑的实现细节
4.1 车辆管理：入库、上下架与价格调整
车辆入库逻辑不算复杂，但有一步容易忽视：自动生成车辆编号。我采用规则"CAR-年月日-四位序号"，比如CAR-20250318-0001。具体实现是用一个DayCounter表或者查询当天已有车辆数加1，然后用String.format补零。这样生成的编号在业务沟通里直观好用，销售报编号就知道是哪天收的车。
上下架操作要写状态流转校验。车辆状态是一个有限状态机：在库→上架→预约中→已售；在库/上架→下架。状态流转必须校验合法性，不能允许已售车辆直接再上架。MyBatis-Plus的updateById可以做更新，但要注意在Service层先查一次当前状态，再判断是否允许流转，不能盲目更新。
价格调整这块，二手车跟新车不一样，价格变动频繁。调价要记录原因，比如"车况整备完成加价2000"或者"库存超60天降价促销"。每次调价写一条price_log记录，同时更新car_info表的当前销售价。如果后面要分析"调价频率是否有助于成交"，这个表就是数据基础。
4.2 销售线索与跟进记录的设计
客户从录入到成交，中间围绕的核心是跟进记录。我一直强调，跟进记录是整个销售过程管理的抓手，这事的价值常被低估。很多团队做管理系统只关心车辆数据录入，忽略了跟进记录的设计，实际上这才是销售管理者最想看的。
跟进记录表设计上，内容字段要允许较长的文本，因为销售可能记录详细对话细节。重要的是next_follow_time这个字段，这是下次跟进时间。系统每天早上的任务列表就是查当天需要跟进的客户，关联条件是next_follow_time在当前日期。这样销售一打开系统就知道今天要联系谁，管理者也能看到哪些客户好久没人跟进了。
客户意向等级调整也是一个有效功能。销售在跟进过程中判断客户意向变化，把等级从低改到高，或者标记为"已成交""已流失"。等级变化也可以记录日志，但这个功能优先级可以放低，第一版可以先不做。
预约看车功能要设置冲突校验。同一台车在同一时间段不能被两个人预约。简单做法是查appointment表里有没有该车辆、预约时间重叠且状态为"待确认"或"已到店"的记录。这个判断放在Service层做事务控制，避免并发问题。
4.3 成交流程与数据归档
成交是整个流程的终点，也是数据价值最高的节点。
成交操作要做的事情：把车辆状态改成已售，生成销售订单，更新客户状态为已成交。这三步要在同一个事务里，只要一步失败，整体回滚。我曾经遇到过因为没加事务控制，车辆状态改了销售订单没生成的情况，月底对账时发现库里少了一辆车，非常狼狈。事务这件事，Service层方法上标注@Transactional，并注意抛出RuntimeException才触发回滚，Exception类型默认不触发。
成交价与挂牌价的设计。挂牌价是车辆上架时填的销售价，成交价是最终实际卖出去的价格，两者往往不一样。议价空间就是这两者之差。统计毛利的时候要用成交价减去收购价（成本价），不能用挂牌价计算。订单表里同时存sale_price和deal_price两个字段，报表统计时按deal_price算，这个细节看起来小，但对报表准确性影响很大。
订单编号用"ORD-日期-序号"生成，跟车辆编号类似。合同编号如果线下有纸质合同，系统里存合同编号字段便于对应。销售员ID存user_id，后面统计业绩按这个字段分组即可。
5. 实操过程：从零搭建到可运行
5.1 环境准备与工程骨架
环境建议：JDK 1.8或11，Maven 3.6+，MySQL 8.0，IDEA。Spring Boot 2.7.18对应Maven依赖从中央仓库拉取即可，需要注意Maven镜像源，国内环境建议配置阿里云镜像，不然依赖下载能卡半小时。
创建工程我用Spring Initializr，Group填com.example，Artifact填car-sales，选择Java 8版本，勾选Spring Web、MyBatis Framework、MySQL Driver、Thymeleaf依赖。Lombok可选，如果团队里有不熟悉注解的新手，可以先不用，手写getter/setter也就多几行代码。MyBatis-Plus需要单独在pom.xml里添加依赖，Initializr里不带这个。
<!-- pom.xml 中核心依赖 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-thymeleaf</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency>5.2 数据库初始化与核心配置
数据库先手动执行建表SQL初始化，不推荐用程序自动建表，生产环境更不能用。项目里加一个schema.sql放在resources目录，方便团队新成员快速初始化环境。
application.yml关键配置项：
spring: datasource: url: jdbc:mysql://localhost:3306/car_sales?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver thymeleaf: cache: false mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0这里几个配置项解释一下。serverTimezone=Asia/Shanghai解决时区问题，不然插入的时间会比实际少8小时。allowPublicKeyRetrieval=true解决MySQL 8.0的SHA256密码认证插件导致的连接失败问题。useSSL=false是本地开发环境跳过SSL验证。log-impl配置是让MyBatis在控制台打印SQL，排错利器，正式环境记得关掉。
5.3 权限控制与登录模块实现
登录模块不引入Spring Security，用拦截器就够了。Spring Security配置繁琐，对这个体量的项目属于过度设计。我实现一个自定义拦截器LoginInterceptor，继承HandlerInterceptor接口，在preHandle里检查session中有没有登录用户。排除登录接口、注册接口和静态资源路径，其余接口一律拦截。
用户登录时，用BCryptPasswordEncoder的matches方法比对密码，比对成功后把用户对象放进session。修改密码功能里新密码也要BCrypt加密再存库。密码加密这一点没有商量的余地，哪怕只在这个系统里跑，也不能明文存。
角色鉴权我做一个简易方案：自定义@RequireRole注解标注在Controller方法上，管理员接口标注@RequireRole("admin")，拦截器里读取注解并对比当前用户角色。比在每个方法里手动判断role更优雅，切面代码更容易维护。
6. 常见问题与排查技巧实录
6.1 数据库连接与环境类问题
运行最常见的当属数据库连不上。控制台报CommunicationsException或者Access denied，先别急着怀疑网络，三步排查：第一步看数据库服务是否启动，Windows下用服务管理器查MySQL服务状态；第二步看连接URL能不能ping通，navicat能连上说明数据库本身没问题；第三步看账号权限，URLL里填的账号是否有权限访问对应库。
MySQL 8.0的Public Key Retrieval问题，报错信息是Public Key Retrieval is not allowed，解决方案就是URL参数加allowPublicKeyRetrieval=true。这个问题是因为MySQL 8.0默认使用caching_sha2_password认证插件，客户端第一次连接时需要获取服务器公钥，默认禁止自动获取。加上这个参数就通了。
中文乱码问题。页面显示问号或者乱码，先检查数据库表字符集是不是utf8mb4，再检查连接URL里有没有characterEncoding=utf8，最后看页面编码有没有meta标签设置charset。三处统一了基本不会乱。强调一点：在建库建表时统一用utf8mb4，utf8mb4是utf8的超集，能存emoji和生僻字，MySQL 8.0默认就是utf8mb4。
6.2 Spring Boot与MyBatis-Plus的坑
MyBatis-Plus的逻辑删除有一个经典坑：配置了logic-delete-field之后，所有查询自动过滤已删除数据，但唯一索引会出问题。假设给手机号字段建了唯一索引，用户删除一条记录后，再次插入同一个手机号的数据会报唯一索引冲突，因为那条"已删除"的记录还在表里占着索引。解决思路：要么用联合唯一索引包含deleted字段，要么删除时不走逻辑删除而是真正DELETE，要么用状态字段区分而非唯一索引。我通常选择联合唯一索引方案。
分页插件一定要在配置类里注册MybatisPlusInterceptor并添加PaginationInnerInterceptor，不注册的话Page查询不会生效，查出来的数据量不受限制。这个很多人第一次用都踩过。另外分页查询统计总条数的SQL，如果涉及多表关联，count语句可能要走一遍大表关联，性能会慢。优化手段是自定义count SQL或者干脆只依赖第一页的数据量，用"加载更多"代替分页条。
LocalDateTime序列化问题。Spring Boot默认用Jackson序列化时间，LocalDateTime类型默认输出格式是一长串数字，不好看也不方便前端处理。在application.yml里配置spring.jackson.date-format=yyyy-MM-dd HH:mm:ss对LocalDateTime是不生效的，需要用@JsonFormat注解标注在实体类时间字段上，或者自定义一个Jackson的LocalDateTime序列化器。这个坑很隐蔽，我一开始也被绕进去了。
6.3 业务逻辑中的典型Bug
事务失效是高频Bug，最常见的两种场景：同类内方法自调用失效和异常被吞掉。同类中方法A调用方法B，B上有@Transactional注解，B的事务不会生效，因为Spring事务基于AOP代理，自调用不走代理对象。解决办法是拆到不同Service类里，或者注入自身代理对象。异常被吞的情况：方法里catch住Exception没有往外抛，事务当然不会回滚，数据就写了一半。
还有一个并发问题容易被忽视：成交操作和另一个人同时操作同一辆车。比如销售A提交订单把车辆状态改成已售，销售B同时也在给这辆车创建订单。解决办法是在sale_order表创建时用SELECT ... FOR UPDATE锁住对应car_info记录，或者给car_info表加version字段做乐观锁。MyBatis-Plus支持@Version注解做乐观锁配置，拦截器加OptimisticLockerInnerInterceptor。二手车行同时抢一台车的情况不多，但为了防止数据错误还是加上更稳妥。
关于返回给第三方的接口设计，出现过因为接口参数校验不完善导致的数据问题。比如新增客户接口没有校验手机号格式，销售录入"12345"这种无效号码，后期打电话发现打不通，客户数据质量非常差。解决办法是使用Spring的@Validated注解和@NotBlank、@Pattern等注解做参数校验，统一处理校验异常返回。
结尾：一些实践经验
做这个系统最大的体会是：技术点本身都不难，难的是把业务流程想清楚再动手写代码。我在做第二版的时候，重构了跟进记录表的设计，加了下次跟进时间字段，就因为回收访数据时发现Excel里压根没法快速筛出"今天该跟谁"。一个字段的差别，对实际管理效率的影响是质变的。
最后分享一个小技巧：开发这类管理系统时，每个核心业务的SQL语句我都会先手动在Navicat里跑通，确认结果没问题之后才写到Mapper里。这样可以避免调试接口时还要同时排查SQL语法错误，把变量控制在单一的维度内。另外，车辆图片的本地存储路径要提前规划好，不要放在项目工程目录下，打包发布时会把图片覆盖掉。单独配置一个file.upload.path属性指向服务器固定目录，线上部署时改配置文件的路径，就可以避免这类问题。
