企业官网建设流程全解析

简介：功能齐全的CRM客户管理系统旗舰版源码，面向需要搭建客户管理系统的中小企业和PHP开发者，提供一套涵盖线索、客户、商机、合同、财务、销售、采购、库存、产品、任务、日程、知识、日志、站内信、营销等十大模块和五小模块的完整程序。源码无加密、无域名限制，支持自由二次开发，可自定义字段、审批流程和进销存流程，帮助企业跟踪市场、销售、采购、库存及售后全周期，提升客户满意度。压缩包采用rar格式，大小仅11.53MB，自带数据库导入安装，便于快速部署；该自用版本还调整了若干实用字段与单据显示，更适合实际业务使用。与网上免费版相比，新增了报价单快捷生成合同、合同自动生成应收款与出库单、库存流水账等实用功能，并优化了权限、审批统计、知识分类等体验，修复了导出和地址搜索等已知问题。目前已有2907人学习下载，适合希望深度定制CRM系统的团队参考使用。

1. 功能齐全的CRM客户管理系统源代码：这到底是什么、谁能直接用

很多销售团队买过或下载过所谓的“旗舰版”CRM客户管理系统源代码，结果打开压缩包就傻眼：几十个文件夹、几百个PHP文件、一堆没见过的类名，连入口在哪都找不到。这不是你能力不行，而是这套代码默认就要求你具备一套完整的技术环境，否则入口再多也白搭。这篇笔记要解决的问题，就是把这套代码从压缩包里搬到服务器上，讲清楚跑通它的最小命令、看懂它功能架构的读码顺序，以及改动和上线时最常踩的坑。适合两类人：一类是小团队的技术负责人，想把CRM接进自己的业务；另一类是接单改造CRM系统的外包开发，需要快速入局。免费CRM和私人网站的区别就在这：线下源码归你所有，能改能换服务器，但代价是部署、维护、安全都得自己扛。

2. 跑通CRM源代码：本机环境选型与最小启动命令

2.1 先分技术栈：PHP系还是Java前后端分离

拿到源码第一步不是急着配数据库，而是确认它的技术栈。常见的CRM客户管理系统源代码有两条主流路线：老一点的商用旗舰版多是PHP加MySQL，用ThinkPHP、Laravel框架，入口在public/index.php；新一点的会做成Java Spring Boot加Vue前后端分离，前端依赖node_modules，后端依赖Maven。这两类的跑法完全不同，认错方向会在环境准备阶段翻车。

我一般会先执行下面这组命令：

# 解压后先看根目录，别急着双击 index.php ls -la cat composer.json 2>/dev/null | head -40 ls -la vendor/ 2>/dev/null | head -5 ls -la pom.xml 2>/dev/null

有composer.json和vendor目录，基本可以确定是PHP系；有pom.xml加src/main/java就是Java Spring Boot。再看一眼有没有独立的子目录放前端，比如web、vue-web、uniapp这类，如果有说明是前后端分离，前端还要单独执行npm的构建命令。

这里有个实际经验：很多所谓“旗舰版”源码并不干净，根目录会混着备份文件、测试数据和开发者的个人配置。看到backup.sql、config.bak.php这类文件，先别删，复制到旁边留个底，等看明白再处理。它们往往记录了远程数据库地址或固定上传目录的路径，会直接影响本地能不能启动。

2.2 最小启动命令：建库、改配置、配伪静态、清运行时

判断完技术栈后，PHP这套的最小启动路径一般是三条：导入数据库、改数据库连接、配伪静态并指定运行目录。以常见的ThinkPHP系CRM为例，先建立一个空库：

mysql -uroot -p -e "CREATE DATABASE crm_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;" mysql -uroot -p crm_db < install/crm.sql

install/crm.sql一般位于源码包的安装目录，也可能是根目录下的crm.sql或data.sql。如果找不到，用find命令搜一下：

find . -maxdepth 3 \( -name "*.sql" -o -name "*.zip" \) -type f

-maxdepth 3限制搜索深度，避免把整个服务器翻个底朝天；同时找zip是因为有些源码把初始数据库单独打了一个包，需要先解压。

数据库导入后，打开连接配置。ThinkPHP系通常在.env或config/database.php，Laravel系在.env，原生PHP在config.php、conn.php这类文件里。要改的参数是host、username、password，数据库名对应crm_db。改完之后不是直接访问根目录，而是让Web服务器把入口指到public目录，并把所有未命中路径重写到index.php。

Nginx下我看过的典型配置是这样：

