Spring Boot CRM客户关系管理系统：源码剖析与部署实践

简介：这是一套面向Java初学者与企业级开发入门者的SpringBoot实战项目源码，聚焦客户关系管理（CRM）核心业务场景，涵盖客户信息维护、跟进记录、统计分析等典型功能模块，助力开发者快速掌握企业级Web应用的分层架构设计与前后端集成开发流程。资源包共188个文件，包含84个Java后端逻辑类、35个jQuery+Bootstrap前端交互脚本、23个FreeMarker模板页面、13个MyBatis映射配置XML及9个CSS样式文件，辅以SQL建表语句与SpringBoot配置文件，完整覆盖前后端代码、数据库结构与界面资源，压缩包仅2.21MB，轻量易部署。已有3300人学习下载，配套MySQL 5.7建库脚本与详细环境要求（JDK1.8+Maven3+IDEA/Eclipse），开箱即用；目录结构规范，模块划分清晰，含AdminLTE后台管理风格与Font Awesome图标支持，便于二次开发与UI定制。 本身做Java后端开发多年，Spring Boot项目也经手了不少，但像CRM这种"看着简单、做起来全是坑"的系统，确实值得单独写一篇。这个标题是"Java SpringBoot CRM客户关系管理系统源码"，光看热搜词就知道——悟空CRM、芋道源码、springboot面试题、linux部署这些词高频出现，说明很多人在找一套能真正跑起来、能看懂、能二次开发的CRM项目。这篇文章我就从"拿到一套Spring Boot CRM源码之后，怎么从代码里扒出真正有价值的东西"这个角度来写，把客户管理系统的核心模块、数据模型、权限设计、部署踩坑一次讲透。

先说一下这篇文章适合谁：正准备做毕设或求职项目的Java学习者，工作中需要快速上手CRM类项目的后端开发，以及想搞懂"客户管理系统到底在管什么"的产品/测试同学。如果你想要的只是一键启动的Demo，那随便找个开源项目clone下来就行；但如果你想知道这套系统背后的设计逻辑、每一张表为什么这么建、权限为什么这么设计，那这篇文章就是给你写的。

1. 为什么CRM项目成了Spring Boot实战的首选

CRM（Customer Relationship Management，客户关系管理系统）在企业级应用里出镜率极高，几乎每家做B端业务的公司都有一套。而在开源社区和面试项目里，Spring Boot版CRM也常年霸榜。这不是没有原因的——我最早接触CRM是在一家做企业SaaS的公司，当时老的PHP系统实在撑不住并发，需要整体迁移到Java技术栈，技术负责人挑选了八个候选项目做技术验证，统一结论是：CRM系统的业务复杂度恰到好处，既不像进销存那样枯燥，又不会像电商那样被高并发和大流量绑架。

用一个比较直白的方式来理解CRM能覆盖的技术深度。一个完整的Spring Boot CRM系统，至少要包含以下内容：

• 客户管理（客户档案、联系人、批量导入导出）
• 线索管理（线索分配、跟进记录、转客户）
• 商机管理（销售漏斗、阶段推进、赢单率分析）
• 合同订单（合同审批、回款计划、收款记录）
• 工作台（待办事项、日程、数据看板）
• 系统管理（用户、角色、权限、操作日志）

这些模块覆盖了企业级应用最常见的通用能力：数据CRUD、复杂查询、状态机流转、审批流、报表统计、权限隔离、导入导出、消息通知。把这些东西吃透，你去看任何一个其他类型的业务系统，比如OA、工单系统、资产管理系统，会发现老底子都是一样的。

Spring Boot在这里解决的核心问题，是把一堆繁琐的配置从"地狱模式"降到了"新手友好"级别。回想一下Spring时代，谁没被applicationContext.xml、spring-mvc.xml、数据源配置、事务配置这些东西折磨过？Spring Boot的自动配置机制（AutoConfiguration）把绝大多数常规配置包装成了默认行为，你在application.yml里只需要写几行核心参数就能启动一个Web应用。

