自建轻量CRM系统实战：Flask+MySQL实现客户管理与权限控制-育师

1. 项目起源与核心需求拆解

1.1 为什么放弃现成CRM，选择自建一套

先说背景。我所在的团队大概七八个人，一直靠共享Excel表格和微信群里翻聊天记录来管客户，客户信息散落在各人电脑里，谁跟进到哪一步全靠问。后来客户到了四五十个，明显感觉撑不住了，想上CRM，但看了一圈市面上的产品，要么按坐席收费一年下来成本不低，要么一些所谓“永久免费”的版本在人数、数据量、自定义字段上设了一堆暗门槛。于是动了自建一个内部CRM的念头，项目代号就叫DeskcommCRM。

DeskcommCRM要解决的痛点很明确：把客户资料、跟进记录、待办任务、销售漏斗统一到一个可以随时随地访问的Web系统里，让每个人登录后台就能看到自己名下客户的全貌，同时管理层能看整体数据。这不是一个要从零发明轮子的项目，而是要用最省事的方式，把一个稳定可靠的CRM跑起来。

考虑到团队不是专业开发人员，我自己也只是懂一些Python和服务器运维的偏门经验，所以技术选型上刻意避开了重框架、重架构的路线。这里想清楚了一个核心原则：CRM的灵魂是数据结构和服务可用性，不是技术栈多么炫酷。哪怕界面朴素一点，只要客户资料不丢、字段能自定义、多人能同时用，就已经赢过了市面上大部分“试用期结束就冻结数据”的免费SaaS。

在这个阶段，我做了两类产品的详细对比，也给跟我一样在纠结“到底是买现成还是自己搞”的朋友一个参考：

对比维度	付费SaaS CRM	免费/开源CRM	自建轻量CRM（本项目）
初期成本	按年付费，中小团队也有压力	部分免费但高级功能收费	仅服务器成本
数据归属	在厂商服务器上	在厂商服务器上	完全自有
自定义能力	受产品限制，改字段常要加钱	受版本限制	完全可控
维护成本	不用管	不用管	需要自己维护（2-4小时/月）
永久在线	依赖厂商策略	免费版可能有访问限制	服务器不关就一直在线

1.2 核心用户画像与功能边界

真正动手之前，先画了用户画像。DeskcommCRM最核心的使用者是两类人：

第一类是销售/客户经理，他们每天要查询客户资料、记录跟进电话或拜访内容、新增客户、领取待办任务。他们的诉求是“快”，打开系统到找到客户信息，最好三秒以内完成，记录跟进像发微博一样简单。第二类是团队负责人，要看到每个销售的客户数量、跟进频率、商机金额和最近动态，判断哪些客户可能流失、哪些跟进该提醒了。

明确了使用者之后，功能边界就非常清晰了：客户档案、跟进记录、任务提醒、销售漏斗统计、团队成员与权限管理。一开始没有做复杂的工单系统或营销自动化，因为那会让自己陷入开发泥潭。项目目标是两周内上线可用版本，一个月内通过实际使用反馈迭代出符合团队习惯的形态。

这也回应了一个很多人问我的问题：免费CRM和私人网站/私人部署的区别到底在哪？区别在于“你拥有什么”。免费CRM的厂商随时可以调整免费策略，你的数据迁移成本极高，而私人部署的CRM，它的数据、接口、字段、权限都完完全全掌握在自己手里。付出的代价就是服务器费用和维护精力，但换来的是一套真正属于团队的“永久在线”系统。

2. 技术选型与整体架构设计

2.1 技术栈选择的底层逻辑

DeskcommCRM的技术栈非常朴素，但每一样都是经过测试的稳定组合：

后端：Python Flask（轻量、上手快、插件生态够用）
数据库：MySQL 8.x（也可以替换成PostgreSQL，二选一即可）
前端：Bootstrap 5 + Jinja2模板（不搞前后端分离，减少开发和部署复杂度）
部署：Nginx + Gunicorn + systemd（保证进程守护和开机自启）
缓存/会话：Redis（用于session共享，后续如果扩展多节点也方便）

