企业官网建设流程全解析

简介：客户关系管理系统是企业数字化的核心业务场景之一，它通过管客户、管跟进、管结果三个维度，实现销售过程的透明化与可追溯。不同于高并发电商或复杂IM，CRM更考验业务链路的完整性与数据权限的精细化设计。基于SpringBoot构建单体CRM，可快速实现客户管理、公海池、跟进记录、商机合同等核心模块，满足中小企业内部管理与毕业设计、跳槽项目包装等实际需求。同时，借助MyBatis-Plus动态查询与Sa-Token权限控制，能有效平衡开发效率与业务复杂度。从数据库表结构设计、索引优化到原子SQL防并发领取，这套源码沉淀了完整的工程化实践。无论是准备技术面试，还是落地一套可维护的业务系统，掌握该项目的设计思路和部署经验，都能在真实业务中发挥重要价值。 做Java开发这么多年，我一直觉得CRM系统是每个后端程序员绕不开的练手项目，同时也是一个实战价值很高的业务系统。它不像电商那样强调高并发，也不像IM那样复杂，但胜在业务链路完整：客户、联系人、商机、跟进、合同、数据统计，这些模块串起来之后，基本就覆盖了企业中后台系统的常见形态。市面上开源的CRM不少，比如悟空CRM、芋道源码这类，但大多比较重。如果你是准备毕业设计、跳槽项目经验包装，或者公司内部需要一个轻量CRM，用SpringBoot从零搭一个可控性最高的系统，其实是最务实的选择。

这篇就围绕“Java SpringBoot CRM客户关系管理系统源码”这个主题，把我在实际开发这类系统时的设计思路、技术选型、核心功能实现、源码结构和部署经验完整拆一遍。我不会只贴一堆代码跑一个CRUD就完事，而是会把每一步“为什么这么做”讲清楚，包括表结构怎么设计、数据权限怎么做、跟进记录怎么防重复、统计数据怎么预聚合这些容易踩坑的点。适合刚学完SpringBoot想做项目练手的同学，也适合准备从单体往业务系统扩展的初中级开发者参考。

1. 整体设计思路与核心需求拆解

1.1 CRM系统到底在解决什么问题

先想清楚一件事：CRM（Customer Relationship Management，客户关系管理）系统不是简单的“记录客户电话和姓名”的通讯录，它要解决的核心问题是销售过程的透明化和可追溯。公司老板想知道每个销售手里有多少客户、哪些客户快成交了、跟进到什么阶段了；销售自己想知道下一个该跟进谁、上次聊了什么、这个月业绩还差多少。这些需求归纳下来就是三个核心动作：管客户、管跟进、管结果。

从“管客户”出发，系统要有客户信息维护、公海池（客户回收和分配）、客户查重、客户标签；从“管跟进”出发，系统要有跟进记录、跟进计划、下次跟进提醒；从“管结果”出发，系统要有商机阶段管理、合同订单、回款记录和销售数据看板。把这几个模块做扎实，一个CRM的主体功能就立住了，剩下的比如产品管理、工作台提醒、操作日志，都是在这个骨架上的增量。

我见过不少同学拿开源项目改完就当自己的项目，结果面试官一问“公海池回收规则怎么设计的”就卡壳。所以这篇文章里我会把设计逻辑讲透，你就算不照着写代码，把思路吃透了，也是个加分的项目亮点。

1.2 技术选型：为什么是SpringBoot而不是Spring Cloud

技术选型这件事，最怕的就是过度设计。一个面向销售团队使用的CRM系统，用户量撑死几百上千人，根本不需要微服务那一套。选SpringBoot单体架构，理由很实在：

• 开发效率高：Spring Boot的自动配置和Starter机制，把大量模板配置省略掉了，一个spring-boot-starter-web就能起服务，不需要像SSM时代那样写一堆XML。
• 部署运维简单：打成jar包扔到服务器上java -jar就完事，不像微服务要管注册中心、配置中心、网关，运维成本直线下降。
• 事务好控制：下单、分配客户、更新商机阶段这些操作涉及多张表的数据变更，单体架构直接在一个Service方法上加@Transactional就能保证一致性，拆成微服务反而要在分布式事务上折腾半天。
• 团队协作适中：按controller、service、mapper分层，三个人开发一个CRM系统，代码冲突都很少。

