1. 项目缘起DeskcommCRM 到底是做什么的先说结论DeskcommCRM 不是那种满大街的通用 CRM 壳子而是一套把“客户管理”和“即时通信”揉在一起的轻量级客户管理平台。它的核心思路很简单传统 CRM 管的是“字段”和“流程”但现代销售和客服每天大量时间其实泡在聊天窗口里会话记录、客户意向、跟进结果全散落在各个 IM 工具里导致数据断层。DeskcommCRM 想解决的就是这个断层。我最初做这个项目是因为手上同时管着三个渠道的客户咨询——官网留言、个人微信、以及一个后来被客户频繁使用的在线客服组件。每天来回切换窗口手动把聊天内容摘录到 Excel 或后台备注漏掉的信息特别多。更痛苦的是客户第二次来问同一个问题时我根本记不清上次聊到哪了。DeskcommCRM 的雏形就是这么来的一个能把所有渠道会话统一收拢、自动关联到对应客户档案、并且保留完整跟进历史的系统。这个项目适合谁看如果你是独立开发者、小团队负责人或者公司里负责选型 CRM 但又觉得大厂产品太重的业务管理者这篇复盘对你会有参考价值。我会把整个系统的定位、数据设计、核心模块实现、部署过程中遇到的坑以及我自己的取舍逻辑都掰开讲。不是教科书式的架构分析而是踩过坑之后重新梳理出来的真实路径。2. 整体设计与关键选择2.1 为什么没有直接用开源 CRM 改一开始我想过直接拿现成方案比如热词里提到的 RuoYi 生态或者一些开源 CRM 项目。RuoYi 系产品做后台管理确实效率高权限、字典、代码生成这些底层能力都非常成熟拿来当底座开发业务能省两三周时间。但我在试用之后放弃了这个路线主要卡在两个点上。第一RuoYi 这类框架的重心是“管理后台”它的交互习惯、组件风格都偏向内部系统。而我希望 DeskcommCRM 的客户会话界面像一个现代聊天工具左侧客户列表、中间消息流、右侧客户详情这种三栏布局如果硬塞进通用后台模板里改造成本不亚于重写一套前端。第二消息通道这块是核心RuoYi 没有内置我需要自己接 WebSocket、实现会话归档和离线消息存储。与其背着框架的约束去补轮子不如从零开始把前后端分离做得彻底一点该从底层控制的地方一点不含糊。如果你只是想快速给内部搞一个记录客户电话和拜访计划的小工具那直接用开源框架没问题。但如果你像我一样要把“聊天记录”作为客户资产的核心载体我还是建议自建。这就像一个工具箱里已经有活动扳手但你要拧的是内六角螺丝最终还是得再买一把专用扳手。2.2 模块划分把系统和插件分开DeskcommCRM 的前端采用 Vue 3 Vite后端用 Spring Boot数据库默认 MySQL缓存用 Redis。整体划分为四个相对独立的模块deskcomm-core基础能力包括用户、角色、权限、部门、字典、操作日志。这一层是所有业务模块的地基。deskcomm-customer客户档案管理负责客户创建、去重、分群、标签、自定义字段。deskcomm-ticket工单管理负责跟进记录、任务派发、状态流转、SLA 提醒。deskcomm-channel消息通道模块管理 WebSocket 会话、聊天记录归档、离线消息拉取、消息通知。这样拆分的好处非常明显。消息通道如果出问题我只重启 channel 服务不会影响客户库的读取。而且将来如果我想把短信、邮件也接入进来只用在 channel 模块里增加对应的适配器不用去动核心表结构。有人说微服务对大项目才有意义单机部署搞这么多模块有点浪费。我的看法是模块化不等于微服务它更多是代码边界上的约束。即使最终只打成一个大 JAR 包模块拆分也能让你在改动时少犯低级错误。当你同时改客户详情和在线客服页面时就会感谢这种边界。2.3 数据模型的三个核心思想整个数据库设计里我坚持了三件事。第一客户表和联系人表分开。客户是公司或组织联系人属于客户。很多 CRM 新手会把两者混在一张表里结果一个客户有多个对接人的时候数据就乱了。DeskcommCRM 里一对多的关系从一开始就建模清楚。第二所有关键业务表都带version乐观锁字段。销售和客服经常同时在多个设备上操作同一条客户记录不加乐观锁就会发生“最后提交覆盖前面内容”的问题。加了之后提交版本不一致时系统会提示而不是悄无声息地丢数据。第三消息记录单独建库。聊天记录的数据量增长速度远超客户档案如果和应用业务数据混在一起后续要按客户查历史会话时SQL 会越写越慢。我把消息记录放到独立的message_store库中按日期分表查询时先定位到客户再限定时间范围速度基本可控。3. 客户管理的实操细节3.1 客户去重是怎么做的做过 CRM 的人都懂最烦的不是录入客户而是录进去之后发现跟原有客户重复了。DeskcommCRM 的客户去重分为两阶段录入时实时校验以及每日批次清洗。录入时实时校验比较保守主要查手机号和公司名称两个硬指标。如果完全相同直接弹提醒如果相似度高于一定阈值比如“北京华信科技有限公司”和“北京华信科技”系统会显示疑似重复的列表让操作人决定是合并还是新建。每日批次清洗用的是自定义的分词和相似度算法先清洗特殊符号再用编辑距离算公司名的相似度。这里有个心得不要迷信复杂的 NLP 模型做客户去重规则的准确率往往更高。你只需要找出“集团”、“有限公司”、“股份公司”这类后缀词标准化之后再比较基本就能覆盖大部分重复场景。去重合并的时候有一个特别容易踩的坑合并客户记录时原有跟进日志、工单、聊天记录都要跟着转移到主客户下而且必须是在一个数据库事务里完成。我刚开始只转移了客户主表漏了订单导致后排数据统计对不上账。后来专门写了一个合并服务把所有关联表全部抽成一张映射清单逐个处理。3.2 自定义字段的灵活性与代价每个团队的销售字段都不一样。有人关心“客户规模”有人关心“需求类型”还有人关心“预算金额”。若把所有字段都写成固定列迟早会被需求淹死。所以我在客户模块里做了一个轻量级动态字段方案。实现方式并不复杂建一张customer_attribute表字段包括customer_id、attr_name、attr_value。客户详情页加载时先读固定列再动态读取该客户的扩展属性列表。好处是灵活坏处是查询统计变麻烦。曾经有同事要求“按行业和预算金额做一个组合筛选”直接对数据库做动态字段的条件过滤很痛苦。后来换了个折中方案常用字段仍然提供固定列但是允许在后台“启用”某些预定义字段选中的字段会生成真实的数据库列并通过模板机制在前端自动渲染。只有真正很少用的个性化信息才丢到 JSON 列里。用 JSON 列做存储查询时用函数索引也能接受。如果你从头开发建议一开始就想清楚哪些字段高频使用别把所有希望寄托在 EAV 模型上。3.3 跟进记录的写法跟进记录模块看起来就是一张表但“记什么”和“怎么展示”直接影响销售的使用积极性。如果只是做成一个文本框备注很多人写两天就不写了因为感觉太麻烦而且事后看没有价值。DeskcommCRM 里把跟进记录拆成了几个结构化字段跟进类型电话、微信、见面、邮件、其他。客户意向等级高、中、低、未知。下次跟进日期由系统结合人设定规则自动推算或手动指定。记录正文支持成员之后该成员会收到待办提醒。这样做的目的是让“跟进”成为一个动作闭环。打电话之前系统能看到上次跟进摘要打完电话只需要快速勾选类型和意向等级再写一段关键内容十秒钟就能完成。而不像过去那样要打开一个表单从头到尾敲一堆描述。结构化数据也给后续统计带来了便利比如“这个月通过电话渠道把客户从低意向带到高意向的数量”都是可以直接算的。4. 消息通道DeskcommCRM 最有难度的地方4.1 为什么消息模块是项目的灵魂很多CRM没有消息模块客户记录里的“沟通历史”只能靠销售手动录。但大家心里都清楚手动录的内容一定会有删减和美化无法还原真实对话。DeskcommCRM 的目标是让客户在网页、微信公众号或其他接入渠道里发来的消息都自动沉淀到客户时间轴上。这里遇到的第一问题就是“渠道接入”。我选了一条务实路线一开始不接任何第三方 IM 的开放接口而是自己做一套在线客服组件以网页嵌入的方式挂在官网和产品后台里。访客打开页面输入称呼和联系方式就能发起实时对话。对销售而言这个聊天窗口和外部微信聊天窗口长得几乎一样但所有消息都会写入message_store并自动关联到客户档案。后续如果要扩展微信或飞书只需要在 channel 模块里做适配器把外部消息转成标准的Message对象再走同样的归档逻辑。4.2 在线状态和消息时序实现在线聊天最核心的是消息不丢、不重、不乱序。我用 WebSocket 做实时通道消息服务端收到后先持久化再推送给在线接收方。如果接收方不在线消息就留在数据库表中等对方上线后拉取未读。最容易出问题的是消息乱序。WebSocket 虽然有顺序保证但客户端网络波动时重连后补拉历史消息可能和实时推送的数据交叉导致时间线出现“新消息后面跟着旧消息”的怪相。解决办法是给每条消息生成一个单调递增的序号用 Redis 自增实现。客户端渲染消息列表时按照序号排序而不是简单按数据库时间戳排序。时间戳到毫秒也可能相等但序号绝不会重复。碰到断线重连客户端用当前已收到的最小序号和服务端做一次差值同步只补缺的部分避免了整页刷新造成的消息闪烁。4.3 大量消息存储的性能方案一开始我也天真地认为 MySQL 表能永远扛住。后来系统跑了一个月未读消息和聊天记录加起来涨到了几十万条查询消息历史时明显变慢。最直观的体验是打开一个聊天记录很多的客户会话页面要等三秒才能看到历史内容。我采用的优化措施有三步按日期分表。消息表使用分区策略按月分区查询时带上时间范围MySQL 会自动只扫描对应分区。分离“热数据”和“冷数据”。90天内最近会话用高频表历史归档表单独存放。超过90天的消息从热数据表迁移到归档表。前端分页加载。聊天窗口初始化时只拉最近20条滚动到底部时再加载更早内容。这是最直观的优化配合分表之后历史消息打开基本能稳定在300毫秒内。还有一个容易被忽视的细节消息正文中如果有图片或文件不要在消息表里存 Base64只存文件链接和缩略图地址。一开始为了省事把图片转成 Base64 存到文本字段里结果一个月的消息数据就膨胀了 8GB。后来全部改成对象存储归档加 CDN 加速性能和存储成本都改善明显。5. 打造“永久在线”的部署体验5.1 服务器部署方案DeskcommCRM 的在线聊天功能要求服务端 7x24 小时运行所以部署方案不能是“开发机跑一个 java -jar”就完事。我用的是单台云服务器 Docker Compose 的方式。服务器配置不用太高2核4G起步包含 Nginx、后端应用容器、MySQL、Redis 四个核心组件。version: 3.8 services: mysql: image: mysql:8.0 restart: always environment: MYSQL_ROOT_PASSWORD: change_me MYSQL_DATABASE: deskcomm volumes: - mysql_data:/var/lib/mysql command: --default-authentication-plugincaching_sha2_password redis: image: redis:7-alpine restart: always command: redis-server --appendonly yes volumes: - redis_data:/data backend: build: ./backend restart: always depends_on: - mysql - redis environment: SPRING_PROFILES_ACTIVE: prod nginx: image: nginx:1.25-alpine restart: always ports: - 80:80 - 443:443 volumes: - ./nginx/conf.d:/etc/nginx/conf.d - ./frontend/dist:/usr/share/nginx/html - ./cert:/etc/nginx/cert volumes: mysql_data: redis_data:这里restart: always很关键。云服务器重启或者容器异常退出时Docker 会自动拉起服务配合进程守护基本不需要人工介入。如果有人问我“永久在线的CRM网站”是怎么做的本质就是把每一个环节都设计成可自动恢复的数据库有持久化Redis 有 AOF后端进程挂掉能自愈最后再配置一个探活脚本监控公网访问状态。5.2 HTTPS 和其他基础设置既然要对外提供在线聊天没有 HTTPS 的话浏览器会拦截混合内容WebSocket 也会被我用wss://协议所以 SSL 证书必须要配。我是用 Certbot 申请免费证书然后写了一个定时任务每月自动续期。Nginx 配置里要把 HTTP 强制跳转到 HTTPS避免用户通过明文访问。有一个细节容易被忽略WebSocket 反向代理时Nginx 需要设置proxy_read_timeout和proxy_send_timeout默认60秒可能会导致长连接被断开。我调成3600s并开启Upgrade和Connection头。location /ws { proxy_pass http://backend:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 3600s; proxy_send_timeout 3600s; }这样设置之后一整天挂在聊天页面不太会出现 WebSocket 断开重连的问题。5.3 免费CRM与私人网站的区别热搜词里有一个很典型的问题“免费CRM与私人网站的区别”。我自己的理解是免费CRM通常指服务商提供的多租户云端CRM注册即用但数据托管在别人的服务器上私人网站是自己掌控服务器、数据库和代码所有数据都归自己所有隐私和定制能力完全可控。但私人网站并不等于免费。你得承担服务器成本、维护成本和升级成本。免费CRM帮你省了这部分但代价是通常无法深度定制想改字段改流程都受限制。DeskcommCRM 选择自建私人部署是因为我需要把客户聊天记录和业务数据放在同一个系统里这属于核心资产我不想因为免费服务商的规则变更而不确定。如果你只是需要一个“够用就行”的客户登记表免费CRM完全够用。但如果你的业务流程比较特殊或者客户数据比较敏感无论从功能自由度还是数据主权角度自建一套轻量CRM都值得考虑。6. 团队协作与权限控制6.1 员工邀请机制系统单机自用的时候权限不是问题。一旦要多个人一起用就必须解决“怎么邀请员工”和“怎么限制员工权限”的问题。这正好是热搜词里提到的“飞鱼CRM怎么邀请员工”类似的需求。DeskcommCRM 的员工邀请流程是管理员在后台点击“添加成员”输入对方邮箱或手机号系统生成一个一次性邀请链接发送到对方邮箱或短信。新成员点开后设置初始密码即可激活账号。这里有一个安全细节邀请链接必须有时效性和一次性限制。我之前遇到过团队同事把邀请链接转发给其他人结果被无关账号激活。后来清了invite_uuid和expire_time同一个 UUID 激活后立即失效并且超过24小时自动过期。再配合管理员手动撤销基本堵住了这个漏洞。6.2 数据权限设计权限方面我设置了四个层级全部客户管理员和部门主管能看到所有客户数据。本部门客户只能看到本部门成员负责的客户。本人客户普通销售只看得到自己名下的客户。自定义共享规则通过共享规则把某些客户或客户群授予特定成员。这样做的核心逻辑是销售线索和客户档案是敏感数据。如果每个销售都能看见公司全部客户很可能出现争抢客户、信息泄露等问题。按所有权和共享规则来限制可见范围是最常见也最稳妥的做法。实现上并没有用很重的 RBAC 框架只是把user、role、customer_owner、customer_share四张表按规则联查。对比那些大型权限框架这种轻量设计在小团队场景下更好理解也更容易维护。7. 踩坑实录与排查技巧7.1 数据库连接池耗尽系统上线一段时间后某个工作日突然收到大量告警后端日志显示HikariPool-1 - Connection is not available, request timed out after 30000ms。我一开始怀疑是慢查询检查之后发现并没有特别离谱的 SQL。后来通过线程 dump 才发现原来是消息推送模块在并发量高的时候每个 WebSocket 连接都占着一个数据库连接去查“未读消息数”查询虽然快但并发量大把连接池占满了。解决方式很简单把未读数放到 Redis 里维护WebSocket 连接不再直接查数据库连接池核心线程数从10调整到20最大50同时给数据库查询加超时配置。这样调整后连接池耗尽问题再没出现过。7.2 WebSocket 重连风暴客户端断网后如果所有在线页面同时尝试重连服务端可能瞬间被大量握手请求打垮。特别是公司网络闪断的瞬间几十个在线坐席的浏览器一起重连会造成握手风暴。解决方式是在前端做随机退避重连首次重连延迟1秒失败后延迟翻倍最大到30秒并加入随机抖动值。服务端也要限制每个用户同时只允许一个 WebSocket 连接旧的连接直接关闭。这个方法很小但能明显降低极端情况下的服务压力。7.3 聊天图片加载超时有个客户反馈历史聊天里的图片经常加载不出来。排查后发现上传的图片直接存在了本地磁盘Nginx 静态文件路径配置没问题但随着图片增多磁盘 IO 在高峰期成了瓶颈。后来把图片迁移到了云上的对象存储URL 改为带签名的链接并加了一层 CDN 缓存问题才彻底解决。从这个事情我意识到一个道理凡是会增长的数据都应该从一开始就考虑“无限扩展”的存储方案而不是塞在应用服务器本地磁盘里。8. 复盘与下一步扩展计划DeskcommCRM 做到现在基本能覆盖一个中小团队的客户管理和在线沟通需求。接下来我想把两个方向做得更深。第一个方向是“会话智能”。现在聊天记录虽然归档了但只能靠人一条条看。我打算训练一个轻量级分类模型自动把客户消息打上“产品咨询”、“价格异议”、“售后投诉”等标签并且配合规则自动给客户分配意向等级。如果客户发来“太贵了”系统直接在客户详情页高亮提示商机风险。第二个方向是“外部渠道标准化接入”。我已经预留了适配器接口下一步打算接入企业微信和公众号。接入的思路依然是复用消息通道模块的协议把外部平台的事件变成标准的Message和Conversation这样销售不需要切换任何工具所有客户互动都沉淀在同一个时间轴上。回到最开始的问题做 DeskcommCRM 最大的收获是什么我觉得不是“写了一套系统”而是理顺了“客户互动数据应该如何被记录和复用”这个问题。市面上很多CRM重功能、重报表却恰恰忽略了业务人员最真实的使用场景。真正好用的系统一定是从第一线的工作流中长出来的而不是在PPT里规划出来的。如果你也有类似的客户管理需求建议先把自己的核心场景画出来客户从哪来谁在聊聊了什么聊完怎么跟进。想清楚这四个问题再动手做系统或选型方向一定不会偏。