但这里有一个我需要特别提醒的点：很多初学者拿到Spring Boot CRM源码，第一步就是启动，启动跑通了就觉得完事大吉。这其实是最大的误区。代码能运行只是最表层的东西，真正值得花时间的是理解项目结构、业务表关系、权限数据模型、异常处理这些"看不见"的部分。后面我会逐一展开讲。

2. 客户关系管理系统的核心业务架构与模块拆解

我们先说清楚一件顶顶重要的事：CRM系统的业务核心到底是什么？很多人以为CRM就是"一个存客户信息的表格系统"，这是完全错误的认知。真实的CRM核心是一条完整的业务闭环：市场活动带来线索，线索经过清洗和分配变成有效商机，商机进入销售漏斗，通过阶段推进转为合同，合同履约后产生回款，回款数据最终沉淀为企业的经营指标。这整条链路里的每一个节点，都是CRM的业务模块。

2.1 基础数据模块：客户、联系人、线索之间的关系

客户（Customer）、联系人（Contact）、线索（Lead）三者的关系，是整个CRM系统设计的第一个关键点，也是很多二开项目改得最乱的表结构。不少新手会有疑问：客户和联系人为什么不放在一张表里？

简单来说，客户是公司维度的对象，联系人是个体维度的对象，两者是多对一的关系。真实企业场景里，你对接的是一家公司，但这家公司可能有多个关联人——采购经理、商务总监、技术负责人，他们各自的角色、话语权、接触偏好都不同。如果把客户和联系人合并成一张表，每次新增联系人就要复制一遍客户信息，客户信息变更时又得去同步所有联系人，数据冗余和一致性问题立刻显现。

线索的定位又不一样。线索是最原始的潜在客户信息，可能来自展会扫码、官网留资、市场活动、老客户转介绍，信息往往不完整（可能只有一个名字加一个手机号）。线索的触点是"事件"而非"主体"，所以运营上讲究先清洗、后分发、再转化。设计上一般用单独的lead表存储，通过状态字段区分"未分配、跟进中、已转化、已作废"，一旦线索被验证有效并完成转化，系统会以它会为源数据创建客户和联系人的正式档案记录。

我这里给出一套在源码里经常见到的表结构设计参考，大家对照自己手里的项目看看是不是这个模式：

2.2 业务流转模块：从线索到回款的完整闭环

商机管理是整个CRM里最有业务"深度"的模块，也是面试时最容易被追问细节的地方。商机表的stage_id字段关联了一个商机阶段字典（例如：初步接洽、需求确认、方案报价、商务谈判、赢单/输单），每次商机阶段发生变化，系统都会记录一条跟进历史。销售漏斗报表的本质，就是按阶段分组统计商机数量和金额的聚合查询。

合同模块则要处理审批流和回款计划的关联关系。一封合同可能对应多期回款节点，所以设计上会有合同主表加回款计划子表；每次实际到账后生成回款记录，再反向更新合同的已回款金额。这里有开发者在二开时容易犯的错误——直接在合同表上用一个total_amount字段累计所有回款，再把流程做完之后重新审视，发现很多边缘情况根本没被覆盖。正确做法是回款金额由回款计划子表聚合得出，合同表只存合同总额和签约日期，尽量做到不需要经常被动更新。

跟进记录（follow_up）是另一个容易被忽略但数据量最大的表。所有客户、线索、商机的沟通痕迹都沉淀到这里，支持录入文字、设置下次跟进时间。这块在表设计上要特别注意：用target_type和target_id两个字段来做多态关联，不要给每种业务单独建一张跟进表，否则日后的统计查询会非常痛苦。

2.3 附带模块：工作台与报表的价值