选Flask而不是Django的原因很简单。Django自带Admin后台、ORM、迁移工具，功能很全，但对一个小团队内部系统来说有些笨重；Flask可以把代码组织得更加轻快，路由直观，模型层用SQLAlchemy也一样顺手。还有一个考量是团队里有同事想参与二开，Flask的学习曲线比Django平缓不少。

有人可能会问：为什么不用现成的开源CRM，比如SuiteCRM、EspoCRM、Odoo？这些确实是成熟方案，安装即用。但我需要的是一个完全贴合销售流程的系统，开源产品往往预设了一堆用不上的模块，自定义字段和表单逻辑的学习成本反而比从零写一个更高。而且从维护角度说，自己写的系统，遇到问题能直接改代码，不需要去翻第三方文档和社区求助。

2.2 数据模型设计实战

整个系统的核心是数据表结构，这一步决定了后续所有功能的开发效率。我花了一整天画表和关系，踩过的坑包括：客户和联系人的关系不够清晰、跟进记录和任务的字段设计得过于冗余等。最终稳定下来的核心表如下：

customers（客户表）

id：主键
name：客户名称/公司名
industry：所属行业
source：客户来源（展会、转介绍、线上广告等）
level：客户等级（A/B/C/D）
owner_id：负责人ID
phone、email、address等联系方式
remark：备注
created_at、updated_at：时间戳

contacts（联系人表）

id、customer_id（外键关联客户）
name、position、phone、wechat
is_primary：是否主要联系人

follow_ups（跟进记录表）

id、customer_id、contact_id（可选）
content：跟进内容
next_plan：下一步计划
follow_type：跟进方式（电话/拜访/邮件等）
creator_id、created_at

tasks（任务表）

id、customer_id、title、description
due_date：截止时间
status：待办/已完成/已取消
assignee_id：执行人
creator_id、created_at

users（用户表）

id、username、password_hash、real_name
role：admin/manager/member，role在权限判断里非常关键
is_active、last_login_at

字段设计上有一个很重要的经验：客户等级和合作状态这类枚举字段，一定要用代码维护一个config表或Python枚举类，不要直接在数据库里散落各种值。否则半年后你会发现数据里出现了“A级”“A”“a+”三种写法，统计口径彻底乱掉。

2.3 永久在线的部署架构

“永久在线”是DeskcommCRM被问到最多的一个点。这其实是个部署架构问题，而不只是代码问题。我的部署方案直接采用云服务器 + systemd守护进程 + 域名HTTPS。

云服务器选择上，2核2G内存的入门机型就够用了，操作系统用Ubuntu 22.04 LTS。这个规格承载一个每天几十人访问的内部系统绰绰有余。价格方面，国内主流云厂商新用户活动价一年大概几百块，比付费CRM便宜太多。

进程守护是“永久在线”的关键。用systemd管理Gunicorn进程，设置Restart=always，这样即使代码bug导致进程崩溃，systemd也会在三秒内自动拉起服务。同时用logrotate做日志轮转，防止日志文件把磁盘塞满。

对于外网访问，如果有公网IP，直接解析域名到服务器，再用certbot申请Let's Encrypt证书启用HTTPS即可。如果没有公网IP，也可以用内网穿透工具——但那是另一个话题，我觉得既然要做一个正式的内部管理系统，还是建议直接上云服务器，稳定性和安全性都在可控范围内。

3. 核心功能模块与实现细节

3.1 客户管理模块的实现重点

客户管理模块是DeskcommCRM最核心的部分，它要解决的是“客户档案从分散到统一”的问题。实现上做了三件事：

第一，客户列表的分页和筛选。列表页支持按负责人、客户等级、来源、关键字搜索，全部通过SQLAlchemy的动态查询实现。这里一定要在owner_id和created_at上加索引，否则客户数据过千之后列表查询会肉眼可见地变慢。我实际测试过，不加索引时两千条数据查询要三四秒，加上复合索引之后直接降到几十毫秒。