server { listen 80; server_name crm.local; root /data/www/crm/public; index index.php; location / { try_files $uri $uri/ /index.php?s=$uri$args; } location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } }

关键参数是try_files里/index.php?s=$uri$args，这是ThinkPHP兼容PATH_INFO的写法。换成Laravel要把?s=去掉，写成/index.php?$query_string。很多项目本地跑不通，问题不在PHP版本，而是没配伪静态：页面能打开，一点菜单就跳回首页。Apache环境则要开mod_rewrite，并在public下放.htaccess，源码里通常会带，缺了可以自己补。

配完伪静态还有个容易漏的步骤：清理runtime缓存目录。开发者的本地环境可能和你的PHP版本不一致，runtime里残留的缓存会直接让你看到“模板不存在”的报错。

rm -rf runtime/* cache/* 2>/dev/null chmod -R 755 runtime upload

runtime给755是多数PHP框架的正常需求，upload目录如果程序要写文件，可能要给到775甚至777，具体看运行用户是谁。

2.3 首次登录账号：初始化数据与默认密码查询

数据库导入成功不等于有账号可以登录。旗舰版CRM通常有两类初始化方式：一类是install.sql里直接插入了admin管理员，密码是明显弱密码如admin123、123456；另一类是首次访问install.php体验安装流程，在界面上设置管理员邮箱和密码。

遇到第一种情况，不要在页面上乱试密码把账号锁了，直接在数据库里重置。先看用户表结构：

SHOW COLUMNS FROM crm_user; SELECT username, password, salt FROM crm_user WHERE username = 'admin';

重点看password和salt字段的长度和格式。长度32位一般是MD5，长度60位以上通常是password_hash。不同源码的加密规则不一样，抄网上SQL前必须看控制器里的登录方法。

与其猜加密规则，不如直接用服务端脚本走一遍：

// reset_pwd.php 临时脚本，验证成功后立即删除 $user = M('user')->where(['username' => 'admin'])->find(); $newPwd = 'Admin@123'; // 以下按常见 md5(md5(明文) . salt) 规则演示，实际以 LoginController 为准 $encPwd = md5(md5($newPwd) . $user['salt']); M('user')->where(['id' => $user['id']])->save(['password' => $encPwd]); echo '密码已重置为: ', $newPwd;

这段PHP脚本是临时工具，登录成功之后必须把它从项目里删掉，不然它会变成公网上的一个重置密码入口，性质跟后门一样。首次登录后第一件事是清理默认账号，把install目录整个改名或限制访问。我见过不止一次，项目上线了，install目录还在，别人访问install.php就能重装系统，把整库数据清掉。

提示：密码别用admin123这类弱口令，也别写在README里交付。销售团队的人会到处转发文档，你写上的密码很快就会传遍全公司。

3. 看懂“旗舰版”CRM的功能结构：从菜单表反推模块与权限模型

3.1 菜单表是所有功能入口：把模块清单先读出来

一套“功能齐全”的旗舰版CRM，单看目录结构根本看不出名堂。我的读码习惯是先去数据库找菜单表。名字常见为menu、sys_menu、admin_menu。这张表是整个系统的功能地图，记录着菜单名、路由地址、上级菜单、排序、权限标识。把它按层级查出来，等于拿到一张完整的模块清单。

SELECT id, parent_id, name, route, order_num, perms FROM sys_menu WHERE status = 1 ORDER BY parent_id ASC, order_num ASC;

基于这张表，你能立刻看清它包含哪些模块：客户管理、联系人、商机、合同、回款、跟进记录、工单、日程、报表、系统设置。如果里面还出现销售目标、团队排行、审批流，说明确实够“旗舰”。拿到这张清单后再回去翻代码文件，效率会高很多，因为源码文件目录的命名基本与菜单的route一一对应。

有的源码不叫menu，叫auth_rule，这类通常是权限规则表，字段里有type区分菜单目录、菜单页面和操作按钮。遇到这种情况，加上type过滤条件，只选菜单类型的记录，否则会把几百个按钮权限混在一起，看得头大。

3.2 主键链路：客户、联系人、商机、合同怎么关联

功能齐全意味着业务表之间有关联。新手拿到CRM源码最容易迷失在几十张表里，不知道先看哪几张。我的建议是从客户表开始，把主键链路读出来：客户表是主表，联系人、商机、合同、跟进记录都通过customer_id挂靠。这条线理清楚后，后面改任何页面都能快速定位对应表和字段。

典型关系查询如下：

SELECT c.id AS customer_id, c.name AS 客户名称, ck.name AS 联系人, b.title AS 商机, ct.contract_no AS 合同号, ck.phone FROM crm_customer c LEFT JOIN crm_contact ck ON ck.customer_id = c.id LEFT JOIN crm_business b ON b.customer_id = c.id LEFT JOIN crm_contract ct ON ct.customer_id = c.id WHERE c.id = 1;

这里要注意表名前缀。不同源码的默认前缀不一样，常见的有crm_、tp_、sys_。先执行SHOW TABLES;看一遍实际存在的表名，再改写这个SQL，不然会白报错。查询结果如果rows很多，说明这是一套主从结构，商机和合同都是可重复的独立实体；如果商机表里还挂了stage字段，再往下看，它对应着销售漏斗阶段。

还要补一个反例：有些旗舰版源码把客户和联系人合并成一张表，用type字段区分。这种结构不是错，只是定制字段时要注意，给“客户”加字段等于给“联系人”也加了一遍。判断方式很简单：看有没有单独的contact表。没有，就按合并表来改。

3.3 权限模型：角色、菜单、数据范围三张表怎么串

旗舰版和大路货拉开差距的地方在权限。功能齐全的CRM，权限至少分两层：菜单权限和数据权限。菜单权限决定你能看到哪些页面，数据权限决定你能看到哪些客户。后一种最容易被忽略，也最容易造成越权。

先看关联关系：

-- 角色和菜单的关联 SELECT * FROM sys_role_menu WHERE role_id = 1; -- 用户和角色关联 SELECT * FROM sys_user_role WHERE user_id = 1; -- 数据权限典型的字段：data_scope SHOW COLUMNS FROM sys_role;

data_scope字段我见过三种取值：1全部、2仅本部门、3仅本人。如果这套源码里有这个字段，说明它自带数据权限引擎，改权限时要同时改角色和用户，不能只改菜单勾选。如果没这个字段，就只做菜单权限，要升级成“数据级权限”得自己在查询SQL里加WHERE条件按部门过滤，这一步是改造CRM系统的常见翻车点。

读到这里也就明白了：旗舰版CRM的“旗舰”不在代码写得有多花哨，而在于这些表和字段的存在。阅读顺序反了，先去读加密类、验证码类这些底层工具，一头扎进去，几周都绕不出来。血泪经验：先库后码，先菜单后路由。

4. 按业务改一套CRM：加字段、改跟进、出看板的完整改造顺序

4.1 改造顺序：先数据字典，再框架同步，最后动表单

很多开发拿到代码就急着改模板，结果数据库漏加字段，前端报错一屏。我自己改造CRM系统总结下来的顺序永远是：数据库先加，框架层同步，表单最后动。这么做的好处是任何一步出错都能定位，不会出现“页面上多了个输入框但保存丢数据”这种半残状态。

旗舰版CRM一般把字段定义放在两个地方：一个是业务实体表本身，比如crm_customer的列；另一个是自定义字段表，常见名crm_field_config。支持自定义字段的版本，后台“字段管理”里看到的配置就存在这张表里，改的是元数据，不动表结构。如果只改了后台字段名，没同步数据库列，保存时SQL就会报错。

所以第一件事是确认这套源码是否支持自定义字段：

SHOW TABLES LIKE '%field%'; SELECT * FROM crm_field_config LIMIT 10;

有这张表说明改造主力在配置，没有就要直接ALTER TABLE。大部分“旗舰版”介于两者之间：默认字段写死，但预置了扩展表。

4.2 加“行业分类”字段：ALTER TABLE、字典与下拉框联动

假设业务方要在客户列表加一个下拉框“行业分类”，取值包括制造、软件、金融、医疗。先给表加列，再加字典或下拉配置，最后改模板。

ALTER TABLE crm_customer ADD COLUMN industry VARCHAR(32) NOT NULL DEFAULT '' COMMENT '行业分类' AFTER customer_type;

如果源码带字典表，顺手再插入一条dict数据：

INSERT INTO sys_dict_data(dict_type, dict_label, dict_value, sort) VALUES ('industry', '制造', 'manufacturing', 1), ('industry', '软件', 'software', 2), ('industry', '金融', 'finance', 3), ('industry', '医疗', 'medical', 4);

AFTER customer_type这个位置要看你刚查的表结构，没有customer_type列就把AFTER去掉。字段类型用VARCHAR还是TINYINT？我的建议是字典类的字段用VARCHAR存英文标识，不要存数字ID。原因很简单：导出Excel给业务看的时候，显示的是“软件”而不是“3”，省去二次加工的工单，同时也降低了两套环境的字典同步成本。

改完表和字典后，去前端模板。老式PHP模板在对应的form.html里加一行下拉框，新式vue前端在src/views/customer/form.vue里加el-select。手写HTML的更直接：

<div class="form-group"> <label>行业分类</label> <select name="industry" class="form-control"> <option value="">请选择</option> <option value="manufacturing">制造</option> <option value="software">软件</option> <option value="finance">金融</option> <option value="medical">医疗</option> </select> </div>

保存时后端控制器一般不需要改：只要字段名匹配，验证规则里加一条industry的in校验即可。要找到验证规则，搜controller类里validate方法。加校验的目的是防止绕过页面直接POST非法值，真实业务里会有人在调试工具里提交超长字符串，你挡一层少一层麻烦。

4.3 看板统计：跟进记录按状态聚合的SQL与接口

功能齐全的CRM通常都带销售看板。老板想看的不是记录明细，而是“今天哪些客户要跟进”“本周商机赢率如何”。如果源码里的看板不满足需求，自己加一个聚合查询最实在。

跟进记录表常见结构是crm_follow_log，字段包括customer_id、content、next_time、admin_id、status。统计“各销售今日需跟进客户数”的SQL：

SELECT a.realname AS 销售, COUNT(f.id) AS 待跟进数 FROM crm_follow_log f JOIN crm_user a ON a.id = f.admin_id WHERE DATE(f.next_time) = CURRENT_DATE() AND f.status = 0 GROUP BY a.id ORDER BY 待跟进数 DESC;

这里的status含义要翻字典确认。0可能代表未处理，也可能代表正常。跑之前先SELECT DISTINCT status;看一下到底有几种值。跟进的next_time字段同时要确认是datetime还是时间戳，时间戳要改用FROM_UNIXTIME(f.next_time)包裹查询。

接口层如果是ThinkPHP，在控制器里加一个public function todayStat()，调用这个SQL并返回json。前端用表格或ECharts图表直接拉取。这里有个细节：聚合SQL的别名“待跟进数”用于ORDER BY在MySQL 8.0里正常，但如果目标环境跟开发库版本不一致，导出的脚本里中文别名会有兼容性风险，导出Excel的列名最好用英文字段名，中文留给画面显示。

改造到此，你已经完成了从数据层到展示层的完整闭环：字典先行、字段同步、接口兜底。下一次业务方再提“能不能加一个客户所属区域”的需求，你按同样顺序十分钟内完事。

5. CRM上线避坑：最容易翻车的五个环节与排查清单

5.1 登录白屏或报500：先开错误显示，再定位缺扩展

现象：部署完成后访问首页正常，一登录就白屏或抛出PHP Warning。

原因：runtime目录没有写权限、PHP版本太高触发旧框架废弃函数报错，或者PHP fileinfo、curl扩展没开。

解决：先把错误显示打开，别在没报错信息的情况下猜代码。

# 临时开启显示错误，排查用，线上记得关闭 php -i | grep error_log tail -f runtime/log/*.log

在PHP入口index.php加两行临时开关：

error_reporting(E_ALL); ini_set('display_errors', '1');

改完再登录一次，真正报错会直接打在页面上。最常见的三种报错：Call to undefined function curl_init，是缺php-curl扩展；Class 'PDO' not found，是缺pdo_mysql；OpenSSL不支持，是php.ini里extension=openssl没打开。线上排查完后，这两个配置要倒回去，display_errors设0，不要留。

注意：display_errors在正式环境必须关，否则数据库连接信息、绝对路径都会跟着报错一起吐给访问者，这是信息泄露。

5.2 中文乱码：库、表、连接三处字符集必须统一

现象：新客户输入的中文姓名保存后变成问号，或者Excel导入的数据全是乱码。

原因：MySQL库的默认字符集、表的字符集、连接字符集三个地方不一致。最常见的情况是库是utf8mb4，表是latin1，连接又走utf8。

解决：统一成utf8mb4，一处都不能漏。

ALTER DATABASE crm_db CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; ALTER TABLE crm_customer CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

代码里连接参数也要改。PHP的MySQLi连接后执行：

mysqli_set_charset($conn, 'utf8mb4');

PDO则在DSN里加charset=utf8mb4。网上很多教程只说改库和表，忽略了连接字符集，这就是为什么有人改了库还乱码。老项目里如果库和表已经是utf8mb4但页面还是乱，检查HTTP响应头有没有把页面输出声明成UTF-8，多半是模板文件头部meta标签缺失或被改过。

5.3 跟进提醒不触发：定时任务没配，等于永久在线是空话

现象：设置了今天要跟进的客户，CRM却从来不推送提醒。销售会觉得产品“不够智能”。

原因：源码里的提醒依赖Linux的crontab或Windows计划任务，而你没配，或者配了但路径不对。用户以为CRM是个永久在线的网站，提醒理应自动出现；实际上提醒是靠后台定时任务在跑，没配就等于没有。

解决分两步：先确认任务在跑，再去看队列或消息日志。

crontab -l # 常见命令类似 */5 * * * * /usr/bin/php /data/www/crm/public/index.php cron/run

