做小型企业CRM系统最怕的就是一上来就撸代码做到一半才发现表结构不合理、接口设计混乱前后端联调的时候改来改去。这个项目我前前后后搭过三轮这一版用SpringBootVue3MyBatisMySQL前后端分离的方案算是在小型团队规模和长期维护成本之间找到了比较舒服的平衡点。如果你正准备做类似的客户管理系统或者想拿一套完整的全栈项目练手下面这些从设计到落地的细节应该能帮你省掉不少弯路。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加