企业官网建设流程全解析

Spring Boot 实现的客户关系管理系统，表面上看就是一套标准的增删改查，但真正动手做起来，从客户字段怎么设计、跟进记录怎么关联商机、权限粒度怎么控制，到前端表格怎么处理分页联动，每一层都有不少值得琢磨的地方。这篇文章我从实际的系统落地角度出发，把项目结构、核心表设计、关键后端实现、前端交互还有踩坑记录完整梳理一遍，希望能给正在做同类管理系统的朋友一些能直接抄作业的参考。

1. 客户关系管理系统到底在管什么

1.1 最核心的需求不是“管客户”，而是“把客户变成订单”

客户关系管理系统，英文缩写就是 CRM，听起来好像只要把客户名单录进数据库，做个列表查询就完事了。我一开始也这么想，但真正把一个 CRM 项目跑通后才发现，这套系统最核心的价值在“关系”两个字，不在“客户”两个字。客户只是一个静态的记录，关系才是动态的、会变化的、能产生业务价值的东西。

打个比方，客户表里录入了五百个客户，这只是仓库里放了一堆箱子。真正有用的信息是哪些箱子正在洽谈中、哪个箱子最近跟进了三次、哪个箱子说下周打款却断了联系。这些信息才是销售主管和一线业务员最关心的。所以这套基于 Java 和 Spring Boot 的 CRM 系统，表面上在管客户，本质上是在打通一条从线索到客户再到商机最后到成交的完整链路。

我在设计系统的时候，把业务模块拆成了五块：客户资料管理、联系人管理、跟进记录、商机管理、统计看板。客户资料是主数据，联系人是挂在客户下面的子表，跟进记录是动态行为数据，商机是客户购买意向的量化体现，统计看板则是把所有数据汇总成管理层能直接看懂的图表和数字。这五个模块互相咬合，缺一个，系统就只是通讯录。

1.2 不同角色的需求差异决定了权限设计的走向

做管理系统最容易踩的坑，就是把所有用户当成同一个角色来设计。我的客户管理系统里，当初没有区分角色就盲目开工，结果做着做着就发现不对。销售业务员用系统，希望记的东西越简单越好，页面越少越好，最好三步之内完成一条跟进记录的录入。销售主管用系统，关心的是下属名下哪些客户一个月没动静了，哪些商机处于高风险状态，他要的是筛选和统计能力。系统管理员关心的是数据能不能整体备份、用户能不能快速开户销户、角色权限能不能灵活调整。

所以这个系统的后台设计必须把用户表、角色表、权限表拆开，做成经典的 RBAC 模型。普通业务员登录后只能看到自己的客户数据和跟进记录，销