持久层框架我选MyBatis-Plus，这个不是情怀，是因为CRM这种业务系统里动态条件查询特别多。客户列表要根据名称、来源、状态、创建时间、负责人多个条件组合筛选，用MyBatis-Plus的LambdaQueryWrapper写起来比手写XML拼SQL要爽太多了。不过复杂的报表统计我还是倾向用XML手写SQL，因为group by加多表联查的SQL，用Wrapper构造出来可读性很差，而且不好调优。

认证授权方案用的是Sa-Token，不是Spring Security。虽然Spring Security功能强大，但它的配置复杂度对这个体量的系统来说有点重了。Sa-Token开箱即用，登录、踢人下线、权限校验注解都有，几百行代码就能集成完。当然这个可以根据个人偏好替换，JWT+拦截器也是经典方案，后面我会讲一下JWT方案的注意事项。

1.3 项目模块规划与包结构设计

拿到项目第一件事，不要急着建Spring Initializr，先规划目录结构。我是按业务模块划分包，而不是按技术层次划分包。原因很简单：如果你先建controller、service、mapper这种顶层包，然后再往里塞各业务模块的类，业务一多就会很乱，比如com.example.crm.controller.CustomerController和com.example.crm.service.CustomerService之间跳来跳去，找代码全靠全局搜索。按业务模块划分以后，一个模块的所有类都在一个包下，开发时只需要在这个包内操作，高内聚低耦合。

我推荐的结构是com.company.crm作为根包，下面再分modules子包，每个业务模块单独成一个包：

com.company.crm ├── common # 通用组件：统一返回体、异常处理、工具类、配置类 ├── framework # 框架配置：Sa-Token配置、MyBatis-Plus配置、CORS配置 ├── modules │ ├── customer # 客户模块 │ │ ├── controller │ │ ├── service │ │ ├── mapper │ │ └── entity │ ├── contact # 联系人模块 │ ├── track # 跟进记录模块 │ ├── business # 商机模块 │ ├── contract # 合同模块 │ └── system # 系统管理模块：用户、角色、菜单、部门 └── AuthApplication.java # 启动类

common和framework的区别在于：common是业务无关的通用类（比如Result<T>返回体、BusinessException），framework是框架层面的配置类。这样分清楚以后，后面接手的同事看目录结构就能明白哪些是基础设施、哪些是业务代码。我踩过的坑就是一开始把配置类全部扔到config包里，后来配置越来越多，找起来极其痛苦。

2. 数据库设计：CRM系统的地基怎么打

2.1 核心表结构一览与设计思路

数据库设计是整个系统最核心的部分，表设计一旦定型，后面的业务逻辑全是围绕它转的。CRM系统的核心表我用这八张来覆盖：

2.2 客户表状态字段的设计细节

客户表是CRM的“心脏”，它的字段设计直接影响后续所有功能。我建议客户表至少包含status和follow_status两个状态字段，但它们的含义完全不同。status是客户生命周期状态，一般包括潜在客户、有效客户、成交客户、流失客户；follow_status是跟进状态，表示“这款客户当前是否正在被跟进”，主要用于“待跟进提醒”功能，比如客户设置了下次跟进时间，到了时间系统要推送给销售。

这两个状态千万别合二为一，否则统计“本月新增了多少潜在客户”和“有多少客户该跟进了”会互相干扰。比如一个成交客户可能仍然需要售后跟进，如果status直接覆盖了follow_status，售后跟进计划就丢了。

还有字段类型的取舍问题。客户级别、来源这类字段，我强烈建议用varchar存储字典编码（比如level字段存A、B、C），不要直接存中文“重要客户”或“普通客户”。原因有两个：一是数据库层面排序不友好（按级别排序时需要自定义排序规则），二是以后字典项改名时要写大量update语句。查询的时候再用@Trans或者字典翻译逻辑转成中文展示。我在实际开发中遇到过直接存“高”“中”“低”的项目，后来产品说要改成“S-A-B-C”等级，光改数据就花了半天，这就是设计时偷懒的代价。

2.3 公海池与客户分配的设计要点

公海池是CRM区别于普通管理系统的标志性功能，通俗讲就是“无主客户资源池”。客户没有负责人，或者因为长期未跟进被系统自动回收，就会掉入公海池，其他销售可以捞取。怎么设计？

