简介一套面向中小企业及开发者二次使用的开源客户管理CRM系统基于PHP开发源码未加密支持自由修改与功能扩展适合需要搭建私有化客户管理平台或深入学习CRM业务流程的PHP工程师。系统功能覆盖客户全生命周期包括公海管理、客户公海、线索管理导入、转移、列表、来源与状态、客户管理添加、编辑、删除、导入、转移、成交客户、行业类别、客户状态等、业绩订单订单列表、审核、删除以及系统设置邮箱配置、权限管理、管理员与用户组管理等模块界面设计较为大气基本涵盖常见CRM操作场景。压缩包为ZIP格式整体约32.55MB内含完整的PHP源码及部署相关文件可直接上传至服务器配置运行。这套源码当前已有271人学习下载对于想快速获得一套可运行、可定制的CRM系统或希望参考其权限与线索流转逻辑进行二次开发的用户而言具备不错的实用价值。 做开发和搞运营的朋友对“客户管理系统”应该都不陌生。这两年我接触过不少中小团队花了不少钱买SaaS版的CRM结果第二年就发现两个尴尬问题一是功能做死了流程和自家业务对不上二是数据在别人服务器上想导出来做个分析都费劲。后来我慢慢转向了开源方案尤其是一套PHP技术栈的CRM客户管理源码整个系统直接摊在你面前哪里看不顺眼就改哪里。最近我把一套3.0版本的PHP CRM系统源码完整跑了一遍源码无加密可以无限二次开发从部署到改造都做了记录这篇就把其中最有价值的东西整理出来。适合读这篇内容的人大概有两类一类是公司里负责选型或自研的技术负责人想评估是买现成产品还是拿开源代码做私有化部署另一类是PHP开发工程师手里拿到一套老的CRM源码不知道怎么下手改造或者改造到一半踩了坑。不管你是哪一种这篇都会从“业务定位”“选型逻辑”“部署实操”“模块拆解”“第一次改代码”和“避坑记录”这六个角度展开说清楚这套系统到底能干什么、怎么干、有哪些坑。1. 这套3.0版本解决谁的客户管理难题——定位与适用场景1.1 客户管理最本质的诉求是“流程跟着业务走”很多团队在刚开始管客户的时候用的都是Excel表格。客户一多、销售一多问题就全冒出来了客户跟进到什么阶段了上次联系人是谁说的什么事哪些商机下个月可能签约这些信息散落在不同人的表格里根本没法汇总。CRM系统要解决的核心问题就是把这些散落的信息收拢到一套统一流程里让“客户建档—跟进沟通—商机推进—合同签约—回款管理”这条链路变得透明、可追踪。我拿到这套3.0源码后第一感觉是它把最基本的客户生命周期管理做完整了。它不像那些动辄几十个模块的重型CRM一上来就要你配工作流、配审批流、配复杂权限搞了半个月还没看到客户列表长什么样。这套系统的设计思路更接近“直接开张做生意”装完之后销售就能录入客户就能写跟进记录就能建商机管理者就能看报表。这种克制其实很重要因为复杂系统最大的问题是学习成本团队不愿意用再强也不落地。1.2 什么人适合拿这套源码做二次开发我在实际使用中觉得这套源码最适合三类场景。第一类是业务模式比较特殊的公司比如做项目制交付的公司客户从“意向”到“合同”中间可能夹着“方案报价”和“项目评审”标准CRM没有这个状态你需要自己加字段、加状态、加流程第二类是数据敏感型公司客户信息、报价信息、合同信息都不想放在第三方SaaS平台上私有化部署在自己服务器上更安心第三类是已经有开发团队的公司在做产品化的准备想拿一套成熟的基础代码做底座在上面不断叠加自己的行业know-how。反过来说如果你只是想今天装完、明天就用、后天不维护也不想有开发人员参与那这套源码其实不适合你。开源系统的前提是你愿意投入精力去运行和维护它。把代码给你不等于把服务给你这是一个非常重要的预期管理。真正值钱的不是这一份代码而是你自己团队动手改它的能力。2. 选PHP做二次开发基底核心是这三件事2.1 PHP生态对中小团队到底友不友好有人会觉得PHP技术栈老看到PHP就摇头。但放在CRM这个场景里PHP恰恰是性价比很高的选择。第一市面上能找到的、可以直接部署的客户管理开源项目PHP系占了相当大的比例样本多、参考多、踩坑的经验也多第二PHP的部署门槛确实低一台普通云主机装好Nginx、PHP、MySQL就能跑不挑环境对没有专职运维的中小团队来说很省心第三PHP开发人员好招市面上存量PHP开发者很多后续想扩展开发团队找人成本比冷门语言低得多。我在跑这套3.0源码的过程中最大的体会是“可读性”很重要。好的PHP项目代码风格清晰目录结构规范你打开一个控制器文件基本就能看明白这个功能的完整脉络。这比某些过度设计、层层封装的框架友好太多了。二次开发讲究的是“拿到手能改”而不是“拿到手得先读三个月源码”。2.2 无加密源码真正值钱的地方在哪无加密这三个字很多非技术的人可能没感觉干过开发的人才知道有多重要。市面上很多商业CRM产品源码是加密过的你想改一个字段名都费劲更别说加模块、改逻辑。你花钱买到的不是一个可以随便折腾的系统而是一个“租来的半成品”。这套3.0系统源码无加密意味着你可以直接看到数据库结构、控制器逻辑、前端模板可以直接审计它有没有安全隐患也可以放心地做深度定制。不过这里要提醒一句无加密不代表没有版权。开源不等于可以随意商用分发你拿到源码后要看一下它带的开源协议。如果协议要求保留版权声明那么你二次开发后的产品也应该保留相应声明如果协议允许商用那才能把它作为商业产品基础。我在项目启动前第一件事就是把协议读明白这是基本素养别嫌麻烦。3. 从零跑通源码环境、安装、配置的完整过程3.1 环境准备和目录结构我测试用的环境是Linux服务器装的是PHP 7.4、MySQL 5.7、Nginx 1.18。这套系统对PHP版本有最低要求安装前务必先确认版本别拿PHP 5.6那种老古董去跑会有很多语法兼容问题。PHP需要开启的扩展一般是这几个pdo_mysql、mbstring、curl、openssl、gd缺少哪个就装哪个大多数云镜像已经默认装好了。下载源码解压后第一件事是看目录结构。这套系统的结构很典型项目根目录 ├── app # 应用代码目录 │ ├── controller # 控制器 │ ├── model # 模型 │ └── view # 视图模板 ├── config # 配置文件 ├── public # Web入口目录Nginx根目录指到这里 ├── runtime # 运行时缓存目录需要写入权限 └── install # 安装向导如果你拿到的是ThinkPHP系开发的系统一般入口目录是public所有HTTP请求都经过index.php如果你拿到的是原生PHP开发的老系统入口文件可能在根目录。这套3.0走的是框架路由模式所以Nginx配置时要把root指向public目录并且配置好伪静态规则。3.2 初始化安装重点看installer浏览器访问域名后系统会跳转到安装向导页面。安装向导会检查环境是否满足要求比如PHP版本、扩展是否开启、目录是否有写权限。这个环节最容易出问题的就是runtime目录没有写权限导致安装向导卡在第一步。我用命令行直接改了一下权限chmod -R 755 runtime chmod -R 755 public/static接下来填写数据库信息。这里有个小建议数据库名不要用默认的crm改成你自己的项目代号比如mycompany_crm密码一定不要用弱密码数据库一旦被攻破客户信息全都裸奔。安装向导会自动导入初始SQL创建核心表结构。跑完后进入后台登录页默认管理员账号一般在安装完成页有提示立刻登录进去改掉默认密码并且把安装目录install直接删掉或改名避免被恶意重装覆盖数据。3.3 改配置文件的几个关键点系统跑起来之后配置文件要重点看三项。第一是数据库配置确认连接信息、字符集是否为utf8mb4这个决定中文和特殊符号能不能正常存取第二是调试开关开发阶段可以打开详细的错误提示但一旦上生产环境务必关闭并开启日志记录不然出错信息直接暴露给用户既难看又不安全第三是时区配置在PHP配置文件里把date.timezone设置成Asia/Shanghai否则后续系统记录客户跟进时间、合同时间都会出现时间差排查起来极其折磨人。4. 模块拆解从客户到回款的业务流转设计4.1 客户库与跟进记录——这套系统的“地基”跑通系统后我花了很长时间把数据库的表结构过了一遍确认这3.0版本的核心逻辑是完整的。最核心的是客户主表在数据库里对应类似crm_customer这样的表存储客户名称、联系人、电话、来源、所属销售、创建时间等基础属性。与之紧密相关的是一张跟进记录表记录每次销售和客户的沟通内容、下次跟进时间、跟进方式。这两张表的设计决定了整个系统的使用体验。我遇到过不少开源CRM跟进记录只是简单堆在日志表里没有和客户状态做关联导致销售要手动看“这个客户上次聊到哪了”。这套3.0跟进表里带了“下次跟进时间”字段首页仪表盘会按时间维度提醒销售哪些客户该联系了这对一线销售来说是非常实用的功能。做二次开发时最优先考虑的一定是这两张表因为它们直接承载业务数据。4.2 商机与合同回款——衡量CRM有没有用的标准商机模块在业务上的定义是“有可能成交的潜在销售机会”。这套系统的商机表里包含商机名称、预计金额、成交概率、当前阶段、预计签约日期等字段。阶段是高度可配置的默认可能是“初步接洽—需求确认—方案报价—商务谈判—赢单/输单”你可以根据自己公司的销售流程在后台配置中心把阶段名称换成你们的专业叫法。合同模块负责把成交结果固定下来记录合同编号、关联客户、合同金额、签约日期、回款计划。这里要特别提醒合同金额和回款计划的设计是和后续报表模块联动的。如果你想在报表里看到“本月回款金额”回款计划的字段就必须维护得规范否则报表就是白扯。我一般在自己项目里会再给合同表加一个“回款状态”字段方便在合同列表直接筛选哪些还没回款完。4.3 数据权限和角色权限——这个坑必须在一开始就设计好很多开源CRM的权限只做到“登录才能看”但到了实际业务中销售只能看自己的客户销售主管能看整个团队的客户老板能看全部客户。这套3.0的权限设计基本做到了“角色数据范围”两层控制。角色决定能点哪些菜单、操作哪些按钮数据范围决定客户列表中能看到谁的数据。权限这一块的二次开发是最需要谨慎的。我看到不少项目客户列表查出来全公司的客户都显示了问了之后才发现是角色分配的数据范围没有配置对。你在设计权限时最好画一张表格角色、可见数据范围、可操作权限、是否可转移负责人、是否可删除客户。把这些理清楚再去后台配置效率会高很多。4.4 报表和导出——老板真正关心的东西最后要说的模块是统计报表。系统自带客户总量、新增客户趋势、跟进次数统计、商机金额漏斗、合同签约金额等常用报表。老板通常不看系统操作界面直接看周报和月报所以报表模块的数据准确性很重要。这个模块是二次开发的重点区域很多公司会要求按月份、按团队、按产品线做多维统计把数据导出成Excel再加工。好在数据库表关系清晰写SQL统计并不困难后面我会专门讲一个改报表的案例。5. 首次动手改造给客户资料增加自定义字段并联动列表筛选5.1 加字段前的思路先想清楚“哪些需求真的需要字段”我见过不少拿到源码就加字段的人今天加一个“客户来源渠道”明天加一个“客户意向等级”后天加一个“客户行业”数据库表撑出二三十个字段大量字段录入的时候是空的列表页也没显示。这种改动叫“自嗨型二次开发”给自己制造维护负担。正确的做法是倒推先想清楚新增字段之后要在哪个界面展示、要不要参与列表筛选、要不要进报表统计、销售人员会不会愿意填。比如我想给客户表加一个“客户等级”字段用来区分普通客户、重要客户、核心客户实际价值是销售可以在客户列表按等级筛选优先跟进高等级客户。这个需求链路是通的加字段才有意义。5.2 数据库字段、后端、前端三层改动实操第一步在数据库加字段。我用的是MySQL命令行直接执行ALTER TABLE crm_customer ADD COLUMN customer_level TINYINT NOT NULL DEFAULT 0 COMMENT 客户等级0普通、1重要、2核心 AFTER customer_source;第二步改后端控制器和模型。这套3.0收表单数据的方法大多是直接把POST过来的数组传给模型比如public function save() { $data $this-request-post(); $model new CustomerModel(); if (isset($data[id]) $data[id] 0) { $model-update($data); } else { $model-create($data); } return json([code 0, msg 保存成功]); }这种情况下只要前端表单传了customer_level后端无需改动就能存进去听起来是不是很开心但别高兴太早如果控制器里做了字段白名单校验比如只允许写入name、phone、source这些字段那你就需要把customer_level加进允许列表里不然数据会静默丢掉。第三步改前端模板。在客户编辑表单里加一个下拉选择框div classform-group label客户等级/label select namecustomer_level classform-control option value0 {eq namedata.customer_level value0}selected{/eq}普通/option option value1 {eq namedata.customer_level value1}selected{/eq}重要/option option value2 {eq namedata.customer_level value2}selected{/eq}核心/option /select /div同时在客户列表页的筛选区域加一个下拉筛选框并把列表查询方法里加上对customer_level的条件判断。这一步如果后台查询是封装的方法你要看一下是直接拼where数组还是用原生query别改错地方。改完这三层之后先测添加、再测编辑、再测搜索、再测详情详情页展示一轮走完才算这个字段真正上线。6. 我踩过的坑二次开发时最容易被绊倒的四个细节6.1 表单提交了但数据没入库的完整排查链路这是我在做第一个改造时遇到的很典型。客户列表筛选功能加完之后发现点击搜索没有结果但我明明加了条件。后来仔细排查整个链路是这样的:前端请求有没有发出去浏览器F12打开Network确认筛选请求参数里带没带customer_level请求到达后端后PHP控制器有没有在接收参数我在控制器入口打日志发现参数收到了但列表查询方法里的where条件因为在字段前加了表前缀比如crm_customer.customer_level而拼SQL的时候用了不加前缀的字段名导致SQL报错找不到列。排查到最后发现问题出在我加字段的时候数据库列名用的是customer_level但模板里的name属性写成了customerLevel对不上。POST到后端自然没有这个键。这类问题在二次开发中特别常见因为前端习惯用驼峰命名后端和数据库习惯用下划线命名。我的建议是统一全部用下划线别在模板里玩花活。6.2 时间显示差8小时问题不在PHP代码系统跑起来后发现客户跟进记录里的时间比实际时间慢了8个小时。第一反应是PHP时区配置有问题但我检查了php.ini的date.timezone已经设置成Asia/Shanghaiphpinfo()也显示正常。后来查到了MySQL那边发现数据库连接的字符集和时区设置里time_zone是SYSTEM而系统时区是UTC导致数据库存的时间被转换了一次。解决办法是在MySQL连接配置里把时区设置成和PHP一致的时区。修改配置文件后执行SET time_zone 8:00;别忘了在MySQL的my.cnf里加一行default-time-zone 8:00重启MySQL后永久生效。这个问题不查到最后一步真的很难想到是数据库时区和系统时区不一致造成的。6.3 权限节点加了缓存改完角色不生效还有一次我在后台给某个角色新增了一个客户导出权限保存之后用那个角色的账号测试发现导出按钮还是灰的。一开始以为是权限判断逻辑写错了看了半天代码发现权限判断是从缓存里读的而角色权限保存时没有清掉缓存。后台设置里有一个“清除缓存”按钮点了之后权限才生效。在给客户做二次开发时凡是涉及权限、菜单、配置类的改动一定要记得在代码里加上清缓存的操作或者至少在上线文档里写清楚“修改权限后刷新缓存”。不然你交付给客户之后客户自己去配权限配完发现没变化就会觉得你的系统有Bug很冤。6.4 备份策略比二次开发功能更重要最后说一个很多人忽略的坑。每次改代码、改数据库字段之前一定要做好备份。我给自己定的规矩是改数据库之前先备份整个库改PHP文件之前先把原文件复制一份。动手改之前想清楚改挂了能回滚才不会慌。这套3.0系统我统计过数据库有几十张表代码文件几百个如果你改完一个功能导致另一处报错没有备份的情况下排查起来非常费时间。我的习惯是在正式做功能开发之前先给整个项目在服务器上打一个快照或者打包一份源码再导出一次完整SQL。这样不管是改崩了还是改到一半想推翻重来都能快速回到起点。二次开发最怕的不是慢而是改到一半没有回头路。这几轮实操下来我个人体会是开源CRM系统最大的价值不是省了那点采购费而是把业务的掌控权还给了你自己。客户系统这种天天要用的东西只有业务变了能跟着改才真正属于你。这套3.0版本虽然是老架构但胜在数据结构清晰、权限模型完整、无加密可自由折腾作为一套二次开发的底子比很多花架子系统实在得多。希望这篇踩坑和实操记录能帮你少走点弯路。本文还有配套的精品资源点击获取