做小型企业CRM系统，最怕的就是一上来就撸代码，做到一半才发现表结构不合理、接口设计混乱，前后端联调的时候改来改去。这个项目我前前后后搭过三轮，这一版用SpringBoot+Vue3+MyBatis+MySQL前后端分离的方案，算是在小型团队规模和长期维护成本之间找到了比较舒服的平衡点。如果你正准备做类似的客户管理系统，或者想拿一套完整的全栈项目练手，下面这些从设计到落地的细节，应该能帮你省掉不少弯路。
1. 项目概述与整体架构设计
1.1 小型企业CRM系统的真实痛点
给小型企业做CRM，第一件事不是选技术，而是想清楚系统到底要解决什么问题。我接触过的大部分小企业，客户资料基本躺在三四个地方——销售手机里的通讯录、微信聊天记录、Excel表格，运气好点的可能还有个在线文档。跟进记录更是随缘，今天聊了什么、下次什么时候跟、客户目前卡在哪个环节，全凭业务员脑子记。
这种状态下做系统，核心诉求其实很朴素：客户资料集中管理、跟进过程有迹可循、合同数据随时能查。不需要复杂的CRM理论，不需要自动化营销工作流，更不需要AI销售预测。把这些基础功能做到好用、稳定、上手快，远比堆砌一堆花哨功能有价值。
所以这个项目的功能边界我控制在五个模块内：客户信息管理、联系人管理、跟进记录、合同台账、系统用户与登录。每个模块都做到够用且不臃肿，既能让小团队真正用起来，又不至于让开发周期拉得太长。
1.2 前后端分离架构为何是首选
前后端分离早就不算什么新概念了，但在CRM这类管理系统里，它的优势依然很明显。后端只负责业务逻辑和数据，前端专注页面交互和体验，两边通过JSON格式的接口通信，互不干扰。
对于小团队或者个人开发者来说，这个架构最直接的好处是开发和调试效率高。后端接口用Postman或Apifox单独测，前端页面用Vue3的devServer热更新，两边可以并行开发，不用像传统JSP项目那样每次改点东西都要重启整个Tomcat。部署的时候也更灵活，前端打包成静态文件扔到Nginx里，后端打成Jar包独立跑，哪个有问题就单独处理哪个。
当然，前后端分离也有代价，最典型的就是跨域问题和Token鉴权需要额外处理。我在第5章会详细讲这两个坑。总的来说，对一个需要长期迭代的CRM项目，这个架构带来的收益远大于初期那点额外成本。
1.3 技术选型背后的一笔账
这套技术栈不是追新，而是每一环都经过了实际考量。
后端用SpringBoot，版本选的是2.7.x，不是最新的3.x。原因很简单，2.7.x的生态最成熟，网上资料多，遇到问题好排查，而且很多第三方库对SpringBoot 3.x的Jakarta命名空间支持还有兼容性风险。小企业项目追求的是稳定，不是尝鲜。
持久层选MyBatis而不是MyBatis-Plus，一方面是因为项目标题要求的就是MyBatis，另一方面，CRM系统里很多查询都是多条件动态组合，MyBatis的动态SQL在这种场景下非常顺手。相比MyBatis-Plus那种偏CRUD的封装，手写Mapper XML能让我对每一条SQL都心里有数，排查慢查询的时候多一份掌控感。
前端Vue3采用的是Composition API加
