1. 为什么小团队需要一个"永久在线"的CRM
先说一个我观察到的现象：很多三五人的小团队，客户信息散落在微信聊天记录、Excel表格、飞书文档、甚至某个人手机备忘录里。等到需要复盘一个客户跟进了多久、上次沟通说了什么、报价发到哪个版本，全组人开始翻聊天记录，翻半小时翻不出来。这不是能力问题，是工具缺位。
市面上的SaaS CRM按人头收费，五个人一年下来少说几千块，功能还只用到两成。更关键的是，客户数据放在别人服务器上，导出受限、字段不能随便加、流程不能随便改。于是"自建CRM"这件事就变得很有吸引力——数据在自己手里，功能按需定制，一次搭好长期用。
但"自建"两个字吓退了不少人。大家脑子里浮现的是：要买服务器、要配数据库、要搞运维、要防攻击……听起来像是一个需要专职运维才能撑住的事。实际上，用Flask + PostgreSQL + Nginx这套组合，一个懂点Python的人花一个周末就能把核心功能跑起来，而且跑得相当稳。
这篇文章要聊的就是这件事：怎么用轻量技术栈搭一个属于自己团队的客户管理系统，让它"永久在线"——不是指服务器永不宕机，而是指这套系统不依赖某个第三方服务的存续，你自己完全掌控，随时能迁移、能备份、能续命。关键词里的DeskcommCRM就是这类自建方案的典型代表，它的思路值得拆开来看。
适合谁读：三到二十人的小团队负责人、独立开发者、想给自己业务做一套客户跟进工具的技术同学。不需要你是运维专家，但需要你能看懂基本的Linux命令和Python代码。
2. 技术选型：为什么是Flask而不是Django
2.1 小团队CRM的真实负载有多大
先算一笔账。一个十人团队，每人每天新增或更新20条客户记录，一天200条写入，一年按250个工作日算，5万条记录。每条记录假设2KB（含备注、标签、跟进历史），总共100MB。这个量级，说句不好听的，SQLite都能扛。
所以选型的第一原则是：不要为不存在的规模做过度设计。很多团队一上来就上微服务、上消息队列、上分布式数据库，结果维护成本比业务本身还高。CRM这种读多写少、并发极低的场景，单机单进程完全够用。
那为什么不用SQLite？因为CRM会有多个人同时写的情况，SQLite的写锁在并发写入时容易出问题，而且备份和远程访问不如PostgreSQL方便。PostgreSQL在这个量级下性能绰绰有余，还自带全文检索、JSON字段、窗口函数这些实用能力，后面想加功能不用换库。
2.2 Flask和Django的取舍逻辑
Django自带Admin、ORM、认证、迁移，开箱即用，很多人第一反应是选它。但我实际搭过几套之后，小团队CRM这个场景我更倾向Flask，原因有三：
第一，CRM的界面高度定制。客户列表要按行业分组、按跟进阶段着色、按负责人筛选，这些Django Admin改起来反而别扭，你得跟它的模板体系较劲。Flask没有预设，你想怎么渲染就怎么渲染，前端用原生HTML+一点JS就能做出很顺手的界面。
第二，字段经常变。小团队的CRM需求是长出来的，今天加个"客户来源"，明天加个"下次跟进提醒"，Django的迁移体系虽然完善，但每次改模型都要生成迁移文件、处理冲突。Flask配SQLAlchemy或者直接写SQL，改起来更直接。
第三，学习曲线和调试成本。Flask一个文件就能跑起来，出问题一眼能看到底。Django的层次多，新人接手时定位问题要翻好几层。
当然，Django不是不好，如果你的团队已经有Django经验，或者需要复杂的权限体系，选Django完全合理。选型的核心是匹配团队现状，不是追新。
2.3 三个组件的分工
| 组件 | 角色 | 为什么需要它 |
|---|---|---|
| Flask | Web框架 | 处理HTTP请求、路由、模板渲染，轻量灵活 |
| PostgreSQL | 数据库 | 存客户数据，支持并发写、全文检索、JSON字段 |
| Nginx | 反向代理 | 对外提供稳定入口，处理静态文件、HTTPS、限流 |
这个架构里，Flask应用本身监听本地端口（比如127.0.0.1:8000），Nginx监听80/443对外。外部请求先到Nginx，Nginx再转发给Flask。这样做的好处是：Flask不用直接暴露在公网，安全性高；静态文件（CSS、JS、图片）由Nginx直接返回，不占用Flask进程；将来要加HTTPS、加访问限制，都在Nginx层做，不动应用代码。
提示：不要图省事让Flask直接监听0.0.0.0:80对外。Flask自带的开发服务器性能差、安全性弱，只适合本地调试。生产环境必须用Nginx在前面挡着。
3. 从零搭起：PostgreSQL与Flask的落地细节
3.1 PostgreSQL安装：选对版本和安装方式
热词里"postgresql下载哪个版本""postgresql安装教程windows""linux安装postgresql"出现频率很高，说明这一步卡住了不少人。我的建议很明确：生产环境用Linux，版本选当前稳定大版本的最新小版本。
以AlmaLinux 9为例（热词里出现了"almalinux 9 安装nginx"，说明这个系统有不少人用），安装PostgreSQL的步骤：
# 添加官方仓库 sudo dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm # 禁用系统自带的postgresql模块，避免版本冲突 sudo dnf -qy module disable postgresql # 安装PostgreSQL 16 sudo dnf install -y postgresql16-server postgresql16-contrib # 初始化数据库 sudo /usr/pgsql-16/bin/postgresql-16-setup initdb # 启动并设置开机自启 sudo systemctl enable --now postgresql-16Windows下安装更简单，去官网下载安装包一路下一步即可，但要注意两点：一是安装时设置的postgres用户密码要记牢，二是端口默认5432，如果本机已有其他数据库占用要改。
安装完验证一下：
sudo -u postgres psql -c "SELECT version();"能输出版本号就说明装好了。
3.2 建库建用户：别用postgres超级用户跑应用
这是很多人踩的坑：图省事直接用postgres超级用户连接数据库。一旦应用有SQL注入漏洞，攻击者就能拿到整个数据库实例的控制权。正确做法是给应用单独建一个受限用户：
-- 用postgres用户登录后执行 CREATE USER crm_app WITH PASSWORD '你的强密码'; CREATE DATABASE deskcomm_crm OWNER crm_app; -- 只给必要的权限 GRANT ALL PRIVILEGES ON DATABASE deskcomm_crm TO crm_app;然后编辑pg_hba.conf，把本地连接方式从peer改成md5或scram-sha-256，让应用能用密码登录：
# 找到这行 local all all peer # 改成 local all all scram-sha-256改完重启PostgreSQL生效。这一步不做，Flask连接时会报"peer authentication failed"，是新手最常见的报错之一。
3.3 Flask连接PostgreSQL：连接池是必须的
Flask本身不带数据库连接管理，需要装驱动。推荐用psycopg2（同步）或psycopg（新版），配合SQLAlchemy做ORM：
pip install flask sqlalchemy psycopg2-binary连接字符串这样写：
from flask import Flask from flask_sqlalchemy import SQLAlchemy app = Flask(__name__) app.config['SQLALCHEMY_DATABASE_URI'] = \ 'postgresql+psycopg2://crm_app:密码@127.0.0.1:5432/deskcomm_crm' app.config['SQLALCHEMY_ENGINE_OPTIONS'] = { 'pool_size': 5, 'max_overflow': 10, 'pool_pre_ping': True, # 关键：连接前先ping，避免用到失效连接 'pool_recycle': 3600, # 一小时回收一次连接 } db = SQLAlchemy(app)pool_pre_ping这个参数我要重点说。PostgreSQL默认会断开空闲超过一定时间的连接，如果Flask的连接池里存着已经失效的连接，下一个请求就会报"server closed the connection unexpectedly"。加上pool_pre_ping=True，每次取连接前先探活，失效的就重建，这个报错基本就消失了。这是我在生产环境踩过好几次才总结出来的。
3.4 客户表怎么设计：先想清楚跟进流程
CRM的核心表其实就几张：客户表、联系人表、跟进记录表、用户表。设计时最容易犯的错是字段拍脑袋加，导致后面查询和统计很痛苦。
我的经验是，先画出团队的跟进流程，再倒推字段。比如流程是"线索→初步接触→需求确认→报价→成交/流失"，那客户表里就要有一个stage字段存当前阶段，一个stage_updated_at存阶段变更时间。这样后面统计"每个阶段平均停留多久"才有数据支撑。
CREATE TABLE customer ( id SERIAL PRIMARY KEY, name VARCHAR(200) NOT NULL, industry VARCHAR(100), source VARCHAR(50), -- 客户来源 stage VARCHAR(30) DEFAULT 'lead', owner_id INTEGER REFERENCES app_user(id), tags JSONB DEFAULT '[]', -- 标签用JSONB，灵活 created_at TIMESTAMPTZ DEFAULT now(), stage_updated_at TIMESTAMPTZ DEFAULT now() ); CREATE INDEX idx_customer_stage ON customer(stage); CREATE INDEX idx_customer_owner ON customer(owner_id);tags用JSONB是个实用技巧。小团队的标签体系经常变，用JSONB存数组，查询时用tags @> '["重点客户"]'就能筛出来，不用为标签单独建表建关联。PostgreSQL的JSONB支持GIN索引，数据量大了也不慢。
4. Nginx配置：让CRM稳定对外的关键几行
4.1 反向代理的基本配置
Nginx装好之后（AlmaLinux下sudo dnf install nginx，Ubuntu下sudo apt install nginx），核心配置就一个server块：
server { listen 80; server_name crm.yourdomain.com; # 静态文件直接由Nginx返回 location /static/ { alias /var/www/deskcomm/static/; expires 7d; add_header Cache-Control "public"; } # 其他请求转发给Flask 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; proxy_read_timeout 60s; } }X-Real-IP和X-Forwarded-For这两行很重要。Flask拿到的request.remote_addr默认是Nginx的地址（127.0.0.1），加上这两个头之后，应用里通过request.headers.get('X-Real-IP')才能拿到真实客户端IP。做登录日志、异常检测都靠它。
4.2 静态文件交给Nginx，Flask只处理动态请求
很多人把CSS、JS、图片也交给Flask返回，这是浪费。Flask处理一个静态文件请求要经过完整的WSGI流程，而Nginx直接读磁盘返回，性能差一个数量级。配置里那个location /static/块就是干这个的。
Flask项目里静态文件默认放在static/目录，模板里用url_for('static', filename='style.css')生成路径。部署时把这个目录软链或者复制到Nginx能访问的位置即可。
4.3 用systemd守护Flask进程
Flask应用不能靠python app.py裸跑，终端一关就没了。用systemd做成服务：
# /etc/systemd/system/deskcomm.service [Unit] Description=Deskcomm CRM Flask App After=network.target postgresql-16.service [Service] User=www-data WorkingDirectory=/opt/deskcomm ExecStart=/opt/deskcomm/venv/bin/gunicorn -w 4 -b 127.0.0.1:8000 app:app Restart=always RestartSec=5 [Install] WantedBy=multi-user.target这里用gunicorn而不是Flask自带的服务器。-w 4表示4个工作进程，小团队够用了。Restart=always保证进程崩溃后自动拉起，这是"永久在线"的基础保障。
sudo systemctl daemon-reload sudo systemctl enable --now deskcomm sudo systemctl status deskcomm看到active (running)就说明服务起来了。
5. 那些文档里不会写的踩坑记录
5.1 数据库连接数被打满
有一次团队反馈CRM突然打不开，报"too many connections"。登服务器一看，PostgreSQL的连接数到了100上限。原因是Flask的gunicorn开了4个worker，每个worker的连接池pool_size=5，加上max_overflow=10，理论上最多4×15=60个连接，再加上一些残留连接，就顶到上限了。
解决办法有两个：一是调小连接池，pool_size=3, max_overflow=5；二是调大PostgreSQL的max_connections。我建议两个都做，连接池调小是治本，因为小团队根本用不到那么多并发连接。
-- 查看当前连接数 SELECT count(*) FROM pg_stat_activity; -- 查看最大连接数 SHOW max_connections;5.2 时间字段的时区陷阱
PostgreSQL的TIMESTAMPTZ存的是UTC时间，Flask取出来默认也是UTC。如果前端直接显示，用户看到的时间会比北京时间少8小时。这个坑我踩过，客户跟进记录的时间全乱了。
处理方式：在Flask里统一转换，或者用pytz/zoneinfo在展示层转。我的做法是在应用启动时设置：
import os os.environ['TZ'] = 'Asia/Shanghai'然后在模板里用过滤器统一格式化。不要在每个地方手动加8小时，那样迟早出错。
5.3 Nginx的client_max_body_size
CRM里经常要上传合同、报价单附件。Nginx默认允许的请求体大小是1MB，超过就报413错误。这个报错很隐蔽，因为Flask那边根本收不到请求，日志里也没有。
server { ... client_max_body_size 20m; # 按需调整 }加上这行，重启Nginx即可。20MB对大多数附件够用了，如果经常传大文件，考虑用对象存储而不是直接存数据库。
5.4 备份不是可选项
"永久在线"的前提是数据不丢。PostgreSQL的备份很简单：
# 每天凌晨3点全量备份 0 3 * * * pg_dump -U crm_app -h 127.0.0.1 deskcomm_crm | gzip > /backup/crm_$(date +\%Y\%m\%d).sql.gz配合find /backup -name "crm_*.sql.gz" -mtime +30 -delete保留30天。备份文件最好再同步一份到另一台机器或者对象存储，别只放本机——本机磁盘挂了备份也没了。
注意：备份完一定要定期做恢复演练。我见过备份脚本跑了半年，结果真要恢复时发现备份文件是空的，因为pg_dump的密码认证一直失败但脚本没检查返回值。备份脚本里加上
set -e和错误通知。
6. 让CRM真正被团队用起来的几个设计
6.1 录入成本决定使用率
技术搭好了，最大的挑战其实是让团队成员愿意用。我见过太多自建系统，搭完只有搭建者自己在用。核心原因是录入太麻烦。
降低录入成本的做法：客户列表页支持快速新建，只填名字和来源两个字段就能存，其他信息后面慢慢补。跟进记录支持在客户详情页直接输入，回车即存，不用跳转页面。这些交互细节比功能多少更重要。
6.2 用看板视图代替表格
销售团队对表格的接受度远低于看板。把客户按stage字段渲染成看板，每个阶段一列，客户卡片可以拖拽换阶段，这个体验比表格筛选直观得多。实现上不需要复杂的前端框架，原生JS的拖拽API加上一个更新接口就够了。
// 拖拽结束更新阶段 async function onDrop(customerId, newStage) { await fetch(`/api/customer/${customerId}/stage`, { method: 'POST', headers: {'Content-Type': 'application/json'}, body: JSON.stringify({stage: newStage}) }); }后端收到请求更新stage和stage_updated_at字段。就这么简单，但使用率会明显提升。
6.3 提醒机制：别让客户被遗忘
CRM最有价值的不是记录，是提醒。一个客户三天没跟进、报价发出去一周没回音，系统应该主动提醒负责人。实现方式可以很简单：每天定时任务扫描stage_updated_at超过阈值的客户，生成提醒列表，登录时在首页展示。
# 每天早上的定时任务 def check_stale_customers(): threshold = datetime.now(timezone.utc) - timedelta(days=3) stale = Customer.query.filter( Customer.stage_updated_at < threshold, Customer.stage.notin_(['won', 'lost']) ).all() # 生成提醒记录这个功能不需要推送、不需要邮件，就在首页显示一个"需要跟进"的列表，效果已经很好。
7. 关于"永久在线"这件事的真实理解
最后聊聊标题里"永久在线"这四个字。它不是指99.99%的可用性——那是大厂用钱堆出来的。对小团队自建系统来说，"永久在线"的真实含义是：这套系统不依赖任何你控制不了的东西。
SaaS服务可能涨价、可能改条款、可能哪天就关停了，你的数据在别人手里。自建系统跑在自己的服务器上，代码在自己手里，数据在自己手里，哪怕服务器到期了，换个机器把备份一恢复，半小时就能重新跑起来。这种掌控感才是"永久"的来源。
当然，代价是你得自己维护。系统出问题没人帮你兜底，安全补丁要自己打，备份要自己盯。所以我的建议是：如果团队里没有一个人愿意承担这个维护责任，那还是老老实实用SaaS。自建不是免费的，它只是把"付费"换成了"投入时间"。
对于愿意投入的团队，Flask + PostgreSQL + Nginx这套组合的性价比极高。它足够简单，简单到你花一个周末就能理解全部；又足够强大，强大到能支撑一个团队几年的客户管理需求。DeskcommCRM这类方案的价值也在这里——它证明了小团队完全有能力拥有自己的客户管理系统，而不必把命脉交给别人。
我在实际维护中最大的体会是：别追求功能全，追求数据准。一个只有客户列表和跟进记录、但每条数据都真实及时的系统，比一个功能齐全但没人维护的系统有价值一百倍。先把核心流程跑通，让团队养成录入习惯，后面加什么功能都是水到渠成的事。