第二，客户详情页的时间线设计。点进一个客户，能看到这个客户从建立档案开始的所有跟进记录、历史任务、资料修改日志。这个设计让新人接手客户时能快速了解来龙去脉，不用再翻聊天记录。跟进记录的富文本框我用的是Contenteditable+plain text保存，没有上富文本编辑器，因为销售们写跟进记录就是要快，格式反而不重要。

第三，客户去重。这个容易被忽略。Excel时代常见的问题是同一个客户被录入两次，导致统计口径混乱。我在新建客户时做了重名校验，如果名称相似度超过85%，就提示是否合并。实现上用了一个简单的方式，先查完全同名，再查去掉空格和特殊符号后的同名校验，没有上模糊匹配算法，效果也已经够用了。

3.2 跟进记录与任务提醒的联动逻辑

跟进记录和任务不是孤立的功能模块，它们之间要有联动。我在设计时定了一条规则：写跟进记录时可以顺便创建下一步任务，任务到时自动提醒。比如销售给客户打完电话，在跟进内容里写“对方对报价单有兴趣，下周三前给出优惠方案”，这时候系统会提取并让用户确认是否创建一个“给客户发送优惠方案”的任务，截止时间默认是下周三。

这个设计极大提升了销售的使用意愿。他们不用单独跑去任务模块新建任务，在记录跟进的场景里就顺手把后续动作安排好了，实际用下来任务创建率提升了将近一倍。

任务的提醒方式，我做了站内消息和邮件提醒两种。站内消息是一登录就能看到的待办清单；邮件提醒则是每天上午九点把当天到期和逾期的任务汇总发到用户邮箱。服务器上配了一个crontab定时任务，调Flask的CLI命令发送邮件提醒，没有引入Celery这样的重型队列框架。

3.3 员工邀请与权限管理的实操方案

热词里提到的“飞鱼CRM怎么邀请员工”，本质就是多用户系统的团队管理功能。这一点DeskcommCRM实现得比较细致，我把完整的员工邀请和权限管理流程分享出来。

邀请员工流程：

第一步：管理员在后台点击“添加成员”，输入对方邮箱或手机号。
第二步：系统生成一条带token的邀请链接，有效期为24小时，同时向邮箱发送邮件或在手机端显示邀请码。
第三步：被邀请人打开链接，设置自己的登录密码，即完成注册并自动关联到团队。
第四步：管理员在成员列表里为其分配角色（admin/manager/member）和默认数据权限范围。

权限管理的粒度：

admin：拥有系统全部权限，包括成员管理、参数配置、数据删除。
manager：可以查看团队内所有客户数据，能分配和转移客户，不能修改系统设置和删除成员。
member：只能看到自己名下及被共享给自己的客户，不能查看他人客户列表。

代码层面用装饰器实现权限控制，在Flask里写了一个login_required和role_required装饰器。每个路由上标注允许的角色，比如@role_required('admin', 'manager')，未授权访问直接返回403页面。这个方案在代码维护上非常直观，新加一个功能时，只需在路由上加装饰器就能完成权限控制。

实际操作中遇到的坑：邀请链接的token一定要设置过期时间并做单次使用校验，否则拿链接的人可能反复用它注册出多个僵尸账号。还建议记录邀请人的ID，团队审计时能追溯是谁拉进来的成员。

3.4 销售漏斗与统计看板

光记录数据不产出洞察，系统就没有灵魂。统计看板模块做了三个核心视图：

第一个是销售漏斗图，按客户等级和商机阶段统计金额。我在customers表里加了一个deal_amount字段和一个stage字段，stage表示当前商机阶段（初步接触/方案确认/商务谈判/已成交）。漏斗图用纯前端绘制，基于ECharts的funnel类型，数据由后端API返回JSON格式。这里注意不要在ORM查询后直接传给前端，要转换成前端友好的结构，比如{'stage': '方案确认', 'count': 12, 'amount': 300000}。