工作台和统计报表虽然是辅助功能，但它们直接决定用户愿不愿意用这套系统。销售每天早上打开系统看到的第一眼，应该是"我今天要跟进的客户有哪些""哪些商机进入停滞预警""我这个月的回款目标完成了多少"，而不是一张冷冰冰的客户列表。这些数据看板的后端实现并不复杂，核心就是按条件筛选加分组统计，做成几个独立的接口返回聚合数据。

报表模块的经典指标包括：销售漏斗转化率（各阶段的商机数量和金额）、客户新增趋势（按日/周/月聚合）、回款计划完成率（实际回款/计划回款）、团队业绩排行榜（按销售人员分组汇总合同金额）。这些指标本质上就是几张聚合查询SQL的事，但性能问题在数据量大时会暴露出来，后续我会提到优化思路。

3. 数据模型设计的关键细节：字段、类型、索引与数据隔离

我看了很多CRM源码，包括一些商业项目的开源版本，发现大家在业务功能上基本都能做到七七八八，差距主要体现在数据模型设计上。数据模型就是CRM这栋楼的地基，地基歪了后面无论怎么装修都别扭。下面几个细节是我反复拿来说的。

3.1 金额与时间的字段类型选择

先说不容易出错但影响很大的点：金额字段必须用decimal，不允许用float或double。原因很简单，二进制浮点数在十进制小数运算时存在精度误差，0.1 + 0.2 可能等于 0.30000000000000004。我见过一个踩坑的案例：合同金额用double存储，回款累计多次后对账差出几分钱，客户财务盯了一个下午，最后发现是浮点精度导致的分摊尾差。解决方法是金额字段统一decimal(15,2)，Java侧使用BigDecimal进行所有运算。

时间字段在Java 8之后统一使用LocalDateTime，对应数据库的datetime类型。这里容易踩的坑有两个：一是很多老项目还在用java.util.Date，和LocalDateTime混用，序列化格式不统一，前端解析会出现各种时区偏移的诡异问题；二是当需要记录"某天的数据"而不仅仅是"某个时间点"时，比如回款计划只需要精确到日，很多人还是用了datetime，导致跨天查询时依赖between边界判断，稍稍粗心就会漏数据。正确做法是按精度需求区分字段类型：需要精确到时分秒的操作时间用datetime，只需要年月日的用date，并在Java实体类中对应LocalDateTime和LocalDate。

3.2 多租户与数据权限：客户数据到底该存哪张表

CRM系统的数据隔离是设计时最需要提前定调的问题。SaaS版CRM一般有租户（tenant）的概念，一套代码为多个企业客户服务，所以核心业务表都会带一个tenant_id字段，所有查询强制拼接该条件；而企业内部部署的单租户CRM不关心多租户，但同样需要处理"谁可以看哪些客户"的问题。

这就引出了拥有者（owner_user_id）和可见范围（数据权限）这两个概念。简单场景下，客户表会有一个owner_user_id字段，数据权限规则是"销售只能看自己名下的客户"。但如果一个企业想让销售总监看到整个团队的客户，或者让市场部看到公海池里的所有线索，纯粹的owner过滤就不够用了。业界通用做法是引入用户-部门-角色的组织模型，在做数据查询时动态拼接SQL条件，把用户的部门层级关系转换为in子查询。这一块我放到后面的权限章节详细讲。

3.3 索引设计的常见问题与优化

CRM系统的核心查询模式相对固定：按客户名/联系人手机号模糊搜索、按状态字段筛选列表、按拥有者查看我的客户、按创建时间做报表聚合。针对这些pattern，索引设计不需要过度设计，但几个关键位置必须覆盖：

• 客户表owner_user_id + status的组合索引，用于"我的客户"列表查询
• 客户表customer_name前缀索引（或配合全文索引）用于快速模糊检索
• 跟进记录表target_type + target_id + create_time的组合索引用于业务关联查询
• 商机表stage_id + owner_user_id用于销售漏斗统计

