手上这套Java大型CRM客户管理系统源码连带小程序端一起我前后断断续续维护了差不多两年。CRM这东西业务看起来无非是客户、商机、合同、跟进记录可真要把它做成一个能支撑几百人销售团队日常运转的系统牵扯出来的深度和细节远超预期。这也是我想把它整理成一篇完整复盘的原因——市面上讲CRM概念的文章很多讲某一块技术的也不少但能把服务端架构、小程序端实现、权限模型、部署运维串成一条完整链路来讲的确实不多。这篇文章主要围绕这套Java CRM源码展开包含三部分内容一是我自己做的整体设计和核心模块拆解二是小程序CRM端从登录态到列表缓存的实际实现思路三是部署上线后那些最容易被忽视的坑。适合正在做企业级管理系统、准备拿CRM作为Java面试项目经验或者想给自己的业务快速搭建一套客户管理后台的同学参考。如果你只是想要一个能跑起来的demo那直接去拉源码跟着启动文档走就行但如果你想搞清楚每个设计决策背后的原因那这篇文章应该能帮你省不少时间。1. 项目起底为什么做一套“Java 小程序”的CRM1.1 这个源码项目到底解决了什么问题先说说背景。当时是给一家做企业服务的公司搭建内部CRM业务形态是电销加面销混合销售团队分散在全国几个城市。市面上现成的CRM产品不是不能用问题在于两点一是按坐席收费团队两三百号人一年下来是一笔不小的开支二是现有产品的字段、审批流、报表逻辑都是固定的我们想按业务线自定义客户字段、自定义跟进阶段基本上都要走定制开发周期和费用更不可控。所以当时定了自研路线并且明确了几个硬性要求服务端必须用Java技术栈团队现有人员最熟招聘也好招前端要同时覆盖PC管理后台和销售人员手上的微信小程序数据要支持私有化部署。这几个要求直接决定了后续的所有技术选型也决定了这套源码现在的样子——一个Java后端项目加一个微信小程序CRM前端再加上一套可本地跑的部署脚本。这个项目解决了什么问题往小了说它让销售能在手机上随时录入客户、查看跟进计划、提交审批往大了说它把客户数据从销售个人的微信聊天记录和Excel表格里解放出来统一收口到系统里管理层能看到真实的漏斗数据。很多人低估了这一点觉得CRM不就是个客户台账吗。实际用下来你会发现客户归属、公海回收、跟进提醒、合同回款对账这些环节每一块都是业务管理上的硬需求缺一个都会导致销售钻空子或者管理层拍脑袋决策。1.2 技术选型背后的取舍逻辑主技术栈是Spring Boot 2.7 MyBatis-Plus MySQL 8.0 Redis 微信小程序原生前端。看到这里可能有同学会问现在Java后端都流行Spring Cloud微服务了怎么还用单体加模块化拆分原因很朴素这套系统初期预估并发量就是几百号销售同时在线单机MySQL加Redis缓存完全扛得住而微服务带来的分布式事务、服务治理、链路追踪复杂度对一个核心链路高度耦合的CRM系统来说短期是纯成本不是收益。所以我的选择是Maven多模块单体内聚按业务域拆包后续如果某个模块压力大了再单独拆出去做服务。这个思路在源码里的体现就是controller、service、mapper按客户、商机、合同、审批、报表这些业务域划分而不是按技术层堆在一起。这样做的直接好处是新人接手代码时能顺着业务线读下去而不是在几百个类里大海捞针。数据库方面用MySQL 8.0主要是因为窗口函数、JSON字段、公共表表达式这几个能力在开发报表和动态表单时会省不少事。比如客户表里会存一个ext_json字段用来承载不同业务线的自定义字段——这在传统关系型里是个反范式设计但配合MySQL的JSON查询语法实际用下来查询效率和灵活性平衡得很好。小程序端当时没有用uni-app直接写了微信原生小程序。原因是这个项目只需要跑在微信里不考虑跨端发布到支付宝或抖音小程序原生框架的编译体积、调试体验、性能表现都比跨端框架更可控。而且微信小程序的WXML和WXSS有自己的一套生命周期机制跟着官方规范走踩坑的概率最小。后面我会单独展开小程序端的实现细节。2. 服务端核心设计从数据模型到权限体系2.1 客户、线索、商机、合同的数据模型设计CRM系统最核心的实体关系绕不开五张表线索表、客户表、联系人表、商机表、合同表。这套源码里的命名分别是t_lead、t_customer、t_contact、t_opportunity、t_contract。这五张表之间的流转关系是业务上的主线代码里也严格按这个来线索通过“转客户”动作进入客户表客户下可以挂多个联系人和多个商机商机在赢单后生成合同合同关联回款计划。这里有个容易设计错的地方——很多CRM会把客户和线索混在一张表里用status字段区分。我在实际开发中一开始也这么设计过后来发现业务上有一个痛点线索阶段的信息来源渠道、首次接触时间、初始跟进人和客户阶段的信息行业、规模、地址重叠度不高而且线索转客户后这些字段大多数要清空重填混在一张表里会导致数据污染。分开两张表虽然多了一次转换逻辑但字段职责清晰统计口径也准。客户表和联系人表是一对多关系这个不用多说。值得展开的是商机表和合同表。商机表的核心字段amount代表预计成交金额stage代表销售阶段从初步沟通到方案报价到商务谈判到赢单这俩字段直接支撑了销售漏斗报表。合同表则是整个系统里唯一做金额对账的实体字段设计包含合同总额、已回款金额、待回款金额每次回款操作都会去更新合同表并写入一条回款流水。表之间没有用数据库外键约束。这是大部分互联网项目都会做的选择原因是外键在高并发写入时有锁竞争问题而且分库分表后外键根本没法用。数据完整性靠service层的事务来保证比如线索转客户这个方法上加了Transactional先插入客户主表再更新线索状态中间任何一步抛异常都会整体回滚。2.2 RBAC权限模型与数据权限隔离权限设计是CRM系统里最容易被低估的部分。很多初级项目只做了菜单权限也就是“谁能看到哪个菜单”但CRM真正难的是数据权限——“谁能看到哪些客户数据”。这套源码把权限拆成了两层基于RBAC的功能权限和基于组织架构的数据权限。功能权限用的是经典的RBAC模型五张表用户表、角色表、菜单表、用户角色关联表、角色菜单关联表。登录后会把当前用户的角色和菜单权限缓存到Redis每次请求在拦截器里校验。菜单权限控制的是接口级别的访问实现上用的是自定义注解RequiresPermission注解里写权限标识比如RequiresPermission(customer:add)拦截器通过AOP扫描注解并比对当前用户权限集合。数据权限隔离才是核心。这里的规则是销售只能看自己的客户销售主管能看自己团队所有人的客户总经理能看全公司客户。实现上不是简单地在SQL后面拼一个where user_id #{currentUserId}而是引入数据权限范围的概念。范围分为五种仅本人、本部门、本部门及下属部门、全部、自定义通过客户池规则。在做权限过滤时根据当前用户算出允许访问的部门ID集合和用户ID集合然后以多值IN条件拼入查询SQL。但这样实现有一个隐患所有业务表的查询都要带数据权限条件。如果每个Mapper方法里手工拼条件漏一处就是一个越权漏洞。我的做法是用MyBatis-Plus的拦截器统一处理——自定义一个DataScopeInterceptor解析SQL语法树在检测到表名符合需要数据权限控制的表时自动注入条件片段。这样业务代码里就完全不用关心权限拼SQL这件事新加的查询天然带权限隔离。2.3 接口统一响应与全局异常处理接口层有两个约定贯穿全员写码规范统一返回结构R对象统一异常处理。R对象的字段是code、msg、data成功code为200业务异常code为400或500未登录为401无权限为403。前端不管PC端还是小程序端都按这几个code做统一拦截比如401跳登录页403弹无权限提示。全局异常处理用的是RestControllerAdvice。这里要特别说一下不是所有异常都返回500我在异常体系里定义了几个自定义异常BizException业务规则冲突比如客户已被别人认领、ParamException参数校验失败、AuthException登录状态失效。每种异常映射到对应的HTTP状态码和code码前端拿到后能展示精确的提示信息而不是一把抓地弹“系统错误”。还有一个细节是参数校验。实体入参全部用了javax.validation的注解比如NotBlank、Email、DecimalMinController里加Validated。以前我写项目时觉得校验放前端就够了后来发现小程序端和PC端校验逻辑不一致会导致脏数据现在干脆服务端全量校验前端校验只做体验优化。这样接口被第三方调用时也能防住非法参数。3. 小程序CRM端移动场景下的关键实现3.1 CRM配小程序端的意义和处理取舍很多人好奇为什么已经有了PC管理后台还要单独做一个小程序端。真实业务场景是这样销售大部分时间在外跑客户坐在电脑前录入系统的时间很有限。如果只能用PC销售人员的第一反应就是拖着不录等月底集中补录既不准又耗费时间。小程序端解决的是“随时随地快速记录”的问题一个新增客户的表单可以在电梯里两分钟填完跟进记录可以在拜访结束刚上车时语音转文字提交。但小程序端不是PC端的简单瘦身它有几套自己的设计逻辑。第一是端上交互简化PC上的复杂筛选器和多标签页到小程序里都收敛成“搜索 分类Tab 附近客户”模式。第二是网络容错销售在客户办公室和地下车库的网络环境差别很大所以小程序端所有列表页都做了数据缓存页面加载优先展示缓存再异步请求最新数据。第三是拍照上传现场拍照是销售记录客户实际情况的高频操作图片上传接口专门做了压缩处理避免一次提交一个两三兆的原图拖垮上传速度。这套源码的小程序端目录结构是标准的原生微信小程序pages下按业务模块分目录login、customer、opportunity、contract、approval、mine。全局状态用的微信官方app.js配合globalData没有额外引入第三方状态管理库。原因是小程序项目的页面间通信主要靠URL传参和事件通道业务复杂度还没到必须上Redux类库的程度引入反而增加理解成本。3.2 小程序登录态与会话保持的完整链路登录是这个项目里小程序端最值得讲清楚的一部分。现在的流程不是我最初设计的第一版第一版小程序登录踩过一个大坑直接拿微信code去后端换openid然后把openid当登录凭证存到session里。这样的问题是session过期后用户要重新授权而且业务上我们还需要手机号与工号绑定不能只靠微信身份。现在的登录流程分成三步。第一步是小程序侧调用wx.login拿到临时code第二步是后端拿着code调用微信的jscode2session接口换取openid和session_key第三步是拿openid去查数据库里的用户绑定关系如果查不到就返回一个特殊的“未绑定”状态引导用户走手机号验证绑定流程。绑定完成后后端签发我们自己的token返回给小程序后续所有请求都带这个token。token的设计上用了双token机制accessToken有效期2小时refreshToken有效期7天。小程序端在请求拦截器里判断accessToken是否临近过期如果快过期就先用refreshToken换新的accessToken再重放原请求。这样实现的好处是用户不需要频繁重新登录坏处是刷新逻辑如果写不好容易造成请求风暴。我自己踩过的坑是并发请求同时带着过期token到达后端每个请求都触发一次refresh导致refreshToken被重复使用直接失效。解决办法是前端做了一次刷新锁在第一个刷新请求发出后后续并发的过期请求先排队等待等刷新完成后再统一重放。3.3 列表页缓存、分页与图片上传的细节小程序列表页请求后端接口时后端返回的格式是分页对象records、total、current、size。小程序端在onShow时先读取本地缓存渲染列表缓存key为模块名加当前筛选条件然后请求第一页接口返回后用最新数据覆盖缓存。这里要说一个很多人会忽略的问题缓存的键怎么设计。如果缓存键不带筛选条件那用户选了状态筛选后看到的是旧的全量数据体验很割裂。所以我这边缓存的key是把筛选参数序列化之后拼接成字符串这样不同筛选条件下各自有独立缓存。图片上传这块开发时发现微信小程序的wx.uploadFile在处理多张图片时不能用循环一张张传——不是不能而是体验和性能都很差。我们这边的做法是前端先把图片压缩wx.compressImage将单张压缩到300KB以内然后并行上传后端接收后写入OSS对象存储返回URL列表最后再把URL数组作为表单字段和表单其他内容一起提交。这里有一个并发数控制问题小程序端并发上传超过十个会触发微信的限制所以我们把上传任务切成两批每批五张。这也是为什么源码里上传模块会看到类似chunkUpload的封装实际上做的是一次并发控制。4. 关键业务场景与代码实现拆解4.1 客户认领、公海回收与防撞单客户资源的分配是整个CRM业务里规则最敏感的地方。销售私自录入客户后系统要防止两个销售撞单还要防止销售把客户烂在手里不跟进。这套系统里默认的规则是客户可以通过手动新增或从公海领取进入销售名下客户进入名下后有一个“保护期”保护期内其他销售不能抢保护期内在系统里没有产生跟进记录到期自动释放回公海。这个逻辑在数据层的核心实现是crm_customer表里的owner_id、claim_time、last_follow_time、release_time四个字段。自动回收是每五分钟跑一次的任务扫描保护期到期且没有新增跟进记录的客户批量把owner_id置空同时记录一条客户流转日志。这里有一个容易出的并发问题两个销售同时点击“领取公海客户”在事务隔离级别为可重复读时可能都读到该客户未被领取然后都执行更新。解决方式是在公海领取方法里用SELECT ... FOR UPDATE锁住该客户记录行让先到的请求持有锁后到的请求等锁释放后再判断owner_id是否已经变更。防撞单还有一层逻辑是客户查重。销售新增客户时系统会按客户名称加手机号做模糊匹配查询如果有相似客户会弹出提醒让销售确认是新增还是认领。这里没有用复杂的中文分词或相似度算法原因是初期数据量还没大到需要上ESMySQL的LIKE查询加上名称归一化去除空格、全半角转换已经能拦截大部分重复录入。如果后面客户量过百万这个模块再升级为Elasticsearch也来得及。4.2 跟进记录与销售漏斗统计跟进记录是CRM里数据量增长最快的一张表。一个销售一天跟进十个客户每个客户写一条记录一年就是两千多条两百个销售一年就能产生四十万条数据。所以t_follow_record表在设计时只保留核心字段customer_id、content、next_follow_time、creator、create_time。跟进的详细沟通内容存在content字段里类型是text不参与高频查询的条件匹配。销售漏斗的统计口径是按商机表里的stage字段分组统计每个阶段的商机数量和金额总量再从最后赢单阶段往前推转化率。报表模块的实现没有用复杂的OLAP工具直接用SQL按时间维度和人员维度聚合。以前我尝试做实时统计后来发现漏斗报表不需要秒级精确每天凌晨跑批一次汇总到独立统计表就够用了报表读取的是统计表查询速度能控制在百毫秒级。这是很多CRM项目容易陷入的误区——报表模块非要跟业务库实时联查结果业务高峰期把数据库查挂了。跟进提醒的实现是靠Redis的过期监听和定时任务双轨并行。具体来说每创建一条跟进记录时如果设置了下次跟进时间就会往Redis里塞一个带过期时间的key但Redis过期事件在集群模式下并不可靠所以同时还会有一个每分钟跑一次的定时任务扫描t_follow_record表里next_follow_time在接下来一小时内的记录统一推送给对应销售到小程序的消息中心。双轨的好处是即使Redis挂了定时扫表依然能兜住提醒功能。4.3 合同回款与Word/Excel导出合同模块和回款模块是财务和销售共同使用的模块。合同创建后可以关联多个回款计划每个计划有回款金额和计划回款日期。实际回款时操作回款单回款单审核通过后自动更新合同表的已回款金额。这里涉及一个数据一致性要点更新合同已回款金额时不能直接读合同当前值再写新值这样并发时容易丢更新。我在实现里用的是原子更新SQLUPDATE t_contract SET received_amount received_amount #{payAmount} WHERE id #{contractId}这样即使在并发回款时数据库的行锁加上原子操作也能保证金额不丢失。回款流水表每次操作都写入一条undo_log用于财务审计和冲正。导出功能这里有不少同学问过Java POI能不能生成Word里的图表。答案是能但很折腾。POI生成的是xwpf文档可以插入图片和简单表格但像柱状图、饼图这种原生Word图表对象POI支持得并不好需要自己用XWPFChart类去操作底层XML工作量非常大。我们项目里的做法是图表类导出全部用后端拼接HTML然后用工具渲染成图片插入Word或者直接导出PDF。纯Excel导出用EasyExcel比POI原生API封装度更高内存占用也友好很多。5. 源码工程结构与实践部署要点5.1 Maven多模块结构怎么组织这套Java CRM源码的工程结构是一个父POM加四个子模块。很多人接手Maven多模块项目的第一反应是懵这里我把目录结构直接列出来大家对照着看会清晰很多crm-parent ├── crm-common // 通用工具类、常量、自定义异常、统一返回结构 ├── crm-system // 系统管理模块用户、角色、菜单、部门、数据字典 ├── crm-business // 核心业务模块客户、线索、商机、合同、跟进、报表 └── crm-admin // 启动模块Application入口、配置文件、日志配置这个划分的核心逻辑是按“稳定度”分层。crm-common是最基础的工具层其他模块都依赖它crm-system属于平台层和具体业务无关crm-business才是天天变动的业务代码。在Maven依赖上crm-admin依赖crm-system和crm-business而crm-business也依赖crm-system这样平台模块可以被未来新增的业务模块复用。最忌讳的做法是写一个万能util包什么模块都往里塞时间一长依赖关系就乱成一锅粥。代码层面每个模块内部再按controller、service、mapper、entity、dto分层。这里推荐的写法是controller层只做参数接收和结果返回service层承载业务逻辑mapper层只写SQL。很多新手容易把业务逻辑写进Controller里一个接口上千行后续根本没法维护。这套源码里controller层代码量普遍不到50行业务规则全部收敛在serviceImpl里。5.2 本地环境搭建与启动顺序如果你想把这套源码拉下来在本地跑起来需要准备的依赖是JDK 1.8以上、Maven 3.6、MySQL 8.0、Redis 6.x、微信开发者工具。启动顺序有讲究先启动基础环境再启动应用。第一步是初始化数据库。源码的sql目录下有两个脚本crm_base.sql是建库建表脚本crm_init_data.sql是初始化数据脚本包括管理员账号、角色、菜单、数据字典。直接用Navicat或命令行执行即可。这里要注意MySQL的字符集必须设为utf8mb4否则小程序端传来的emoji和生僻字会报错。初始化完成后检查数据库连接配置在crm-admin模块的application.yml里修改数据库用户名密码和Redis地址。第二步是启动Redis。如果机器上没装Redis直接用Docker起一个最省事docker run -d --name redis -p 6379:6379 redis:6.2第三步是启动后端服务在crm-admin目录下执行mvn spring-boot:run日志里看到Started CrmApplication就算启动成功。接口文档用的是Swagger启动后访问/swagger-ui.html就能看到所有接口定义。小程序端的启动也不复杂。用微信开发者工具导入小程序目录修改utils/request.js里的baseUrl为后端服务地址。注意真机调试时不能填localhost要填电脑在局域网内的IP并且后端服务要允许跨域或做同源配置。我最初调试时忽略了这一点手机一直报网络错误排查到IP问题换了就好了。5.3 部署到服务器的Nginx与容器化实践生产环境部署时建议用Docker Compose编排把MySQL、Redis、后端应用、Nginx统一管理。后端打成jar包后构建镜像时要特别注意时区和内存参数。实际项目中我踩过一个典型的坑容器默认时区是UTC导致系统里所有时间字段比北京时间早八个小时用户反馈创建时间不对。解决方式是在Dockerfile里加上ENV TZAsia/Shanghai RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime echo $TZ /etc/timezoneJVM内存参数同样要显式设置。Spring Boot应用在容器里如果不设置最大堆内存JVM会按宿主机内存的1/4来分配容易出现容器内存Limit设了2G但应用实际用了4G导致被OOM Kill的情况。建议部署时明确加上java -Xms512m -Xmx1024m -jar crm-admin.jarNginx这边的核心配置是动静分离和反向代理。健康检查接口可以探测/healthNginx通过这个路径检测后端实例是否存活。如果后端挂掉了Nginx要能快速摘除节点配合多个实例部署时这步尤为重要。还有一个小细节上传文件大小要调整client_max_body_size否则图片一多就报413。6. 常见问题与排查实录6.1 数据库连接池被打满这个问题的典型现象是系统用了几个小时后业务接口开始陆续超时排查日志发现HikariPool报connection is not available。这类问题的根源通常不在连接池配置本身而是代码里出现慢SQL或者事务未及时释放。我遇到过一次印象最深的情况客户列表接口的SQL里left join了五张表其中一张表的关联字段没有索引导致查询耗时两三秒。高并发时每个请求占用一个连接两三秒连接池100个连接很快就全部被占用。解决办法有两步一是给关联字段补索引把查询降到了50毫秒以内二是把连接池的maximum-pool-size从100调回50避免单个实例连接数过多给MySQL造成压力。排查慢SQL的手段建议直接开启MySQL的慢查询日志slow_query_log ON long_query_time 1然后定期分析慢SQL日志把所有查询超过一秒的语句拉出来优化。这是成本最低的数据库性能优化手段比盲目加服务器配置有效得多。6.2 小程序登录态莫名其妙失效小程序端的用户经常反馈用着用着就跳登录页而且重登后又一段时间正常一天出现好几次。这个问题的排查过程比较曲折最后定位到两个层面。第一层是后端Redis的key过期策略。token的存储key如果只设置了2小时有效期用户在使用过程中token到期自然就会被踢下线。这个现象本身正常但体验差。解决办法就是我前面提到的双token机制accessToken过期后自动刷新同时刷新token的Redis有效期采用滑动续期——用户每次操作都会把refreshToken的过期时间往后推7天常用用户就不会被踢。第二层是服务器时间不一致。当时发现双token机制上线后仍然偶发失效排查发现集群里两台机器的系统时间相差了将近一分钟导致签发token时间判断出现偏差。加上NTP时间同步后问题彻底消失。这个小概率问题提醒我分布式环境下所有节点的时钟同步是基础中的基础。6.3 并发情况下客户归属错乱公海客户领取和客户分配并发时出现过归属错乱的情况表现为两个销售都认为自己成功领取了同一个客户。原因是我早期实现领取逻辑时是先查询再更新中间有差值窗口。前面提到了用SELECT FOR UPDATE解决但这里还有一个细节值得补充数据库行锁在InnoDB下必须是索引命中的锁才能生效如果锁的是全表扫描的查询条件最终锁的可能是间隙或全表性能反而更差。所以客户表owner_id字段一定要建索引让锁落在行上。还有一个场景是管理员批量分配客户。批量操作不能用for循环逐条查询加更新那样既慢又容易超时。我的实现是写了一个批量SQLUPDATE t_customer SET owner_id #{newOwnerId}, assign_time NOW() WHERE id IN foreach collectioncustomerIds itemid open( separator, close) #{id} /foreach同时校验该批客户不属于其他已分配状态。批量更新语句在事务里执行要么全部成功要么全部回滚避免半截子分配。6.4 免费CRM与私有部署的定位差异有不少人问我市面上免费CRM那么多为什么还要自己开发一套。这个问题背后其实是一个容易被忽略的分界线免费CRM和私有部署系统的区别不在软件本身而在数据归属和定制边界。免费CRM的数据存放在服务商机房数据的备份策略、恢复机制、导出权限都由服务商控制而私有化部署的CRM数据库在你自己的服务器上数据的所有权、安全性、合规性完全自己掌控。如果你只是几个销售用免费CRM完全够如果客户数据是你们公司的核心资产或者业务流程特殊需要深度定制那就需要私有化部署方案。这套源码的价值就在于它给了一个可复用的Java后端加小程序前端的完整基底你要做的业务定制是在这个基底上做增量开发而不是从零开始设计数据库和权限体系。还有一个常见的误解是“CRM源码拿来就能用”。实际上源码只是起点部署环境适配、初始数据清洗、员工账号导入、操作培训这些落地工作占比相当大。我在这套系统的第二个月角色已经从开发变成了半个实施顾问天天在解答销售“为什么我这边看不到那个客户”的问题——大部分都是数据权限范围没理解透。7. 源码改造与扩展方向如果你准备把这套源码作为毕业设计、公司项目或者面试项目经验我建议在跑通基础功能后尝试在下面几个方向做一次技术改造。第一个方向是把客户查重模块从MySQL的LIKE查询升级为Elasticsearch全文检索这个改造能讲清楚倒排索引、分词器和搜索评分面试时是非常亮眼的点。第二个方向是给跟进记录增加附件上传和语音转文字功能这涉及对象存储、前端录音组件和第三方语音识别API对接业务故事完整且技术面广。第三个方向是报表模块的异构化扩展把日报、周报、漏斗图从SQL统计升级为定时ETL到ClickHouse再配合前端图表库做可视化看板。这个改造可以引出OLAP与OLTP分离的设计理念。第四个方向是工作流引擎的引入目前系统的审批流是硬编码的可以扩展成简单的动态审批流配置用状态机模式管理审批节点流转这个点能体现你对系统扩展性的思考。改动时建议从小处入手先替换一个独立模块而不是全盘重构。比如先把回款模块的回款计划从表结构层面改成可配置项跑通后再逐步增加字段自定义功能。因为CRM这种系统业务链路太长全盘重构的失败率很高真不如一个模块一个模块地演进。我在实际维护这套系统的两年里最大的体会是源码和架构都不是一次到位的业务方和销售的使用反馈会不断推翻你自以为完美的设计。比如销售漏斗的统计维度按产品线还是按区域公海保护期设三天还是五天客户查重的匹配阈值到底多严格才不误伤——这些看起来不起眼的参数背后全是真实业务场景的磨合。所以如果你也在做类似的系统一定要预留足够的配置化能力把业务规则从代码里抽出来放到数据字典和系统参数表里这才是企业级CRM系统的灵魂。