第二个是个人绩效看板。每个销售登录后第一眼看到的就是自己的本周跟进次数、新增客户数、待办任务数、本月成交金额。这些数据用简单的SQL聚合查询即可，关键在于日期范围的判断。我用的是Python的datetime模块计算本周起始日（周一）和截止日，SQLAlchemy查询时加created_at >= week_start即可避免时区问题。

第三个是客户动态预警。如果某客户的跟进记录超过15天没有新增，系统就自动标记为“沉寂客户”，提醒负责人主动回访。这个逻辑用定时任务扫描，导入一个函数update_inactive_flags()，每天凌晨执行一次。将预警结果写入customers表的一个is_inactive字段，并在列表页用红色高亮展示。这样管理层不用每天翻数据，系统主动告诉你要关注谁。

4. 实操部署全流程记录

4.1 服务器初始化与环境准备

部署部分我给出一版从零开始的完整流程，跟着做就能跑起来。假设你有一台Ubuntu 22.04的云服务器，SSH能连上。

# 更新系统 sudo apt update && sudo apt upgrade -y # 安装Python和数据库 sudo apt install -y python3-pip python3-venv mysql-server nginx sudo mysql_secure_installation # 创建数据库和专用用户 sudo mysql CREATE DATABASE deskcomm_crm DEFAULT CHARACTER SET utf8mb4; CREATE USER 'crm_user'@'localhost' IDENTIFIED BY '你的强密码'; GRANT ALL PRIVILEGES ON deskcomm_crm.* TO 'crm_user'@'localhost'; FLUSH PRIVILEGES; EXIT;

这里为什么用utf8mb4而不是utf8？因为MySQL的utf8最多只支持3字节字符，像emoji和生僻字会被截断或报错。既然系统里客户备注和人名都有可能出现特殊字符，直接用utf8mb4一劳永逸。数据库用户名和密码一定要用强密码，这个数据库里有你的客户资料，泄露了后果很严重。

4.2 应用部署与Nginx反向代理配置

项目代码上传到服务器后，使用虚拟环境安装依赖：

cd /opt/deskcomm-crm python3 -m venv venv source venv/bin/activate pip install -r requirements.txt # 初始化数据库 flask db upgrade flask init-data # 创建初始管理员账号

Gunicorn作为应用服务器，直接命令行启动测试一下能否正常运行：

gunicorn -w 3 -b 127.0.0.1:8000 "app:create_app()"

能跑通之后把它写成systemd服务，保证持久化运行：

[Unit] Description=DeskcommCRM Gunicorn Service After=network.target [Service] User=www-data Group=www-data WorkingDirectory=/opt/deskcomm-crm Environment="PATH=/opt/deskcomm-crm/venv/bin" ExecStart=/opt/deskcomm-crm/venv/bin/gunicorn -w 3 -b 127.0.0.1:8000 "app:create_app()" Restart=always RestartSec=3 [Install] WantedBy=multi-user.target

注意Restart=always是为什么要强调？因为你永远不知道代码什么时候会写了一个隐藏bug，进程说崩就崩。有了systemd守护，即使半夜两点崩溃了，它也能在无人值守的情况下自动恢复，这是“永久在线”的第一道保险。

Nginx配置反向代理加HTTPS：

server { listen 80; server_name crm.example.com; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }

然后用certbot一键签发续期HTTPS证书：

sudo apt install -y certbot python3-certbot-nginx sudo certbot --nginx -d crm.example.com

这里解决的就是免费CRM与私人网站的核心差异之一：私人部署后只要服务器在线、SSL证书在有效期内、进程有守护，你的CRM就是永久在线的，任何时间登录都能用，不会有免费版SaaS的“试用到期”“连接超时”“等待审核”这类问题。

4.3 定时备份与灾难恢复方案

