开源CRM系统源码全新发布定制化销售管理系统。这句话看起来像一条标准的软件发布公告但真正跑过业务的人都知道销售管理从来不是一个标准化模块能解决的事。我见过不少销售团队从十来个人的小队伍到上百号人的分公司装了各种商业CRM之后最后都回到了Excel和微信聊天记录。原因很简单每个团队的销售流程、客户字段、审批逻辑、权限边界都不一样商业软件要么改不动要么改一次要排队等版本更新。这套源码的核心思路就是反过来——与其给你一套固定流程不如给你一套可以自己改流程的机制。这套系统是我基于长期服务中小销售团队的经验整理出来的针对性解决的问题有三个客户资源沉淀、跟进过程留痕、成交数据分析。适合三种人看想搭建私有销售管理系统的团队负责人接到定制化CRM项目但不想从零写起的开发者以及想研究业务建模和权限设计的产品经理。下文会从源码结构、核心机制、部署步骤到真实定制案例逐个拆开讲不绕弯子。1. 为什么这套CRM非开源不可私有化与定制化的双重需求1.1 商业软件在“销售管理”场景里为什么总是差一口气先说一个我在某外贸公司遇到的真实诉求。对方的销售团队有三十多人业务员分区域管理客户订单要经过主管审批回款节点和信用证条款挂钩同一个客户可能同时存在多个在谈合同。他们之前用的是一套通用SaaS产品功能看着齐全但一落到实际业务就露馅了。问题出在三个地方。第一字段不够灵活。系统里预设的客户字段只有公司名、联系人、电话、地址这些但外贸业务真正关心的是货代、付款方式、汇率结算币种、目标市场这类信息在通用系统里只能塞进备注。第二销售阶段锁死。默认的“意向客户-报价-成交”三段式对谁都不适用有的行业要走投标有的行业要先寄样有的客户可能要挂账三个月。第三权限边界太粗。通用系统通常只分管理员和普通员工但销售管理需要的是“部门主管能看本部门全部客户、普通销售只能看自己的”这种多层控制。这三点凑在一起就逼着团队回到Excel。不是他们不想用系统是系统没法跟着业务走。这也是我下决心做开源版本的原因销售管理的变量太多了唯一可行的方案是让每个团队都能改自己的字段、阶段和权限。1.2 开源的真正价值不是代码公开而是自定义能力公开很多人对“开源CRM”有个误解觉得把源码放出来就是让你拿去改一改跑起来就算完事。实际上源码公开只是第一步真正有价值的是系统内部的扩展机制。这套系统在设计初期就把“可定制”当作第一优先级而不是后补功能。具体体现在四个层面数据库层面用字段配置表支撑自定义字段业务层面用销售管道配置表支撑阶段调整权限层面用数据范围字段支撑多级可见性接口层面预留了事件钩子方便二次开发。这四个层面加在一起才算是真正把定制化能力交到了使用者手里。另外必须实事求是地说开源不等于零门槛。拿到源码后你仍然需要具备基本的Java后端或前端开发能力至少要能在本地把工程跑起来。系统适合的是有一定技术基础、愿意自己动手调整的团队而不是指望下载即用的非技术用户。这一点请在选型前先对齐预期。2. 源码总览技术栈选择、模块边界与核心业务数据链2.1 工程目录与技术选型这套CRM的技术栈是Spring Boot 2.7.x MyBatis-Plus MySQL 8前端用的是Vue 3 Element Plus。选这套组合的原因很直接Spring Boot生态成熟招人容易MyBatis-Plus写复杂查询方便适合业务字段经常变动的场景MySQL则是绝大多数团队已有的基础设施不需要额外引入重型中间件。整个仓库分成三个工程crm-server后端服务负责接口、权限、业务逻辑和定时任务。crm-admin管理端前端供销售主管、管理员使用包含客户管理、数据看板、系统配置。crm-api给外部系统对接使用的接口工程比如从企业微信或ERP同步客户数据。后端工程内部按模块分包每个业务域独立成包避免多人协作时互相踩脚com.example.crm ├── clue 线索管理 ├── customer 客户管理 ├── business 商机管理 ├── contract 合同管理 ├── receivable 回款管理 ├── system 用户、角色、菜单 └── common 公共工具、统一返回体2.2 销售主线数据模型线索到回款是怎么串起来的很多做CRM的新手容易把表结构设计成单表大而全一个customer表恨不得装下所有字段。这套源码里头业务数据是按销售主线的不同阶段拆开的核心链路是线索 → 客户 → 商机 → 合同 → 回款用五张核心表来承载这条链路表名作用关键关联crm_clue线索未确认的潜在客户跟进后转为客户crm_customer客户完整档案归属销售、归属部门crm_business商机在谈的销售机会关联客户记录当前阶段crm_contract合同成交形成的契约关联客户和商机crm_receivable回款应收与实收记录关联合同这样拆的好处是每个阶段可以独立配置字段和权限不会因为“客户阶段变了”导致数据结构大改。比如某公司只需要管理到客户和合同不需要复杂回款那回款模块可以直接不启用业务无损。2.3 给没接触过CRM源码的读者的快速阅读路线如果你第一次接触这类工程建议按三个层次去读。第一层先看common和system模块理解统一返回体、分页参数和用户权限体系这是全局基础。第二层读业务模块的Mapper和Service接口理解每条业务链路的数据流向。第三层再看前端页面如何用自定义渲染模式展示动态字段这是定制化的关键体现。不要一上来就追着看某一个复杂功能比如合同审批流程。CRM系统真正难的是数据权限和字段扩展机制它们的代码分散在框架层里先把这两个机制读明白再看业务代码就会觉得处处都是通的。3. 定制化销售管理的三个旋钮字段、销售管道与数据权限3.1 自定义字段为什么业务表敢不预埋几十个字段做销售管理系统最常见的一个定制需求就是加字段。有的加“客户来源渠道”有的加“预计成交月份”有的要“是否通过代理商”。如果每个字段都直接改表结构系统迭代几次就会有一堆冗余列升级维护非常难受。这套系统的设计思路是核心字段落在业务表本身拓展字段走动态键值对。具体来说系统里有两张基础配置表。crm_field_config保存字段定义比如字段名称、类型、是否必填、所属业务对象crm_field_value保存具体的字段值通过object_type和object_id关联到某条业务记录。前端页面根据crm_field_config的配置动态渲染表单控件不需要为每个新字段写死代码。这个机制的优点很直接加一个下拉框字段只需要往配置表里插一条记录再在字典表维护选项前后端代码都不用动。缺点是用键值对查询性能会差一些所以系统做了折中常用的筛选字段可以映射到业务表的冗余列上低频字段才走动态值表。3.2 销售管道阶段配置每个团队的漏斗都不一样销售管道Pipeline是最能体现销售管理特点的功能。同一套系统外贸公司的阶段可能是“询盘-寄样-报价-回签-生产-回款”软件服务商可能是“初步沟通-演示-方案-商务谈判-签约-交付”两者天差地别。如果管道阶段写死在代码里系统就废了一半。这套源码把管道阶段做成独立表crm_pipeline_stage包含所属业务对象、阶段名称、排序值、是否初始阶段、是否终态阶段几个字段。管理员在后台配置好阶段顺序后前端商机页面的看板会按顺序渲染成多列拖拽商机卡片切换阶段就是更新阶段字段和排序值。这里有两个细节值得注意。第一个是“终态阶段”设计比如“赢单”和“流失”这种阶段不再允许拖拽回之前的阶段避免销售误操作把已成交客户拉回洽谈中。第二个是“每个阶段可配置必填字段”比如进入报价阶段必须填写报价金额否则无法推进。这两个机制保证了管道不只是视觉上的便利还能约束业务流程。3.3 数据权限谁的客户、谁的合同、谁看全部销售管理系统里权限控制做不好轻则内斗重则客户资源泄露。但权限又不能简单粗暴地只分管理员和普通用户必须支持按数据范围隔离。这套系统的权限模型是“角色 数据范围”两级结构。角色控制菜单和操作按钮比如能否导出客户列表、能否删除合同、能否审批高额折扣。数据范围控制查询的行级可见性支持三个档位仅本人只能看到自己创建或分配给自己的记录。本部门能看到本部门所有人名下的记录。全部系统管理员或销售总监级别的可见范围。实现在代码层面并不复杂核心是在Mapper查询前注入一段数据权限拼接逻辑public PageResultCustomer page(CustomerQuery query, LoginUser user) { // 根据当前用户角色构建数据权限 SQL 片段 String scopeSql buildDataScopeSql(user); query.setDataScopeSql(scopeSql); return customerMapper.selectPage(query); }这里的关键不是SQL拼接本身而是所有涉及客户、商机、合同数据的查询接口都必须经过统一的数据权限拦截不能存在漏网之鱼。这套源码在所有业务Mapper上都加了切面校验防止开发者二次开发时新增的接口绕过权限控制。4. 从源码到跑通环境准备、初始化脚本与首个业务页面4.1 环境准备清单如果你打算把系统跑起来体验一遍先准备好这些基础环境JDK 1.8或17推荐17新特性支持更好。Maven 3.6以上用于构建后端。MySQL 8.0注意字符集要选utf8mb4。Node.js 16以上用于前端构建。一个Redis实例系统用Redis做登录会话和缓存。源码里提供了docker-compose.yml如果本机装了Docker可以直接一键拉起Redis和MySQLversion: 3 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root MYSQL_DATABASE: crm ports: - 3306:3306 redis: image: redis:7-alpine ports: - 6379:63794.2 初始化数据库与演示数据后端工程里自带sql目录里面分三个脚本schema.sql建库建表init_data.sql插入基础字典和权限菜单demo_data.sql插入演示客户和商机数据。初始化命令很简单mysql -u root -p crm sql/schema.sql mysql -u root -p crm sql/init_data.sql mysql -u root -p crm sql/demo_data.sql跑完脚本后系统会有一个默认的管理员账号。登录后第一件事不是去录客户而是先到系统配置里的“字段配置”和“管道配置”页面按自己团队的业务调整字段和阶段。4.3 配置文件中容易遗漏的三个地方本地跑通通常会遇到几个配置问题我直接列出最常见的三个。第一是数据库连接串的时区参数。MySQL 8默认时区可能和本机不一致导致时间字段差8小时连接串里一定要带上spring: datasource: url: jdbc:mysql://localhost:3306/crm?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai第二是Redis密码配置。如果本机Redis没设密码要把redis.password留空否则启动时报认证失败排查半天发现是配置文件里写了默认密码。第三是文件上传路径。客户附件和合同扫描件上传会写到本地磁盘配置文件里的upload.path默认是相对路径部署时建议改成绝对路径否则重启后路径可能错乱。5. 实战定制一例线索自动分配与逾期跟进提醒的完整落地5.1 业务规则拆解讲完了基础机制用一个真实场景串一遍定制开发的完整流程。某销售团队的需求是这样的市场部录入的线索需要自动分配给业务员分配原则有两个线索所属行业优先匹配擅长该行业的销售如果没有匹配项则分配给当前未处理线索最少的销售。另外任何线索超过48小时没有被跟进系统要自动给负责人发送提醒。这个需求看起来不复杂但涉及三个环节分配策略、定时扫描、通知触发。5.2 后端实现分配策略与定时扫描先写分配服务。核心方法是根据线索的行业字段和销售负载情况选择一个归属人Service public class ClueDispatchService { public Long pickOwner(Clue clue) { // 优先按行业匹配销售 ListUser candidates userMapper.findByIndustryAndRole(clue.getIndustry(), SALES); if (candidates.isEmpty()) { candidates userMapper.findByRole(SALES); } // 按未处理线索数量升序排序取最少的一位 candidates.sort(Comparator.comparingInt(u - u.getPendingClueCount())); return candidates.get(0).getId(); } }注意这里没有在Service里直接new一个List再排序而是从Mapper层就查出候选人员再结合未处理线索数做排序避免一次查出全公司几千个用户造成内存压力。接下来是定时扫描任务。系统里用Spring自带的Scheduled注解实现不需要额外引入xxl-job这类分布式调度组件Component public class ClueFollowUpJob { Scheduled(cron 0 0/30 * * * ?) public void scanOverdueClues() { ListClue overdue clueMapper.findOverdue(48); for (Clue clue : overdue) { notifyService.sendRemind(clue.getOwnerId(), clue); } } }这里扫描频率设成每30分钟一次不是每分钟。原因很简单销售跟进提醒不是支付系统不需要秒级实时半小时的延迟完全可接受反而能降低数据库压力。5.3 前端通知与测试路径提醒通知做到前端时要注意“系统内通知”和“企微/钉钉通知”是两条链路。系统内通知通过站内信表存一条记录用户在消息中心能看到外部通知走接口钩子由各团队自己配置。源码默认实现了站内信和邮件通知企微和钉钉的适配器留了接口二次开发时按接口规范实现即可。测试这个功能也有讲究。建议直接用演示数据中的线索记录改行业字段测试分配逻辑再手工把系统时间相关的数据库记录改成48小时之前验证定时任务是否准时触发。不要为了测试真的等48小时那样太浪费时间。6. 二次开发的红线哪些改动能安全落地哪些改动会拖垮升级6.1 直接改表还是加扩展表很多团队拿到源码后第一反应是“我要给业务表加一个字段”。这个动作要分情况讨论。如果只是新增一个常规字段优先用系统自带的自定义字段机制通过后台配置而不是改表。如果确实需要字段参与复杂计算或查询条件才考虑给业务表加冗余列。加了列之后必须同时更新MyBatis的实体类和Mapper文件并在数据库迁移脚本里记录变更否则换环境部署时这张表的结构就对不上。最忌讳的做法是直接修改多张业务表的结构用于存放临时业务数据。比如为了记录某个审批备注在customer表加三个字段。这种操作短期能用长期会把核心业务表搞得臃肿无比还会影响缓存、索引和数据迁移。6.2 用事件钩子扩展业务而不是到处散弹式改代码这套系统内部预留了事件发布机制。客户创建、商机阶段变更、合同审批通过等关键动作都会触发一个领域事件。做二次开发时如果你要给“客户创建后自动发送欢迎邮件”这样的需求正确做法是监听客户创建事件而不是去CustomerServiceImpl的save方法里横插一段逻辑。事件监听的样板代码是这样的Component public class CustomerCreatedListener { EventListener public void onCustomerCreated(CustomerCreatedEvent event) { Customer customer event.getCustomer(); // 发送欢迎邮件或初始化子资源 emailService.sendWelcome(customer.getContactEmail()); } }好处很明显核心业务代码没有被污染问题定位方便后续升级源码时自定义的逻辑独立在监听器里不会和主流程冲突。6.3 分支管理与升级预留源码发布后官方还会继续迭代。团队如果做了深度定制最怕升级时合并冲突。我的建议是维护一个长期分支将定制代码隔离在独立模块包里其中包含自定义事件监听器、自定义Controller和自定义Service尽量避免修改核心模块类。升级时只需要把新版本的代码合并到长期分支再检查几个扩展点表结构变更、接口路径变更、权限配置变更是否影响自定义代码就可以保持兼容。7. 上线前的检查清单性能、接口安全与备份策略7.1 客户列表越用越慢索引和分页是第一道关任何一个CRM系统跑三个月后最大的痛点基本都是客户列表查询变慢原因是客户数据量增长后普通的全表模糊查询开始吃力。上线前必须确认几类查询走了索引按归属人查询客户是在owner_id上建索引。按部门权限查询是在dept_id上加索引。商机列表按阶段筛选在current_stage字段上建索引。排序字段updated_at也要纳入索引设计。同时前端列表一定要用分页不要为了图快一次查一万条。如果确实有导出需求导出的数据走异步任务生成文件而不是由浏览器同步请求拉全量。7.2 接口权限校验不能只靠前端隐藏这是最容易被二次开发忽略又最容易出事的地方。前端菜单隐藏一个按钮并不代表接口不能被直接调用。任何查看、修改、删除客户数据的接口在Controller层之前一定要经过数据权限校验。系统统一在AuthenticationInterceptor里做登录校验在DataScopeInterceptor里做数据范围校验。后者的逻辑是解析当前用户的角色匹配数据范围档位然后把过滤条件拼进查询SQL。如果某个新增的接口没有加DataScope注解系统会默认按“仅本人”处理保证安全兜底。此外导出接口和批量删除接口要额外做操作日志记录。销售管理系统的审计需求很强客户信息一旦被导出或删除是不能悄无声息的。7.3 数据备份与灰度上线最后是上线策略。CRM系统涉及销售数据必须每天做数据库备份。备份方案优先级如下全量备份每天凌晨执行一次mysqldump保留最近7天。binlog增量备份开启MySQL的binlog用于恢复到任意时间点。备份文件异地存放防止机房故障导致备份也一起丢失。在用的团队规模大于50人时建议先在一个销售小组试运行两周确认业务人员反馈的字段、阶段、权限问题处理完毕后再全公司铺开。销售团队对系统的容忍度很低第一次印象不好以后再推动就难了。按照我在这类系统上摸爬滚打的经验源码本身不是最值钱的值钱的是你能基于它快速构造出贴合自己团队的销售管理流程。开源的玩法从来不是下载即终点而是把它当成一个可以反复打磨的地基。如果你准备拿这套源码做二次开发先花两天时间把自定义字段和数据权限这两块机制读透再动手改业务需求能省下后面大量返工时间。这套系统的源码会持续更新但每一次更新我们都会优先保证扩展兼容性尽量让你手上已经做过的定制不因升级而作废。