做销售和客户管理这些年我最大的一个体会是工具本身不难找难找的是一个能跟着自己工作习惯走的CRM。市面上能试的我都试过一圈要么功能重光权限配置就能把人看晕要么数据不在自己手里想导出来还得看平台脸色。后来我干脆自己动手做了一个叫DeskcommCRM的桌面通讯型客户关系管理系统从设计到上线折腾了两个多月目前跑得很稳。这个名字拆开看很有意思Desk是桌面Comm是通讯。合起来就是“把日常沟通和客户管理放在同一个工作台里”。它解决的痛点很直接客户资料不再散落在Excel表格、微信聊天记录和邮件附件里所有线索、跟进、成交、售后全在一个浏览器页面里完成装好之后随时打开就能用数据全部存在自己的服务器上永久在线没有订阅费也没有数据被平台锁死的隐患。这篇内容我会从整体设计思路、核心模块的实操细节、部署上线的几种路径、团队协作和员工邀请以及我踩过的坑这几个方面完整拆一遍。不管你是想自己搭一套类似的CRM还是单纯好奇一个自建客户管理系统到底能做到什么程度应该都能从中找到能直接抄作业的东西。1. 项目整体设计与思路拆解1.1 名字里的逻辑DeskcommCRM到底定位了什么很多人在做项目的时候一上来就想把功能堆得又大又全结果做着做着就失控了。我做DeskcommCRM之前先把名字定下来了这其实是个笨办法但特别有效名字即边界。Deskcomm这几个字母硬生生把项目框在了两个核心关键词上——桌面和通讯。桌面意味着什么意味着所有操作不需要装客户端打开浏览器就能进工作台。无论是Windows、macOS还是Linux甚至平板电脑只要浏览器能上网登录之后就是同一个系统。这个设计在当时是刻意为之的因为团队里有人用Mac有人用Windows还有人偶尔用iPad在外面见客户如果做成桌面客户端光兼容性问题就能拖掉一半工期。通讯这个关键词更关键。传统CRM把客户当成一条条记录填完公司名、联系人、电话就完事了但实际做业务的人都知道真正的客户资产不只是那几个字段而是你跟客户之间所有的互动过程。加了微信之后聊了什么发邮件之后对方怎么回复的电话里承诺了什么事情这些过程才是判断一个客户有没有希望成交的关键依据。所以DeskcommCRM从一开始就把“会话记录”和“沟通时间线”放在比“客户信息列表”更重要的位置上。1.2 一条主线从“管客户”到“管跟进”的转变很多自己做CRM的人会陷入一个误区花大量精力设计客户字段什么行业、规模、来源、等级、区域恨不得把客户的所有信息都结构化结果录数据的时候没人愿意填系统慢慢就变成了一个摆设。我最早用Excel管理客户的时候也有这个问题。表格做得特别细致但到了周一早上打开表格根本不知道今天应该跟进哪些人。有些客户上一次联系还是半个月前有些客户说好上周给报价结果忘了发这些关键信息全凭脑子记时间一长就漏单。漏掉一个潜在客户损失的可能是几千几万块的订单。所以DeskcommCRM的设计主线不是“把客户信息管好”而是“把跟进动作管好”。核心字段不是公司规模、客户等级这些静态属性而是“下次跟进时间”和“跟进状态”这两个动态字段。列表页默认按照下次跟进时间排序系统每天早上自动生成一份当天的跟进清单哪些客户该打电话了哪些客户答应今天回消息但还没回哪些客户超过三天没有动静需要激活全部列出来。数据模型也围绕这条主线重新做了简化客户、联系人、跟进记录、订单四张核心表。客户表存基本信息和归属联系人表存具体的对接人跟进记录表按时间追加订单表关联成交数据。每一条跟进记录都会自动追加到客户的时间线上什么时候联系过、聊了什么、下一步打算怎么做清清楚楚。1.3 方案选型为什么是自建Web版而不是Excel、本地软件或现成SaaS选择自建Web版之前我把其他几条路都认真走了一遍也推荐准备做类似东西的朋友先做个对比。Excel管理客户的问题有三个一是多人协作直接崩溃两个人同时改一个文件版本冲突能把人逼疯二是没有提醒机制就算写了下次跟进时间到了时间也没人提醒你三是手机上看体验太差外出见客户的时候想查一个电话号码翻半天目录找不到文件。本地单机CRM软件的问题相对少一些但依然有硬伤数据只存在一台电脑里换电脑、电脑坏了、出差忘带电脑都意味着客户资料没法访问。而且这类软件通常已经停止更新界面老旧手机端适配也基本没有。SaaS版的现成CRM功能确实齐全但有两个绕不开的坎第一是按坐席收费一个小团队五个人一年下来不少钱随着人数增长还是持续投入第二是数据不在自己手里客户资料、跟进记录、成交金额全部存在对方的服务器上哪天平台调整策略或者停止服务数据迁移是一件非常痛苦的事情。自建Web版的好处刚好能覆盖上面这些坑浏览器访问任何设备都能用数据在自己服务器上随时全量备份功能逻辑自己说了算想加字段改流程随时动手。至于付出就是得自己维护一台服务器和一个数据库。对于一个小团队来说这个付出完全是可控的后面会细说部署方案。技术选型上我最后是服务端用Node.js数据库用PostgreSQL前端用Vue。Node.js在处理消息推送、WebSocket实时通知这类通讯场景的时候非常顺手PostgreSQL在几万条客户记录、几十万条跟进记录这个量级上性能绰绰有余Vue做后台管理系统生态成熟社区资料多。这套组合不追求新技术追求的是稳妥、好维护、遇到问题一搜就有答案。2. 核心功能模块与实操要点2.1 客户台账字段设计决定后续所有功能的边界客户台账是整个系统的基础工程字段设计得好不好直接决定后面的筛选、统计、看板能不能做得顺手。我第一版贪多设计了二十多个字段结果录数据的时候自己都嫌烦后来砍到极致反而好用多了。必填字段我只保留了三个客户名称、负责人、来源渠道。客户名称就是公司名或者个人称呼负责人默认是创建人来源渠道是个下拉选项比如“朋友介绍”“官网表单”“行业群”“电话外呼”“广告投放”。这个来源渠道特别重要后面统计每个渠道的转化率、决定广告投放方向全靠它。状态字段做成可配置的“阶段”默认是潜在客户、跟进中、已成交、已流失四个阶段但允许管理员在后台自己加比如有的团队需要“报价中”“合同审批中”“待回款”这些更细的划分。这个阶段字段和看板模块联动阶段一变看板上的漏斗就自动更新。预计成交金额和下次跟进时间这两个字段是我额外坚持的。预计成交金额用来算销售预测月底总结的时候能看出这个月正在跟进的单子大概值多少钱下次跟进时间是整个系统的灵魂字段所有提醒和任务都围绕它运转。实操中建议金额字段用整数或者小数存储避免浮点计算误差显示的时候再格式化成两位小数。自定义字段的能力一定要预留。团队业务会变今天可能只需要记录微信明天可能需要记录抖音号、快手号如果这些字段都写死在数据库里每次改需求都要动表结构非常痛苦。我做了JSON类型的扩展字段前端动态渲染对应表单虽然查询性能稍差一点但换来的是极大的灵活性在小数据量下完全感觉不到差别。2.2 跟进记录与时间线让历史不丢是CRM存在的意义有一句话我经常跟团队说CRM里最值钱的不是客户名单而是和客户互动的全过程。客户名单只是一堆联系方式而互动过程才能告诉你这个人到底怎么聊下来、报价报了多少、当时有哪些顾虑。跟进记录的录入流程一定要短。刚开始我设计了七八个字段比如沟通方式、沟通摘要、客户意向度、下一步计划、是否需要领导介入等等结果录入成本太高大家打电话之前一想到要填这么多内容就犯懒。后来精简成两个核心字段加一个可折叠的扩展区沟通方式电话/微信/邮件/面谈和沟通内容再放一个“下次跟进时间”作为快速选项。沟通内容默认按照“说了什么—客户反馈—下一步计划”三段式引导但技术上不强制允许自由输入降低心理门槛。每一条跟进记录提交之后自动追加到客户详情页的时间线上按时间倒序排列。一个客户从第一次接触到最终成交或者流失所有关键节点都在这一条时间线里。新接手这个客户的同事不需要问东问西翻一遍时间线就清楚这个客户目前是什么情况、承诺过什么、卡在哪个环节。时间线模块里还需要支持附件比如截图、报价单PDF、合同扫描件。这些附件会统一存到附件目录数据库里只存路径和MD5值。MD5用来去重同一个报价单如果发给三个客户服务器上只保存一份文件节省存储空间。2.3 消息与通讯集成桌面通讯的真正含义是“少切窗口”DeskcommCRM里“桌面通讯”的分量主要体现在这块把第三方平台的客户消息统一收进来让销售不用反复切换窗口。我优先接入了企业微信和邮件这两个场景覆盖了绝大多数商务沟通。先说说消息接收的基本原理。无论是企业微信还是其他平台做消息接收无非三步配置回调地址、校验签名、解析消息存库。第三方平台收到发给你的新消息之后会向你在后台填写的回调URL发送一个POST请求你的服务器接口接收到请求后先校验签名或者Token确认这个请求确实来自对应平台而不是伪造的然后解析消息内容写入数据库再通过WebSocket推送给浏览器前端页面上的会话列表就会实时刷新。签名校验这块必须认真做。企业微信的规则是把Token、时间戳、随机数、消息体加密串按照字典序排列后做SHA1加密然后和请求里带的签名参数比对。如果校验失败直接拒绝请求千万不要把未通过校验的请求处理成正常消息。这个环节做得草率很容易被恶意构造请求刷进垃圾数据。由于回调地址必须是公网能访问的HTTPS地址我在前面用Nginx做了反向代理SSL证书用Lets Encrypt免费签发的三个月自动续期一次。接口接收到的消息先写入一个待处理队列异步存库避免第三方平台等待超时重试导致重复消息。这里一定要做消息去重用“平台的MsgId加上发送者ID”作为唯一键重复的请求直接丢弃否则客户重复的消息会在时间线里出现两遍。2.4 任务提醒与跟进SOP让系统每天告诉销售“今天该干什么”跟进SOP是DeskcommCRM里投入产出比最高的功能。刚上线的时候它只是一个简单的“下次跟进时间到期提醒”后来逐步完善成了可配置的规则引擎。规则很简单就是“如果满足条件A则自动生成任务B”。举个例子所有未成交客户如果超过3天没有跟进记录系统自动生成一条跟进任务分配给客户负责人。这个规则背后的逻辑很朴素一个潜在客户超过三天没有动静热度就开始下降了必须主动联系一次摸摸情况。再比如已报价客户如果超过7天没有反馈自动生成“询问报价反馈”的任务提醒销售跟进。这些都是销售管理中反复验证过的节奏写进系统里每天自动跑。技术实现上我用一个定时任务每小时扫描一次数据库查询所有符合规则条件的客户生成当天的待办任务。生成的时候做去重同一天同一个客户不能重复生成同样的任务否则销售打开待办列表看到一堆重复项反而会产生抵触情绪。任务生成后通过站内信和邮件双重提醒邮件模板里直接带上客户名称、最后一次跟进时间、建议话术销售点开邮件就能进入状态。实测下来这个功能上线后最大的改变不是大家真的都按规则联系客户了而是漏跟进的概率明显降低。以前是凭记忆想起某个客户好像很久没联系了现在每天早上一打开系统就能看到哪些人需要今天处理。系统提醒一次哪怕当时没时间打电话也会在待办里面悬着直到处理完才会消失。3. 部署上线与数据安全落地3.1 永久在线的三种落地路径云服务器、家用NAS、托管主机怎么选很多人一听到自建系统就紧张觉得要懂运维才能搞定。其实搭建一个供小团队使用的CRM网站比想象中简单。根据团队规模和技术能力有三条路可以选。云服务器是最推荐的一条路。阿里云或者腾讯云的轻量应用服务器就够用了2核4G的配置带宽按流量计费或者固定5M一年下来也就几百块。好处是公网IP固定域名解析简单HTTPS证书申请方便随时随地都能访问。DeskcommCRM目前就部署在一台2核4G的云服务器上跑着Node.js服务、PostgreSQL数据库和Nginx日常CPU占用率不到百分之十非常轻松。家用NAS适合数据洁癖比较重、不想把数据放在任何云服务商机房里的用户。群晖、威联通这些主流NAS都支持Docker把镜像跑起来再做一个端口映射配合DDNS动态域名解析也能实现外网访问。但这里要提醒一句家用宽带通常没有固定公网IP上行带宽也有限如果同时访问的人比较多体验会打折扣而且家里断电断网都会导致CRM暂时不可用。托管主机适合有一定技术基础的用户。买一台独立服务器放在机房托管或者直接用云服务商的高配裸金属实例性能上限最高但价格也最高配置和维护的复杂度也上来了。对小团队来说真的没必要。我的建议是三个人以内的团队先用轻量云服务器跑起来等团队扩大到几十个人再考虑升级。操作系统建议直接选Ubuntu 22.04 LTS或者Debian 12社区支持好遇到问题搜到解决方案的概率大。部署方式我在后面复盘的时候会讲第一版手动部署踩了不少坑后来改成Docker Compose才消停这个教训值得单独说一下。3.2 免费CRM和自建私人网站到底差在哪一个很容易被忽略的认知问题这个点经常有人问我结合自己的体会把两者的差异讲透。免费CRM最典型的模式是SaaS平台提供的基础免费版免费的原因不是做公益而是用免费吸引用户进来后续通过坐席数升级、高级功能包、数据导出次数等增值服务收费。你在平台上录入的所有客户信息都在对方的数据库里平台规则一变比如免费版每天只能导出100条数据你也没有办法。更严重的是一旦平台停止运营所有数据能不能完整导出、以什么格式导出都是未知数。自建私人网站或者说自建系统本质上是买地盖房子。前期确实要投入域名要花钱、服务器要花钱、时间精力也要花费但数据完整地掌握在自己手里想备份就备份想迁移就迁移完全不受第三方平台政策变动的影响。如果你的客户数据积累得越多时间越长这个选择带来的安全感和长期价值就越大。两者之间最核心的差别不是钱而是数据所有权和可迁移性。免费CRM像是租房子拎包入住很舒服但房东随时可以涨租、收回房屋你装修的钱也带不走。自建系统像是买地盖房前期的规划和施工费心费力但房子永远是你的哪天想换装修风格随时能改。在实操层面我建议数据量在500个客户以下、没有技术维护能力的人先用高质量的免费CRM过渡但如果你已经积累了上千个客户或者客户质量比较高早一点切换到自建系统数据迁移的成本会低很多。越到后面切换付出的代价越大。3.3 备份与权限不要等数据丢了才想起来这两件事CRM系统里最怕的不是功能bug而是数据丢失。客户资料和跟进记录是团队过去几年积累下来的核心资产服务器硬盘故障、误操作清空数据库、被勒索病毒加密任何一种情况发生而你没有备份都是毁灭性的打击。备份策略不需要很复杂但必须自动化。我在服务器上写了一个备份脚本每天凌晨两点通过cron定时执行用pg_dump导出PostgreSQL数据库再连同附件目录一起打包保留最近7天的备份然后通过rclone把备份文件同步到云服务商的对象存储上。这里的关键点是“异地备份”如果备份只存在同一台服务器上服务器硬盘坏了备份也一起报销。对象存储一年几十块钱买的不只是空间是数据丢失时候的后悔药。权限安全这块我总结了四个必须做的点第一全站强制HTTPS绝对不接受纯HTTP访问否则账号密码在网络上裸奔被中间人抓到就是事故第二密码存储不能明文也不能用MD5必须用bcrypt这类带盐的哈希算法就算数据库被拖走暴力破解的成本也极高第三登录会话设置有效期默认7天超过时间自动失效操作频繁的话会自动续期第四连续登录失败5次锁定账号15分钟这个能有效阻挡大部分撞库攻击。操作日志也是权限系统的一部分。登录日志、新增客户、修改客户、删除跟进记录、修改订单金额这些关键操作全部记录在案。看似增加了一点存储开销但真到核对提成、追溯责任的时候它比什么都管用。4. 团队协作与员工邀请实操4.1 邀请员工加入从“单人工具”变成“团队系统”的关键一步DeskcommCRM前期是单人使用但当数据量上来、业务需要分给团队里其他人处理时邀请员工加入就是必须跨过的一道门槛。这一步如果权限设计不好轻则相互干扰重则数据泄露所以我把整个流程拆得很细。管理员在后台的成员管理页面生成一个邀请链接或者6位随机邀请码同时给这个邀请设置一个预置角色。员工拿到邀请链接后打开先输入自己的邮箱和手机号设置初始密码完成账号激活然后等待管理员审核。这个“先激活后审核”的流程是后来补上的最初版本是点击链接直接就能登录结果有人通过分享邀请链接把不相关的人放了进来虽然没造成什么后果但给我提了个醒邀请链接不能当摆设必须配合审核机制。邀请链接默认24小时有效过期作废。如果团队成员没来得及激活管理员可以一键重新生成。离职员工的账号处理更关键第一时间在后台禁用而不是删除。禁用可以保留他名下所有操作记录方便后续审计和交接。如果一个离职员工名下的客户需要分配给其他人管理员可以发起批量转交操作客户负责人一换防撞单的锁定关系也会跟着重置。4.2 角色和数据权限私有还是共享要提前想清楚权限设计是CRM系统里最容易被低估的一环。如果所有员工登录后都能看到所有客户那这个系统在稍微正规一点的销售团队里肯定出乱子。DeskcommCRM设计了三种角色管理员、销售、访客。管理员拥有全部权限销售可以正常录入和跟进客户访客只能查看被明确共享的数据不能修改。在数据可见范围上我采用的是“共享客户池私有客户池”双轨制这个灵感借鉴了不少主流销售管理软件的做法。共享客户池里放的是线索、公共客户所有销售都能看到谁认领了谁就变成负责人别人只能查看不能编辑。私有客户池里放的是销售各自跟进的客户其他人默认不可见除非通过客户协作功能主动共享给某个同事。这里有一个教训权限不能只做页面隐藏必须在后端接口层面做强校验。第一版只在界面上判断“你是不是这个客户的负责人”结果懂一点技术的人直接调接口就能看数据。后来把所有数据查询都强制经过一个权限中间件根据当前登录用户的角色和客户归属关系动态过滤数据。哪怕前端页面有漏洞后端数据也是被层层挡住的。权限模型越早设计得细后面积累的数据就越规范。临时决定的权限变更往往伴随着脏数据比如一个客户今天在共享池里明天被销售认领到私有池后天又因为归属争议被管理员转给另一个销售每次变更除了记录日志最好还要有个权限变更时间线将来做业绩归属核算的时候有据可查。4.3 防撞单和操作日志避免“飞单”的重要防线用过飞鱼CRM或者其他销售管理系统的同行应该都遇到过“撞单”问题同一个客户销售A和销售B都在跟进最后成交了算谁的这个问题处理不好轻则同事之间闹矛盾重则直接导致销售人员流失。自建系统一样面临这个问题而且因为没有平台规则兜底必须自己在产品层面解决。DeskcommCRM的解决思路是“锁定优先”。当销售从共享客户池里认领一个客户或者管理员分配一个客户给某位销售这位销售就自动获得该客户的排他性所有权。其他销售可以查看这个客户的基本信息但不能编辑也不能提交跟进记录。如果要变更客户负责人必须由管理员操作普通销售之间不能私相授受。客户锁定状态之下系统的跟进记录模块也会自动加上时间戳和操作人信息。实际操作中很多企业在防撞单之外还担心“飞单”——员工把客户资源带走甚至卖给竞争对手。这种情况下操作日志是最有威慑力的工具。我在系统里把所有关键操作都记录下来了谁在什么时间创建了客户、导出了客户列表、修改了联系方式、下载了附件。日志不可删除只有管理员可以查看导出格式和CRM的数据导出是一致的方便做内部审计。防撞单和操作日志这两块功能看起来不起眼但在真实业务场景里比任何花哨的报表都重要。它们解决的都是在客户资源分配和核算过程中的人性问题。5. 常见问题与排查技巧实录5.1 部署之后打不开/白屏先查服务再查网络最后查代码自建系统最常遇到的问题就是部署完访问不了。我一开始也经历过这种手忙脚乱的状态明明按照教程配置好了打开浏览器输入域名结果页面转半天或者直接白屏。我的排查顺序是固定的也建议你照着这个顺序来。第一步看服务状态执行systemctl status启动脚本或者docker ps看看容器在不在跑。很多时候打不开只是因为服务启动失败数据库没连上或者端口被占用。第二步看Nginx日志访问日志和错误日志分别在access.log和error.log里错误日志里会直接告诉你是504超时还是502网关错误。502基本就是后端服务没起来或者起了又崩了这是最容易判断的。第三步看防火墙云服务器除了在系统层面要开放80和443端口还要在云控制台的安全组里放行对应端口。这一步漏了特别经典因为本机curl测试一切正常但外部就是访问不到。第四步才轮到排查代码而且90%的情况在第三步就能解决问题。白屏还有一种可能是前端静态文件路径不对。Vue项目默认使用相对路径打包部署在子目录下就会白屏我后来在配置文件里改成绝对路径才解决。这类问题不需要死记硬背记住先服务、后网络、再代码的排查顺序就不会慌。5.2 消息接口收不到推送回调地址和Token校验是重灾区接入企业微信、微信公众号或者钉钉机器人时最常见的毛病就是“平台端显示推送成功但我这边接口就是没反应”。这个问题看似复杂其实翻来覆去就那几个原因。首先要确认回调地址是不是公网可以访问的HTTPS地址。第三方平台的消息回调地址不支持HTTP甚至部分平台要求必须是备案域名所以测试的时候不要拿内网IP加NAT穿透来试。其次要确认Token和EncodingAESKey配置一致平台端填什么你服务端校验的时候就用什么一个字符都不能差。排查的时候我有一套自己的checklist第一在浏览里直接访问回调地址看是不是能正常返回一个接口定义好的欢迎信息如果不能访问说明Nginx配置或者域名解析有问题第二把平台发过来的请求参数完整打印到日志里包括时间戳、随机数、签名和密文人工比对一下签名计算是否正确第三确认服务端处理完消息之后有没有返回正确的成功响应字符。大部分平台要求你返回特定的字符串来确认消息已经成功接收返回格式不对平台会认为发送失败就一直重试重试次数多了还会断掉推送通道。5.3 数据不同步/时区错乱数据库统一存UTC展示层转本地时间这个坑是我在建系统第三周的时候踩的。当时发现上午录入的跟进记录到了下午再看时间变了8个小时刚开始以为是数据丢失后来才发现是时区问题。服务器上的操作系统默认时区是UTC数据库存的也是UTC时间但用户在中国期望看到的是东八区的时间。解决办法也很简单直接数据库里一律存UTC时间应用服务在处理展示逻辑时按当前用户的时区转换后输出。千万不要在数据库里直接存东八区的字符串看似方便实际上后续做统计报表的时候会非常痛苦。比如月底要算“每天新增客户数”按字符串判断日期的话凌晨0点到8点之间录入的数据会被算到前一天或者后一天去整个报表就乱了。前端展示层我用了Day.js库把所有从后端收到的UTC时间字符串转成用户本地时间显示同时标签上明确标注“北京时间”。团队里如果有人出差到其他时区系统还支持在个人设置里切换时区数据存储层不变只是展示层多一步转换。5.4 备份恢复少用“测试一下备份”的心态恢复一次才算数备份脚本写了不代表真的能恢复这句话是我自己用一次数据事故换来的教训。刚上线不久有一次调整数据库表结构手滑删掉了一张跟进记录表还好备份脚本一直在跑结果在恢复的时候才发现备份的SQL文件只有几十KB明显不对。排查下来发现是备份脚本里的pg_dump命令默认不会备份某些扩展插件的数据导致关键内容没导全。所以我现在对备份的三点要求第一备份文件每天检查一次大小如果某天文件尺寸突然变小大概率备份有问题第二每个季度做一次正式的恢复演练把备份恢复到一台临时服务器上查几个关键客户的数据在不在第三备份文件一定要做加密再传到对象存储防止对象存储账号泄露导致客户数据被拖走。恢复的步骤也整理成了标准流程停掉应用服务恢复数据库备份恢复附件文件目录检查权限和目录归属启动应用服务然后随机抽验几条数据。全部走一遍没问题才算一次真正成功的恢复。5.5 问题排查速查表我把常见问题整理成了下面这个表方便出问题的时候按图索骥。症状可能原因解决办法域名打不开浏览器转圈服务未启动、Nginx未配置、安全组未放行查服务和日志检查80/443端口确认安全组规则网页白屏前端静态资源路径错误检查Vue打包配置确认Nginx root路径能打开但登录后报错数据库连接失败或密码错误查看后端日志确认数据库连接串和密码消息接口收不到推送回调地址不可达、Token不一致、未正确返回成功响应按checklist逐项排查打印完整请求日志同一消息重复入库缺少去重逻辑以第三方平台的MsgId发送者ID做唯一键时间显示快了/慢了8小时时区未按UTC中国时区处理数据库存UTC前端按用户时区转换显示备份文件很小备份脚本遗漏扩展数据检查pg_dump参数完整导出所有schema和相关序列登录账号被锁定连续失败次数达到阈值等待15分钟自动解锁或管理员手动解除锁定客户数据权限混乱角色配置错误或权限中间件未生效检查角色和归属字段确认后端接口经过权限过滤5.6 复盘如果重新做一遍我会在哪些地方直接改掉最后说一点个人体会。做DeskcommCRM的过程中踩了不少坑如果重新来一遍有三个地方我会在第一天就做好而不是事后再补。第一部署环境从最初就统一用Docker Compose。第一版是直接在服务器上手动装Node.js、PostgreSQL、Nginx虽然能跑但换一台机器部署的时候所有环节都要重新来一遍非常痛苦。后来改成Docker Compose一个配置文件搞定所有依赖数据卷挂载到宿主机目录升级的时候也不用担心破坏环境。第二消息模块一开始就抽象成统一的接口层。最初只想接入企业微信结果后来要接邮件和网页表单的时候发现业务逻辑散布在各个控制器里改起来特别费劲。后来重构了一个消息中心各种渠道先统一转成内部消息格式再由同一个处理流程分发给业务模块。这个抽象虽然前期多花了一点时间但后面接新渠道的效率提升是成倍的。第三权限模型宁可一开始就做得细一些。一开始图省事只做了页面级权限控制后来补数据级权限的改动量比从头设计还大权限判断散落在几十个接口里逐个排查的日子不好过。如果你也在做类似项目第一版就考虑好“谁能看到哪个客户”哪怕先不做太多角色数据过滤的中间件也应该在第一版就落到所有查询接口上。作为一个从Excel表格一步步走过来的使用者我现在打开DeskcommCRM的工作台看着当天待跟进客户列表和消息中心里新进来的线索最大的感受是一个顺手且数据自主的客户管理系统给人带来的确定性确实值回当时折腾它的所有时间。