客户数据是CRM里最值钱的部分，备份的问题一定不能省。我写了一个备份脚本放在/etc/cron.daily/backup_crm.sh，每天凌晨3点执行：

#!/bin/bash BACKUP_DIR=/data/backups/crm DATE=$(date +%Y%m%d_%H%M%S) mkdir -p $BACKUP_DIR mysqldump -u crm_user -p'密码' deskcomm_crm | gzip > $BACKUP_DIR/crm_$DATE.sql.gz # 保留最近30天的备份 find $BACKUP_DIR -name "*.sql.gz" -mtime +30 -delete

脚本内容很简单，但价值极高。我建议除了本机备份之外，定期把备份文件同步到另一台服务器或对象存储，防止服务器本身硬件故障把备份一起带走。这个可以用rclone配合对象存储或者网盘实现，Linux自带的rsync也可以。迁移恢复时，只需要在新服务器上建好数据库，然后执行：

gunzip < crm_20250101_000000.sql.gz | mysql -u crm_user -p deskcomm_crm

整个过程十几分钟就能完成，数据一条都不会少。

5. 常见问题与排查技巧实录

5.1 登录会话丢失与Redis配置问题

部署完成后，团队刚开始使用反馈最多的一个问题：登录每隔一段时间就被踢出来，操作到一半提示未登录。排查后发现是session存储方式的问题。Flask默认的session是签名的cookie，大小只有4KB，我往session里塞了用户ID、角色、权限列表之后，每次请求来回传输的数据量过大，而且浏览器端的cookie过期策略和服务器端不一致，导致频繁掉线。

解决方案是改用Redis存储session。这个改动在Flask里很简单，引入Flask-Session库，配置SESSION_TYPE='redis'，指定Redis连接地址即可。Redis里存储session还有一个好处，就是未来如果系统要扩展成多个应用实例，session是集中存储的，任何一台实例都能验证用户身份，天然支持水平扩展。

注意：如果Redis设置了密码，一定要在配置里正确填写。还有给Redis设置合适的内存淘汰策略，用allkeys-lru就可以，防止session数据越来越多把内存占满。

5.2 并发写入导致的数据覆盖问题

销售团队最常做的一个动作是，在客户详情页记录跟进的同时，另一个同事可能正在给这个客户修改等级和负责人。MySQL默认的事务隔离级别是REPEATABLE READ，如果两个请求同时读取同一行再分别更新，后提交的会把先提交的覆盖掉，但这里覆盖的是不同的字段，表现形式就是这次跟进记录的负责人字段突然变成了空。

这个问题定位了很久才找到根因。后来在更新操作中做了行级锁和字段级别校验。简单说就是执行UPDATE前先SELECT ... FOR UPDATE锁住这行，然后比较当前数据和提交时数据的版本号，不一致就提示“该客户已被其他同事修改，刷新后重试”。

但实际使用中，这种锁机制会给用户增加操作成本。更优雅的做法是改成字段级的“部分更新模式”，也就是在编辑表单时只提交发生变化的字段，而不是把整个对象的全部字段一起提交。配合更新时间戳的last_login_at逻辑判断，基本能杜绝覆盖问题。

5.3 备份恢复后出现的中文乱码

有次在测试环境做备份恢复演练，恢复完成后发现中文名称全部变成了问号。排查后确认是字符集问题：mysqldump导出时的默认字符集和导入目标库的字符集不一致。解决办法是导出时强制指定字符集：

mysqldump -u crm_user -p --default-character-set=utf8mb4 deskcomm_crm | gzip > backup.sql.gz

同时恢复前确认目标库的默认字符集是utf8mb4：

ALTER DATABASE deskcomm_crm CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

这个坑不在于代码，而在于数据库运维的细节。建议备份脚本里显式加上--default-character-set=utf8mb4，不要依赖MySQL的默认配置，否则换个版本或环境就会踩坑。

5.4 Nginx 502 Bad Gateway的快速定位