一个容易被忽视的坑是在大数据量下的模糊查询：前台输入客户名称，SQL写成like '%客户名%'，核心索引完全失效，全表扫描。这种情况在数据量几千条时不会有什么感觉，等数据到了几十万条，接口直接变卡，响应时长就会明显恶化。应对思路要么用Elasticsearch做搜索（小项目不推荐，单体阶段过度设计），要么对查询场景做妥协，改成前缀匹配like '客户名%'利用索引，或者引用全文索引能力。在数据量还没大到需要引入搜索引擎之前，前缀匹配是性价比最高的方案。

3.4 逻辑删除与唯一索引的业务冲突

几乎每个后端项目都会做逻辑删除（delete_flag字段标记数据已删除，不真删数据），但这和唯一索引天然冲突。举个例子：客户表保障业务上不允许重复创建同名客户，于是加了唯一索引(customer_name)，客户A被逻辑删除后，客户名还在表里，新建一个同名客户就会触发违反唯一约束，系统直接报错。

处理方式业内常见的做法有好几种，我按使用频率排一下：

• 唯一约束改为(customer_name, delete_flag)组合：当delete_flag只有0和1两种值时，同一个客户名只能被逻辑删除一次；想要支持多次创建同名客户，可以把delete_flag改成记录删除时间戳（删除前为NULL，删除后记录删除时间），这样组合唯一就能保留多条历史删除记录。
• 用状态字段代替删除标记：客户表增加valid_status（0作废/1启用），作废的客户不算删除，只是禁止继续跟进。这更贴近CRM业务的真实语义。
• 通过业务校验替代数据库唯一索引：在Service层先查一下有没有同名有效客户，有则给出明确提示，而不是靠数据库约束去挡住。

我个人的实践经验是，对CRM客户这类业务，推荐第2种，即用"作废状态"代替"删除操作"，既满足需求又不牺牲数据的可追溯性，还躲开了唯一索引的坑。

4. 权限控制的实现路径：从登录态到按钮级操作

权限是CRM系统和普通CRUD系统的最大区别所在，也是代码审查时我会最先看的部分。企业老板最怕的事就是销售离职时把客户信息导走，或者普通员工能看到与自己完全无关的大客户报价，所以权限控制如果没做好，系统的业务价值直接归零。

4.1 认证与会话管理

Spring Boot + Spring Security是目前最主流的选择。登录接口通过用户名密码换取一个Token（JWT格式），后续请求在Header里带上Authorization: Bearer ，由Spring Security过滤器链完成Token解析、用户身份加载、角色权限校验。JWT的好处是无状态，适合前后端分离架构；坏处是Token一旦签发，在过期之前无法主动作废。所以一般要配合Redis做Token黑名单或用户状态缓存，实现"管理员把用户禁用后，用户立即失效"的效果。

很多开源CRM项目选的是若依（RuoYi）框架作为底座，走的也是Spring Security + JWT + Redis这套方案，底子比较靠谱。如果是面试项目，能把这个链路从头到尾讲清楚，在面试官那里会加不少分。

4.2 数据权限：不是"有没有权限看"而是"能看多少"

数据权限是CRM系统里最微妙的设计。菜单权限解决的是"这个用户能不能进入客户管理页面"，数据权限解决的是"进入客户管理页面后，能看到哪些客户记录"。菜单权限是粗粒度的，角色+菜单关联就能搞定；数据权限是细粒度的，需要按用户、部门、数据归属做过滤，这也是权限系统最考验设计功力的地方。

常见的数据权限规则有以下几种，按可见范围从小到大排列：

• 仅本人数据：用户只能看owner是自己或者自己参与协作的数据
• 本部门数据：用户能看到本部门所有成员的数据
• 本部门及子部门数据：结合部门树的递归查询
• 全部数据：通常授予管理层、数据管理员