客户表里的owner_id字段就是关键。owner_id为null或者为0就代表客户在公海池。分配客户就是更新owner_id；回收客户就是将owner_id置空。这里有个重要的细节：回收操作不能简单置空，要额外记录回收原因和回收时间。我建议加一个crm_customer_recycle_log表，每次回收都写一条日志（客户ID、操作人、回收原因、回收时间、流入公海时间）。这样既能追溯客户历史归属，又能为以后做“回收率统计”提供数据。

公海池回收规则一般是：客户被分配后，超过N天未跟进（根据follow_status和last_track_time判断）就自动流回公海。这个定时任务用Spring的@Scheduled注解实现就行，每天凌晨跑一次。规则参数比如N天，要设计成系统配置项，不要写死在代码里，不然产品上线以后想调规则还得改代码重新发布。

2.4 跟进记录为什么单独建表

很多人会觉得跟进记录就是客户表里的一个备注字段，最多加个时间戳，这种想法在系统初期还能凑合，一旦客户量上来就废了。一个客户可能一个月被跟进十几次，每次跟进的类型（电话、拜访、微信）和内容都不同，如果全部存在一个字段里，数据被覆盖、查询困难、统计无从谈起。跟进记录单独建表，核心价值是：

• 每次跟进在客户详情页有完整的时间线展示，谁在什么时候跟进了什么内容，一目了然。
• 可以统计分析每个销售的跟进频率、跟进方式占比，评估销售执行力。
• 为“上次跟进时间”“下次跟进时间”这类计算字段提供数据基础。

跟进记录表的设计上有一个隐藏难点：客户和联系人之间的关系。一次跟进可能对应一个客户下的某个联系人，所以表里既要有customer_id，又要有contact_id，contact_id允许为空，因为有些跟进场景可能没对接具体联系人。

2.5 索引设计的实际经验

很多新手设计表的时候不加索引，数据量小没问题，等客户量到几万条、跟进记录到几十万条的时候，列表页一个order by排序就可能慢到超时。CRM系统里最常用的查询就是“当前登录用户负责的客户列表”，所以crm_customer表的(owner_id, status)联合索引必须有。其次，跟进记录表经常按客户查询，crm_track_record表的customer_id索引必须有。再就是客户查重功能，会按手机号或客户名称精确查询，单独索引足够，不需要联合索引。

还有一个小技巧，客户名称上尽量用前缀索引，比如KEY idx_customer_name (name(20))，这样能显著减少索引体积。客户名称一般不像电话号码那样必须精准匹配，模糊查询可以交给LIKE 'keyword%'走前缀索引，效率很高，不要一上来就是全文索引，CRM这种数据量级用不上。

3. 后端核心功能实现与踩坑实录

3.1 统一返回体与全局异常处理

写接口第一步先定返回体规范，不然后面每个接口返回结构五花八门，前端对接成本极高。我通常定义一个Result<T>泛型类，包含code（200成功/500失败）、message、data三个字段，所有Controller接口都返回这个结构。

@Data public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("success"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }

与之配套的是全局异常处理器，用@RestControllerAdvice统一拦截业务异常和系统异常。业务异常（比如客户名已存在、客户已被回收）统一定义为BusinessException，在处理器里返回code=500，把业务提示消息返回给前端。系统异常（NullPointerException之类）则记录详细堆栈，返回一个友好提示“系统繁忙，请稍后重试”，避免把敏感堆栈信息暴露给前端。

3.2 登录认证与权限控制的落地细节

登录认证用Sa-Token实现的话，代码结构很清晰：