系统上线后有过一次502。当时Nginx返回502，但服务器负载不高，也没有重启记录。排查步骤是这样的：

第一步看Nginx错误日志：/var/log/nginx/error.log，发现是connect() failed (111: Connection refused) while connecting to upstream。
第二步确认Gunicorn进程状态：systemctl status deskcomm-crm，发现进程状态是active (running)，这就矛盾了。
第三步看Gunicorn的日志，发现worker超时被kill。原因是有一个统计报表的SQL查询特别慢，超过了Gunicorn默认的30秒超时时间，worker被杀后master自动拉起新worker，但那个请求已经断开，Nginx就报了502。

解决措施是在Gunicorn启动参数里加--timeout 120，同时优化那条慢SQL，加索引和查询缓存，两条腿走路才彻底解决问题。这也提醒我，复杂报表查询至少要给数据库加索引，不然用户一多并发一上来就会接连踩中超时的坑。

5.5 快速排查速查表

症状	可能原因	排查命令/位置	解决方案
无法访问网站	Nginx未启动/防火墙拦截	systemctl status nginx；sudo ufw status	启动Nginx，放行80/443端口
页面能开但登录失败	数据库连接失败	journalctl -u deskcomm-crm	重启MySQL，核对数据库账号密码
登录后立刻掉线	Session配置问题	检查Flask配置	启用Redis存session
上传文件失败	磁盘空间不足	df -h	清理日志或扩容磁盘
定时任务不执行	crontab环境变量问题	crontab -e；/var/log/syslog	脚本中写全绝对路径

6. 运行一段时间后的经验沉淀

6.1 给“免费CRM”与“私人搭建”之争画个句号

DeskcommCRM跑了大半年，我对免费CRM和私人网站（也就是自部署系统）的区别有了更实际的认识。免费CRM适合个人或极小团队试试水，没有技术维护能力又想快速看效果，那就先用免费版；但如果你的客户数据是有积累价值的，永远不要把自己的核心资产寄托在别人的免费策略上。私人部署这条路线，付出的是服务器钱和维护时间，换来的是数据主权、功能完全自定义、和“永久在线”的确定性。

所谓“永久在线”，不是一个抽象概念。对销售来说，就是凌晨想起客户要求，打开浏览器登录就能填跟进记录；对管理层来说，就是早上九点的提醒邮件准点出现在邮箱里；对老板来说，就是无论出差到哪儿，手机上打开网页就能看到实时销售数据。这些体验只要服务器稳定运行就一直在，不会有厂商调整策略、免费额度用尽、数据被锁这种不确定性。

6.2 后续扩展与优化方向

目前DeskcommCRM的下一步计划有两条。第一条是签约数据的深度分析，比如把成交周期、客户来源渠道转化率、流失原因做一个多维交叉报表，让管理决策有数据支撑。第二条是做一个客户公海池的概念，销售超过两周未跟进的有效客户自动流转回公海池供其他成员领取，激活潜在价值。

功能上，还想加一个自定义字段功能，让管理员自己在界面上新增客户字段类型，不需要改代码。这个功能的底层设计是给customers表加一个custom_fields的JSON字段，配合前端动态渲染表单。JSON字段在MySQL 8里原生支持，查询效率也不错，不改表结构就能满足灵活的字段扩展需求。

6.3 给同样想自建CRM的朋友几句实在话

如果你也想搞一套内部CRM，我给几条实在的建议。第一，第一版千万不要贪多，把客户管理、跟进记录、提醒任务做扎实，比做十个花哨模块有用得多。第二，部署时一定要把自动备份从第一天就做好，否则哪天数据库坏了，你连后悔的机会都没有。第三，权限模型在开始时就要想清楚，宁可先收紧再放开，不要一上来全员都是管理员。最后一条，尽量让一线销售参与测试和反馈，他们觉得好用，系统才真正活得起来；他们觉得难用，再漂亮的功能也是摆设。