实现方式是在MyBatis的SQL动态拼接阶段，根据当前登录用户的角色，自动追加数据范围过滤条件。MyBatis-Plus的DataPermissionInterceptor可以自定义数据权限处理器，在执行的SQL中自动注入部门ID或用户ID条件，业务代码一行都不用改。这是我在生产环境里用过最顺手的方案，把横切关注点从业务代码中完全剥离。

4.3 按钮级权限的实现思路

按钮级权限指的是：同一个客户管理页面，销售人员看到"新增跟进""编辑商机"按钮，但只有销售经理才能看到"删除客户""批量分配"按钮。实现方案一般是菜单表里的perms字段记录唯一的权限标识（如crm:customer:delete），前端在渲染按钮时判断当前用户的权限标签集合里是否包含对应标识，不包含就直接不渲染。

后端同样需要在接口层面二次校验，不能让按钮隐藏成为唯一的防线。Spring Security的@PreAuthorize注解可以作用在Controller方法上，写法清晰：

@PreAuthorize("hasAuthority('crm:customer:remove')") @DeleteMapping("/{id}") public R<Void> remove(@PathVariable Long id) { customerService.removeCustomer(id); return R.ok(); }

这样即使用户拿到了接口地址，没有对应权限也会被403拦截。这段代码逻辑虽然简单，但它揭示了一个重要原则：权限校验必须放在后端，前端隐藏按钮只是体验层面的事情，绝不能当成安全手段。

5. 从源码到部署：本地启动与服务器上线的实操笔记

拿到一套Spring Boot CRM源码，第一关就是怎么把它跑起来。这一步看着简单，实际上我在好几个开源项目的issue区里看到新手被卡住最多的地方，就是环境配置和初始数据。我把自己实操时走过的路和踩过的坑整理成清单，照着做基本能省下半天时间。

5.1 本地启动的第一步：版本对齐

Spring Boot 3.x和Spring Boot 2.x在配置上有一个重大差异，这是很多源码跑不起来的根源：Spring Boot 3基于Jakarta EE 9，javax.包名全部换成了jakarta.；如果你的JDK版本低于17，Spring Boot 3直接拒绝启动。源码如果用了Java 8的语法和依赖（比如javax.persistence、javax.validation），就必须用Spring Boot 2.7.x版本；想用JDK 17强大的新特性，那就得选Spring Boot 3.x的代码分支。

判断方法很简单：打开源码里的pom.xml（Maven项目）或build.gradle（Gradle项目），看parent标签里的版本号，同时查一下当前JDK版本。推荐本地装JDK 8和JDK 17各一个，用环境变量快速切换，这是做Java开发的基本功。

另一个高频启动失败原因是Maven依赖下载慢或仓库找不到某些内网包。如果是国内网络环境，建议在maven的settings.xml里配置阿里云镜像源；如果是源码里有私有仓库依赖，优先看README里有没有说明需要的额外配置，没有的话去issue区搜一下，大概率已经有前人踩过并提供方法。

5.2 初始化数据：建库、导入SQL、改配置

CRM系统几乎都需要初始化数据——至少要有一批默认菜单、默认角色、默认管理员账号，否则启动后登录进去一片空白甚至登录不了。源码包里一般会附带sql脚本，常见命名方式：xx_crm.sql（完整建表+初始数据）、xx_crm_data.sql（只含初始数据）、xx_crm_schema.sql（只含表结构）。建议顺序是先建数据库，再按schema到data的顺序导入，避免外键依赖报错。

导入完成后再改application.yml或application-druid.yml里的数据源配置：

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

这个段落有四个极易出错的新手坑：数据库名和SQL脚本里默认库名不一致导致表建到别的库；MySQL 8和MySQL 5.7的驱动类名不同，一个带cj一个不带；serverTimezone不设置会出现时区差8小时的诡异问题；mysql驱动版本与数据库版本不匹配会报连接错误或字符集错误。

5.3 部署到Linux服务器的常规路径