如果cron里已经有记录但提醒还是没发，多半是cron/run这个路由在前置伪静态的影响下无法从命令行访问。命令行下绕开伪静态直接指定入口文件，或者干脆写一个shell脚本curl访问URL。这一步的坑在于：它和登录界面看起来无关，部署当天根本测不出来，跑一天才发现压根没进消息队列。

5.4 权限越权：菜单权限不等于数据权限

现象：销售主管能看到别人的客户，普通销售也能看到全公司的客户。

原因：源码只做了菜单和按钮级权限，没做数据级权限，或者做了但配置没生效。管理员在后台勾选了角色菜单，以为就完事了。

解决：先定位角色表的data_scope：

SELECT role_name, data_scope FROM sys_role;

把销售角色的data_scope改成3（仅本人），然后检查客户列表的查询控制器，看看有没有真正把scope条件拼到SQL里。有些源码只在前端隐藏了“全部客户”按钮，后端接口不加条件，用调试工具直接POST就能拿到别人客户数据。这是功能齐全CRM最底线的安全要求，上线前必须亲手测一遍：用两个不同部门的测试账号互相看对方客户列表，能看见就说明数据权限没生效。

5.5 并发压测：登录接口和客户列表各打一轮

现象：正式上线后，销售一早集中登录，页面卡死，转圈几秒才出来。