@PostMapping("/login") public Result<String> login(@RequestBody LoginDTO loginDTO) { // 1. 校验用户名密码 LambdaQueryWrapper<SysUser> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(SysUser::getUsername, loginDTO.getUsername()); SysUser user = sysUserMapper.selectOne(wrapper); if (user == null || !MD5Util.verify(loginDTO.getPassword(), user.getPassword())) { throw new BusinessException("用户名或密码错误"); } // 2. 校验用户状态 if (user.getStatus() != 1) { throw new BusinessException("账号已被禁用，请联系管理员"); } // 3. 登录并返回token StpUtil.login(user.getId()); return Result.success(StpUtil.getTokenValue()); }

密码存储绝对不能明文，MD5加盐也好、BCrypt也好，BCrypt更推荐，虽然计算慢一点但安全性高很多。权限控制上，Sa-Token提供注解@SaCheckPermission("customer:add")，在Controller方法上标注即可。权限码建议按模块:操作的格式命名，比如customer:add、customer:delete、track:add，这样代码里一读权限码就知道是哪个模块的哪个操作。

这里有个最容易忽略的坑：数据权限和功能权限是两码事。功能权限控制的是“能不能点这个按钮”，数据权限控制的是“能看到哪些数据”。销售只能看到自己负责的客户，销售主管能看到本部门所有客户的客户，老板能看到全部客户的客户，这种需求在CRM里必然出现。数据权限不能靠注解硬编码，我是在CustomerService的查询方法里根据当前登录用户的角色动态拼接owner_id条件实现的。具体做法是把查询条件封装到一个CustomerQueryDTO对象，Service里根据角色编码判断，如果是普通销售就强制在查询条件上加上owner_id = 当前用户ID；如果是主管就查出本部门所以用户ID列表，用IN条件；如果是老板就直接查全部。

3.3 大客户列表的多条件动态查询实现

客户列表查询是CRM里最常用的接口，它的实现质量直接影响用户体验。多条件组合查询的核心是动态拼接SQL，这里MyBatis-Plus优势非常明显：

public PageResult<CustomerVO> pageCustomer(CustomerQueryDTO queryDTO) { Page<CrmCustomer> page = new Page<>(queryDTO.getPageNum(), queryDTO.getPageSize()); LambdaQueryWrapper<CrmCustomer> wrapper = new LambdaQueryWrapper<>(); // 动态拼接条件 wrapper.like(StringUtils.hasText(queryDTO.getName()), CrmCustomer::getName, queryDTO.getName()) .eq(StringUtils.hasText(queryDTO.getPhone()), CrmCustomer::getPhone, queryDTO.getPhone()) .eq(queryDTO.getStatus() != null, CrmCustomer::getStatus, queryDTO.getStatus()) .eq(queryDTO.getLevel() != null, CrmCustomer::getLevel, queryDTO.getLevel()) .ge(queryDTO.getCreateStart() != null, CrmCustomer::getCreateTime, queryDTO.getCreateStart()) .le(queryDTO.getCreateEnd() != null, CrmCustomer::getCreateTime, queryDTO.getCreateEnd()); // 数据权限控制 applyDataScope(wrapper); // 排序规则：先按跟进状态倒序（未跟进的排前面），再按下次跟进时间升序 wrapper.orderByAsc(CrmCustomer::getFollowStatus) .orderByAsc(CrmCustomer::getNextTime) .orderByDesc(CrmCustomer::getCreateTime); Page<CrmCustomer> result = customerMapper.selectPage(page, wrapper); // 转换为VO，翻译字典字段 return convertToPageResult(result); }

这个方法里有两个值得注意的点。首先是orderByAsc(CrmCustomer::getFollowStatus)这个排序逻辑，把“待跟进”的客户排在列表最前面，销售每天打开系统第一眼就看到今天该干啥，这个细节比功能本身还重要，产品满意度提升非常明显。其次要警惕的是like查询的性能问题，如果客户名称输入的是一个很短的字符串，比如只输入“张”，%张%会扫全表，但这种场景一般出现在数据量超过十万条之后，前期不用过度优化。

3.4 客户查重与分配的高并发处理误区

客户查重逻辑看着简单，但并发场景下容易出问题。假设两个销售同时导入一批客户，都在检查“手机号13800138000是否已存在”，发现不存在就插入，结果就插入了两条几乎一样的客户记录。解决办法是数据库层面加唯一索引，比如uk_phone (phone)（前提是手机号是唯一业务标识），insert时数据库会报DuplicateKeyException，捕获这个异常转换成友好提示“该手机号客户已存在”。

客户分配时也有类似的并发问题。一个公海池客户，两个销售看到后同时点击“领取”，如果代码逻辑是“先查询owner_id是否为空，再更新owner_id”，就会产生重复分配。必须改成一条原子SQL：

UPDATE crm_customer SET owner_id = #{newOwnerId}, assign_time = NOW() WHERE id = #{customerId} AND (owner_id IS NULL OR owner_id = 0)

这条SQL执行后判断受影响行数，如果为0说明客户已经被别人领走了，提示“手慢了，客户已被领取”。这里不要用select for update或者加分布式锁，动静太大了，一条原子更新就能解决问题。

3.5 跟进提醒与数据看板的实现要点

跟进提醒功能，我用的方案是“查询时计算”，不搞复杂的任务调度推送。销售登录系统后，首页工作台会显示“今日需跟进客户”列表，SQL条件就是owner_id = 当前用户 AND next_time <= NOW() AND follow_status = 1。这个查询命中(owner_id, follow_status, next_time)联合索引的话性能还是可以的，不用实时推送，销售点击刷新就能看到，产品体验完全够用。

数据看板是另一个高频功能，销售漏斗图、业绩排行榜、跟进统计图。这些图表数据如果每次加载都实时统计，数据库压力会很大。我的实际做法是分两块：实时性要求低的核心指标（比如每个月的业绩汇总）用定时任务每天凌晨算好写进统计数据表；实时性要求相对高的动态数据（比如当前登录用户今天新增了几个客户、写了几条跟进）直接用count查询，数据量小无所谓。这个思路在资源有限的单体项目里非常实用，不用上一个OLAP列式存储，就把90%的报表需求覆盖了。

4. 源码工程化实战：从Controller到部署

4.1 前端页面与接口的对接规范

虽然是SpringBoot后端项目名义，但一个完整的CRM系统不可能没有页面。我这里篇幅有限不展开写Vue的全部代码，但必须说清楚前后端对接规范，因为接口设计是否合理直接影响协作效率。

我推荐的前端技术栈是Vue3 + Element Plus + Axios，这是目前国内中小企业后台最主流、上手最快的组合。Axios统一封装会做三件事：携带token请求头、处理响应拦截、统一错误提示。具体来说，每次请求在request拦截器中从localStorage取token，放到Authorization头里，后端Sa-Token的鉴权拦截器会自动校验；response拦截器中判断code字段，如果是401跳转到登录页，如果是500直接ElMessage.error(message)弹出后端传回来的业务提示。

接口路径规范建议采用RESTful风格，比如客户资源：

所有接口前缀加/api，前端代理到后端端口，Nginx部署时再统一配置转发。这样前后端联调时只需要确认一套路径规范，不会出现在前端写/customer/add、后端映射/crm/customer/save这种驴唇不对马嘴的情况。

4.2 核心页面逻辑：客户列表与详情

客户列表页面的功能逻辑很典型：搜索栏（名称、手机号、状态、负责人等条件）、表格区（展示客户名称、手机号、级别、负责人、下次跟进时间等字段）、分页器。列表页的技术难点其实在“操作列按钮的动态显隐”上，要根据当前用户的权限码判断是否显示“编辑”“删除”“分配”按钮，这个通过Vue的v-if配合后端接口返回的权限码数组实现。

客户详情页会稍微复杂一点，它由多个Tab组成：客户基本信息、联系人列表、跟进记录时间线、商机列表、合同列表。这种页面后端要提供一个组装好的CustomerDetailVO，把客户基本信息、下属联系人列表、最近跟进记录一次性返回，避免前端发五个接口慢慢拼。虽然会多传一些冗余数据，但整体加载速度更快，前端代码更简单。

4.3 MyBatis-Plus代码生成器与逆向工程

手写每个模块的Entity、Mapper、Service，既枯燥又容易出错。MyBatis-Plus官方提供了代码生成器，可以连上数据库自动生成这些基础代码。我之前也推荐生成的代码，但用多了以后我发现直接生成出来的代码有个问题：生成的Service接口层是空壳，Service实现类也几乎没业务逻辑，Entity还是数据库表字段的一一映射。这些代码本身没毛病，但它会让项目看起来特别臃肿，每个模块都是五个类（entity、mapper、service、serviceImpl、controller），一个CRM系统十几个模块下来就是六七十个类，很多类从头到尾没写过一行业务代码。

所以我的建议是：生成器只用来生成Entity和Mapper，Service和Controller自己手写。Entity是数据库结构的映射，生成器生成完全没问题；Mapper接口的selectPage、selectOne这些通用方法已经够用。Controller和Service是业务逻辑的载体，必须自己动手写，哪怕是一开始没有业务逻辑，也要在写的过程中把接口命名、参数校验、统一返回体的路数走通，这样后续加业务才有感觉。

4.4 SpringBoot项目配置与多环境处理

实际开发中，一台开发机、一台测试服务器、一台生产服务器，数据库地址、Redis地址、日志级别大概率都不一样。把配置写在application.yml里要不得，因为这意味着每次部署到不同环境前都要改配置文件，改漏了就上线出事故。

正确做法是配置多环境文件：

resources/ ├── application.yml # 公共配置 ├── application-dev.yml # 开发环境 ├── application-test.yml # 测试环境 └── application-prod.yml # 生产环境

application.yml里用spring.profiles.active指定当前使用哪个环境配置。启动时通过--spring.profiles.active=prod参数覆盖。生产环境密码、密钥这类敏感信息不要直接写在application-prod.yml里提交到代码仓库，用环境变量注入的方式更安全。

日志配置我建议分开：application.yml配置上logging.file.name，然后logback-spring.xml里按天滚动，保留30天。CRM这种业务系统出错时排查日志是第一手段，日志级别生产环境用info就行，如果遇到问题再动态调低到debug级别看详细SQL。另外，spring.datasource.druid连接池配置里，maxActive大小要根据业务量设置，我通常给20，连接池太小会出现获取连接超时，太大又浪费数据库连接资源。

4.5 项目部署上线与运维注意事项

部署这块我直接推Linux服务器 + Nginx反向代理 + systemd管理Java进程。SpringBoot项目打出来的jar包有几十MB，上传到服务器后用nohup java -jar跑起来，唯一的坑是进程一重启就丢了管理。systemd写好crm.service文件之后，systemctl start crm、systemctl restart crm、systemctl status crm都能用，进程挂了自动重启，比nohup强太多了。

[Unit] Description=CRM System After=network.target [Service] User=apps ExecStart=/usr/bin/java -Xms512m -Xmx1024m -jar /opt/crm/crm-system.jar SuccessExitStatus=143 Restart=always RestartSec=10 [Install] WantedBy=multi-user.target

JVM参数里的-Xms512m -Xmx1024m要根据服务器内存实际情况调整。我见过很多人在1G内存的小服务器上直接把堆内存开到1G，结果系统卡死，这就是没留足系统本身的内存。另外，生产环境不要忘了加-Dspring.profiles.active=prod，不然还是会读默认的dev配置。

Nginx层面要注意两个点：一是client_max_body_size要设置一下，否则上传图片时超过默认1M会直接报413错误（客户头像、合同附件很容易超过这个值）；二是WebSocket或者长时间请求的proxy_read_timeout要调大，不然页面导出大量数据时容易断掉。部署完成后一定要测试一下上传、导出的功能，不要等业务反馈Bug了才去翻Nginx错误日志。

5. 常见问题排查与避坑经验清单

5.1 数据库相关：连接失败、时区报错、中文字符乱码

这个算是SpringBoot项目最常见的坑了。时区问题最典型，启动的时候一直报连接成功但查询CURRENT_TIMESTAMP时间差8小时，大概率是JDBC连接串没加serverTimezone=Asia/Shanghai。字符集问题表现在插入中文后变成了???，这时候检查三处：MySQL数据库字符集、表的字符集、JDBC连接串是否指定characterEncoding=utf8，三处全部统一成utf8mb4才能彻底解决。utf8mb4是utf8的超集，能存emoji表情和生僻字，无脑选它。

还有一个隐藏较深的坑：MySQL的max_allowed_packet默认值是4M，如果往数据库插入一条特别长的跟进记录（比如粘贴了一段长文本），可能会报Packet too large的错误。修改MySQL配置文件（my.cnf）把max_allowed_packet调到16M或更大并重启数据库服务即可。

5.2 JVM内存溢出与内存崩溃的排查思路

热词里出现过java: outofmemoryerror: insufficient memory，这个在CRM部署到小内存服务器时很容易出现。排查分两步：先看是不是JVM堆内存分配过大，超出了物理内存，启动时会直接报错，把-Xmx调小即可（比如512m的小服务器，给Java进程256m或384m）。再看是不是堆内存实际使用量持续上涨直到OutOfMemoryError，这通常是内存泄漏，比如查询数据量太大、循环里不断创建对象、静态集合没有清理等。

真实运维中我发现最多的情况反而是第一种：服务器的物理内存一共512M，-Xmx1024m显然是错误的，改成-Xmx384m后一直很稳定。这里有个个人体会，内存不够的时候不要只调JVM参数，还要检查有没有不必要的中间件常驻进程占内存，比如一台小服务器上同时跑MySQL、Redis、Nginx和一个Java服务，内存自然会紧张。

5.3 登录失效与权限校验的几个常见症状

登录认证这块的问题通常有三种症状。第一种，登录后调用接口每次都返回401，这往往是前端Axios没有正确携带token，或者后端配置了StpInterface但接口路径排除时遗漏，导致每次请求都走登录校验。第二种，权限注解不生效，@SaCheckPermission标在方法上完全没有拦截效果，检查是不是没有注册全局异常处理器，Sa-Token抛出NotPermissionException后没被处理，前端看到就是500错误或者泛白的提示。第三种，用户改完角色后权限没更新，Sa-Token默认缓存了用户的权限列表，需要调用StpUtil.logout(userId)把会话注销后重新登录。

提示：修改用户角色、禁用用户账号这类操作，别只改数据库字段，要联动调用Sa-Token的StpUtil.logout()让用户重新登录，权限才能即时生效。

5.4 SpringBoot版本兼容性与依赖冲突排查

现在SpringBoot版本更新很快，如果你刚接触这个项目，直接拉最新的大版本，很可能会遇到各种依赖兼容问题。比如SpringBoot 3.x基于Jakarta命名空间，老一些的MyBatis-Plus版本根本跑不起来，因为javax.servlet换成了jakarta.servlet。

我的建议是选择稳定组合：SpringBoot 2.7.x + MyBatis-Plus 3.5.x + Sa-Token 1.3x + MySQL 5.7/8.0。这套组合经过大量项目验证，依赖冲突很少。如果真遇到了依赖版本冲突，排查思路很简单：找到mvn dependency:tree输出里的冲突依赖，用exclusion排除掉不需要的版本，或者显式指定依赖版本让Maven选择正确的传递依赖。不要盲目升级版本，一个稳定的技术栈比最新的功能重要得多。

5.5 常见问题速查表

6. 从源码到二次开发：扩展方向与心得

源码拿到手以后，怎么做到既能交付给业务方用，又能变成自己手里可复用的技术资产，我最后分享三个扩展方向和一点个人体会。

方向一：增加自定义字段能力。不同行业的客户需要的字段差别很大，有人要“客户规模”，有人要“客户来源平台”。常规做法是在客户表预留多个扩展字段，比如ext_field1到ext_field10，再在数据库维护一张字段配置表，让管理员在后台自由配置这些字段的显示名称和类型。这样不用改代码就能适应不同业务团队的个性化需求，是CRM产品化的第一步。

方向二：增加数据报表模块。系统跑一段时间后，老板必然会问“这个月的成交转化率怎么算”“哪个销售的拜访次数最多”。提前设计一张统计数据表，每天凌晨定时按销售员、日期、客户状态变化做预聚合，报表页面直接读统计数据表，性能和实时性体验都会有保障。

方向三：增加移动端适配。销售天天在外面跑客户，不可能随时开电脑。最务实的方案不是开发单独的App，而是把现有的管理端页面做成响应式布局，或者单独做一个移动端H5页面展示“今日待跟进客户”和“快速写跟进记录”两个核心功能。这样投入小、见效快，业务方对系统的满意度会有明显提升。

最后再说一点个人实际的感受。我在开发和维护这类CRM系统的过程中，最大的体会是：客户关系管理系统真正的难点从来不在技术，而在业务理解。技术方案上，SpringBoot + MyBatis-Plus + Sa-Token + MySQL这套组合已经能把CRM系统的日常功能支撑得很好，真正拉开差距的是你对“销售怎么看客户、管理者怎么看业绩”这两个问题的理解深度。多去听销售吐槽几句，多看看他们日常的工作习惯，再回到代码层面去设计字段和状态机，你做出的系统会比其他工程师的版本有灵魂得多。

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