本地跑通后部署到服务器，通常有下面几条路：

• jar包直接部署：mvn clean package打出jar，nohup java -jar xxxx.jar &运行，适合小规模内网使用
• systemd服务托管：把启动命令写进systemd服务单元文件，配合开机自启和服务异常自动拉起重启
• Docker容器化：写好Dockerfile，构建镜像后用docker-compose编排应用和MySQL
• Nginx反向代理：前端静态资源由Nginx托管，/api路径反向代理到后端服务端口

热词里单独出现"springboot linux"和"linux+api源码"，说明不少人在这一步卡过。我单独提一下systemd方案，因为很多新手第一次部署时发现nohup启动后ssh断开进程就没了，或者进程虽然活着但重启机器后又找不到了。使用systemd的正确示范是创建/etc/systemd/system/crm.service文件，内容大致如下：

[Unit] Description=CRM Server After=network.target mysql.service [Service] User=root WorkingDirectory=/opt/crm ExecStart=/usr/bin/java -Xms512m -Xmx1024m -jar /opt/crm/crm-server.jar SuccessExitStatus=143 Restart=always RestartSec=10 [Install] WantedBy=multi-user.target

然后执行systemctl daemon-reload、systemctl enable crm、systemctl start crm三步，就能实现开机自启和崩溃自动重启。JVM参数里的Xms/Xmx按服务器内存调整，像客户管理系统这种业务，512M到1G起步足够，压力大时再往上调。

5.4 部署上线后必做的三件事

部署完成不是终点，一套CRM能稳定运行，上线后的环境加固同样不可少。我总结为三点：

• MySQL数据定期备份：至少每天一次全量备份，用cron调用mysqldump命令把备份文件传到独立目录或对象存储
• 日志清理策略：Spring Boot默认的日志文件会无限增长，日志框架配置logback.xml里加上按天滚动和保留天数策略
• 监控告警：简单方案是监控进程是否存活和关键接口的HTTP状态码，直接让运维平台定时curl探测，有问题就报警

6. 读懂CRM源码的正确打开顺序与二次开发建议

源码拿到手，不要一上来就通读全文。我见过太多人翻开项目就是一顿点，看了三天还在Controller层打转，最后脑袋一团浆糊。花费的时间并不少，却没沉淀出系统性的知识结构。正确的方式应该按下面这个顺序来。

6.1 第一遍：跑通闭环，建立整体认知

第一步只做一件事：把项目启动，然后跟着业务主流程走一遍，把链路中的代码全部找出来。比如"创建一个客户"这个操作，从前端页面按钮触发请求，到Controller接收参数，到Service处理业务逻辑，到Mapper操作数据库，到数据落库后返回前端，把这整条调用链上的类、方法、注解都过一遍。

这一遍不需要看懂每一行代码，只需要建立"请求是怎么从入口走到数据库再返回的"这个闭环认识。这一步会建立对项目结构的基础认知，你会知道配置类在哪个包、通用返回对象长什么样、异常是怎么被统一捕获的。

6.2 第二遍：死磕核心模块

第二遍聚焦三个模块：登录认证流程（Security过滤器链的触发顺序）、客户列表查询（数据权限过滤条件是在哪里注入的）、商机阶段流转（状态变更的时候做了哪些额外动作，比如写入跟进历史）。

其中客户列表查询是最值得吃透的。MyBatis-Plus的LambdaQueryWrapper或者XML里的动态SQL，写法上可能风格不一，但逻辑抽象出来基本一致。我看过几十个CRM源码后，发现万变不离其宗：先确定当前用户的数据权限范围，再和客户表的owner/部门条件做交集，最后叠加搜索条件和分页。

6.3 第三遍：带着问题二次开发

源码看得差不多了，就该自己动手改。我推荐的练习方向是：