原因：开发环境单用户测试正常，但PHP-FPM进程数和MySQL的max_connections撑不住集中访问。

解决：上线前用ab做一轮压测，心里有底。

ab -n 200 -c 20 -p login_post.txt -T 'application/x-www-form-urlencoded' http://crm.example.com/index.php/login

参数说明：-n总请求数200，-c并发20，-p指定POST请求体文件，login_post.txt里存好username=admin&password=xxx。看两个核心结果：Failed Requests为0，Requests per second不低于预期。再用同样的方法压一次客户列表。如果失败率10%以上，优先看PHP-FPM的pm.max_children和MySQL最大连接数，而不是互相猜代码有问题。压测完之后给客户列表常用查询条件加组合索引，比如(customer_id, status)，压测效果立竿见影。

6. 换服务器迁数据：CRM系统完整迁移的实操顺序与验证方法

6.1 导出前先停写操作，保证一致性快照

迁移最常见的错误是直接在运行中的CRM上mysqldump，拷到新机器后商机、合同对不上账。我吃过这种亏。不管项目是基于这套源码自研，还是你在评估Microsoft Dynamics CRM这类本地部署方案，导库、搬代码、按业务路径验证这三步都逃不掉。

systemctl stop php-fpm # 或停Nginx，让外部不再写入 mysqldump -uroot -p --single-transaction --routines --triggers crm_db > crm_db_full.sql