• 给客户模块增加"批量导入"功能，学习EasyExcel的使用和异步任务处理
• 给商机模块增加"阶段停滞提醒"，学习Spring Boot的定时任务（@Scheduled）和简单的消息通知
• 给报表模块增加"客户来源分析图"，学习分组查询和日期格式化统计

做这些练习时，刻意不去看原项目里有没有类似实现，自己先写一遍，写完再对照源码看别人的思路，这样学习效率远高于纯阅读。遇到"这个功能我加的为什么和原来的风格不一致"这类问题，正是在打磨自己的代码风格和对框架的理解深度。

6.4 二开过程中容易踩的雷

二次开发最大的风险是破坏原有架构的隐性约定。我列几个典型的例子：

• 新写的Service方法直接用了BaseMapper的insert，跳过了原有Service公共类里的填充逻辑（比如create_time自动赋值、唯一性校验），导致新增数据不完整
• 改动了数据库表的某个字段，但没有同步更新实体类、XML的ResultMap、前端Vue页面三处，导致接口出参缺字段或前端渲染报错
• 在事务方法里调用了同类里的另一个方法，忘了Spring事务是在代理对象层面生效的，this.xxx()调用不会经过代理，导致事务失效
• 把业务校验逻辑散落到Controller层，而不是放在Service层，破坏了原项目的分层约束，后续维护时定位问题会非常难

这些问题在面试和实际工作中都是高频警戒点，也是代码评审时最容易被资深开发挑出来的毛病。

7. 关于这套项目的选型借鉴与横向对比

最后再聊聊"选型"这件事。市场上的Spring Boot CRM开源项目并不少，光是热词里就出现了悟空CRM和芋道源码。对刚接触这个领域的人来说，不同的脚手架风格和设计取舍，确实容易让人挑花眼。

7.1 常见开源CRM的结构风格

• 若依系列（RuoYi）衍生的CRM：统一使用Spring Boot + MyBatis-Plus + Vue，管理后台成熟度高、代码风格统一、权限体系完善，适合学习经典框架组合，业界应用面也广
• 悟空CRM：模块划分细致、前端交互丰富，更贴近商业产品形态，部署时前端后端分离明显，适合想研究复杂业务场景的开发者
• 芋道源码的CRM模块：基于完善的基础框架做扩展，内置大量企业级功能，代码工程化程度较高，适合想在企业级标准下做二次开发的场景

选择哪个作为学习对象，取决于你的目标。如果目标是短时间打通Spring Boot全流程，选结构简单的；如果目标是走进大厂常见的Spring Cloud微服务架构，选相对完整的企业级框架。

7.2 单体还是微服务：一个务实的判断

CRM系统到底需不需要上微服务？我的看法是：绝大多数企业内部CRM都没必要。微服务解决的是大团队并行开发和独立部署的问题，引入的分布式事务、链路追踪、服务治理等复杂度，对一个日活几十上百人、数据量千万级以内的系统来说性价比不高。单体架构（Monolith）在一个合理的模块拆分下，完全能支撑CRM的业务体量；真要到了性能瓶颈，优先考虑按功能模块做垂直拆分成几个独立应用，而不是一步到位冲微服务。

这一点在面试里也很容易成为加分项：当面试官问"你们项目为什么不用微服务"时，能说出"出于业务体量和运维成本的考量"这种务实回答的候选人，通常比一上来就说"微服务是未来所以要用"的人更受青睐。

这套项目的价值，不在于它用了多新的技术，而在于它把一个企业级系统的完整样貌展示给了开发者。客户数据结构怎么设计、权限边界怎么切分、业务状态怎么流转、部署上线要考虑哪些问题，这些经验都是实打实可以迁移到其他项目里去的。我在写这篇分享时也重新梳理了一遍自己做过的那套CRM的核心设计，得到的结论是：Spring Boot本身只是工具层面的东西，真正让系统有价值的，是对业务的理解和对细节的把握。这个认知，可能比任何一份源码都更值得带走。

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