mysqldump的--single-transaction对InnoDB表可以做一致性快照，不需要锁表很久。但如果表是MyISAM，这个参数无效，必须停写后再导。导出之后把代码目录一并拷走：

rsync -avz /data/www/crm/ root@新服务器:/data/www/crm/

rsync的-a保留权限，-v显示过程，-z压缩传输。目录里如果有runtime缓存，建议先清掉再同步，上传目录upload要单独保留。

6.2 迁移后按业务路径做三轮验证

导入到新库并改完配置后，别急着让大家用。按业务路径验证三轮。第一轮登录链路：管理员登录、改密码、退出。第二轮数据链路：客户详情、联系人、商机和合同是否串得上：

SELECT c.id, (SELECT COUNT(*) FROM crm_contact k WHERE k.customer_id = c.id) AS 联系人数 FROM crm_customer c ORDER BY c.id DESC LIMIT 50;

第三轮按销售漏斗走一遍：新建客户、录入跟进、创建商机、关联合同、提交回款。这一步能同时验证路由、上传、权限和字段完整性，比跑一百条自动化用例都可靠。我现在的习惯是迁移完打印一份核对清单，逐项打勾，页面响应时间、附件下载、导入导出各测一条，宁可多花半小时，也不要在上线后第二天接到老板电话说回款记录少了一半。希望帮到你。

本文还有配套的精品资源，点击获取