1. 从免费SaaS到自建系统为什么我最终选择了DeskcommCRM用了三年多的免费CRM从最早的表格工具到后来的在线SaaS我算是把市面上能白嫖的方案都摸了一遍。最开始觉得挺香——注册就能用不用管服务器不用操心备份销售录单、跟进记录、漏斗视图这些基础功能都有。但用着用着问题就来了客户数据存在别人服务器上导出要申请字段想改要升级套餐API调用次数卡得死死的最要命的是有一次服务商调整业务线整个系统停服三天销售团队直接抓瞎。这就是免费CRM和私人网站最本质的区别。免费CRM是租房子房东随时可能涨租、改规矩甚至收房自建系统是买地盖楼前期投入大但每一块砖都归你管。DeskcommCRM这个项目吸引我的点就在这——它是一套基于Django的CRM系统代码完全开放可以私有化部署在自己的服务器上数据、字段、流程、集成全部自主可控。我选它的理由很直接第一Django框架成熟稳定Python技术栈我熟悉二次开发成本低第二DeskcommCRM的功能覆盖了线索、商机、客户、合同、回款这些核心模块不是那种只有通讯录的半成品第三社区活跃度还行遇到问题能搜到相关讨论。当然最打动我的还是“永久在线”这个可能性——只要服务器不关系统就一直在不用看任何服务商的脸色。这篇文章适合两类人看一类是正在用免费CRM但感觉被绑住手脚的中小团队负责人另一类是有一定Python基础、想通过实战项目练手的开发者。我会把整个自建过程拆开揉碎从环境准备到部署上线从数据迁移到性能调优包括我踩过的那些坑全部摊开来讲。你不需要是Django高手但至少要能看懂Python代码和基本的Linux命令。2. 技术选型与整体架构设计2.1 为什么是Django而不是其他框架DeskcommCRM本身是基于Django开发的这省去了我很多选型纠结。但即便从零开始选Django在这个场景下也是最优解之一。CRM系统的核心需求是什么大量的表单处理、复杂的权限控制、频繁的数据库读写、需要快速搭建管理后台。Django的ORM、Admin、Auth、Form这些内置组件几乎是为这类业务系统量身定做的。对比一下其他方案Flask更轻量但什么都要自己搭FastAPI异步性能好但生态在CRM这种重后台的场景下不如Django成熟Node.js全栈方案对Python团队来说学习成本太高。Django的“batteries included”哲学在这里体现得淋漓尽致——你不需要花两周时间造一个权限系统的轮子django.contrib.auth直接拿来用配合django-rbac或者自带的Group/Permission机制半天就能把角色权限跑通。还有一个隐性优势Django的社区足够大。遇到问题搜一下Stack Overflow上大概率有现成答案。DeskcommCRM这种项目最怕的就是遇到坑没人填Django的生态让这个风险降低了不少。2.2 私有化部署的架构分层我的部署架构分三层接入层、应用层、数据层。接入层用Nginx做反向代理和静态文件服务顺便处理SSL证书应用层跑Django应用用Gunicorn做WSGI服务器Supervisor做进程守护数据层用PostgreSQL做主库Redis做缓存和会话存储Celery处理异步任务比如邮件发送和报表生成。为什么不用MySQLPostgreSQL在JSON字段、全文检索、复杂查询上的优势更明显CRM系统里自定义字段和高级筛选是刚需PostgreSQL的JSONB类型能省掉很多关联表的麻烦。Redis的引入是因为Django的session默认存数据库并发一高数据库压力很大放到Redis里既快又减轻主库负担。服务器配置方面我用的是一台4核8G的云服务器跑这套系统绰绰有余。如果团队规模在50人以内2核4G也能撑住但建议内存不要低于4GPostgreSQL和Redis都是吃内存的主。存储用SSDCRM系统虽然数据量不大但查询频繁IO性能直接影响体验。2.3 网络与安全的基础考量自建系统放在公网上安全是绕不开的话题。我的做法是Nginx层强制HTTPS用Let‘s Encrypt免费证书自动续期Django的SECRET_KEY必须改掉默认值DEBUG模式在生产环境绝对关闭数据库只监听本地回环地址不对外暴露端口服务器防火墙只开放80、443和SSH端口SSH改非标准端口并禁用密码登录只用密钥认证。还有一点容易被忽略Django的ALLOWED_HOSTS必须配置正确否则会报400错误。我一开始只写了域名后来发现用IP访问也会被拦调试了半天才想起来这个配置。另外如果用了CDN或者反向代理要正确设置SECURE_PROXY_SSL_HEADER不然Django会认为请求是HTTP的导致重定向循环。3. 环境准备与依赖安装的实操细节3.1 服务器初始化与Python环境我用的Ubuntu 22.04 LTS系统自带Python 3.10但DeskcommCRM的某些依赖可能需要特定版本。稳妥起见我用pyenv装了一个Python 3.11.6隔离系统Python避免把系统工具搞崩。安装pyenv的过程略过无非是装编译依赖、克隆仓库、配置环境变量那几步。创建虚拟环境是必须的不要图省事直接用系统Python。python -m venv venv创建后激活后续所有pip安装都在这个环境里进行。虚拟环境的好处是依赖隔离万一某个包版本冲突删掉重建就行不会影响系统。系统依赖方面PostgreSQL和Redis直接用apt装sudo apt install postgresql redis-server。PostgreSQL装完后要创建数据库和用户这里有个坑Django的createdb权限默认没有需要手动给用户授权。我当时的命令是sudo -u postgres psql CREATE DATABASE deskcomm; CREATE USER deskcomm_user WITH PASSWORD your_password; ALTER ROLE deskcomm_user SET client_encoding TO utf8; ALTER ROLE deskcomm_user SET default_transaction_isolation TO read committed; ALTER ROLE deskcomm_user SET timezone TO Asia/Shanghai; GRANT ALL PRIVILEGES ON DATABASE deskcomm TO deskcomm_user; \q注意时区设置CRM系统里时间字段很多时区不对会导致跟进记录时间错乱。Asia/Shanghai是必须的除非你的团队跨时区工作。3.2 DeskcommCRM源码获取与依赖安装从代码仓库克隆源码后先看requirements.txt。DeskcommCRM的依赖不算多核心就是Django、psycopg2、redis、celery、gunicorn这些。安装时建议加国内镜像源不然某些包下载速度感人pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simplepsycopg2在编译时可能需要libpq-dev和python3-dev如果报错就补装这两个系统包。还有一个常见问题是Pillow安装失败通常是缺少图像处理库sudo apt install libjpeg-dev zlib1g-dev能解决。依赖装完后复制一份settings.py的模板修改数据库连接、Redis地址、SECRET_KEY、ALLOWED_HOSTS这些关键配置。DeskcommCRM的配置项比较清晰注释也全照着改就行。但有一个地方要注意STATIC_ROOT和MEDIA_ROOT的路径要提前创建好并且给足权限不然collectstatic会报错。3.3 数据库迁移与初始数据python manage.py migrate是第一步但在这之前要确保数据库连接正常。我遇到过一个坑PostgreSQL的pg_hba.conf默认配置可能不允许密码登录需要改成md5或scram-sha-256。改完后记得sudo systemctl restart postgresql。迁移完成后创建超级用户python manage.py createsuperuser。然后加载初始数据DeskcommCRM可能提供了一些fixture文件比如默认的权限组、初始字段配置等。如果没有就手动在Admin里配。我建议先把角色权限体系理清楚再录数据不然返工很麻烦。静态文件收集python manage.py collectstatic。这一步会把Admin和所有app的静态文件汇总到STATIC_ROOTNginx直接从这个目录读性能比Django自己服务静态文件好得多。注意STATICFILES_DIRS和STATIC_ROOT不要设成同一个目录否则collectstatic会报错。4. 核心功能模块的配置与调优4.1 权限体系与RBAC的落地DeskcommCRM的权限控制基于Django的Permission系统但原生Permission是模型级别的CRM需要更细粒度的控制比如“销售只能看自己的客户”、“经理能看团队的客户”、“管理员能看全部”。这就需要引入对象级权限或者自定义权限逻辑。我的做法是结合Django的Group和自定义的get_queryset方法。在ViewSet里重写get_queryset根据当前用户的角色过滤数据def get_queryset(self): user self.request.user if user.is_superuser: return Customer.objects.all() if user.groups.filter(name销售经理).exists(): return Customer.objects.filter(teamuser.team) return Customer.objects.filter(owneruser)这种硬编码的方式虽然不够优雅但胜在直观、好调试。如果团队规模大、角色多可以考虑用django-guardian做对象级权限但会增加查询开销需要权衡。还有一个细节Django Admin的权限和前端API的权限是两套体系。Admin用的是has_view_permission这些方法API用的是DRF的permission_classes。配置时要确保两边一致不然会出现“Admin能看但API看不到”的诡异情况。4.2 自定义字段与动态表单CRM系统最怕的就是字段不够用。DeskcommCRM支持自定义字段但实现方式决定了灵活性和性能。我见过两种方案一种是EAV模型Entity-Attribute-Value把字段名和值存到单独的表中另一种是JSON字段把自定义字段塞进一个JSONB列。EAV的优点是查询灵活缺点是关联查询多性能差JSON字段的优点是读写快、结构简单缺点是复杂查询和索引支持弱。DeskcommCRM用的是哪种我没细看但如果是JSON方案PostgreSQL的GIN索引能大幅提升查询性能CREATE INDEX idx_customer_custom_fields ON customer USING GIN (custom_fields);动态表单的前端渲染也是个坑。如果字段是动态的前端就不能写死表单结构需要根据后端返回的字段定义动态生成。我用的是Vue的动态组件根据字段类型文本、下拉、日期、多选渲染不同的输入控件。这里要注意字段校验规则也要动态生成不然前端校验和后端校验对不上用户体验很差。4.3 数据导入与迁移策略从旧CRM迁移数据是自建系统最头疼的环节。我的旧系统能导出CSV但字段名和DeskcommCRM对不上需要做映射。我写了一个Python脚本用pandas做数据清洗和转换然后用Django的bulk_create批量导入。批量导入时要注意第一关掉Django的信号signal不然每导入一条就触发一次信号速度慢得离谱第二用事务包起来出错就回滚避免导入一半留下脏数据第三分批导入每批1000条左右太多会撑爆内存。from django.db import transaction transaction.atomic def import_customers(dataframe): customers [] for _, row in dataframe.iterrows(): customers.append(Customer( namerow[客户名称], phonerow[联系电话], # ... 其他字段映射 )) Customer.objects.bulk_create(customers, batch_size1000)导入完成后要校验数据完整性比如客户数量对不对、关键字段有没有丢失、关联关系有没有断。我当时的做法是随机抽100条和旧系统逐条对比确认无误后再全量切换。5. 部署上线与性能调优实战5.1 Gunicorn与Nginx的配置要点Gunicorn的worker数量有个经验公式(2 * CPU核心数) 1。4核机器就是9个worker。但CRM系统是IO密集型worker可以适当多一些我设了12个。worker class用gevent还是sync如果代码里有同步阻塞操作比如调用外部API用gevent能提升并发但要注意兼容性。我用的sync稳定第一。Nginx配置里client_max_body_size要调大不然上传附件会报413。我设了50M够用了。静态文件用alias指向STATIC_ROOT媒体文件指向MEDIA_ROOT并设置缓存头location /static/ { alias /path/to/static/; expires 30d; add_header Cache-Control public, immutable; } location /media/ { alias /path/to/media/; expires 7d; }还有一个容易忽略的点Nginx的proxy_read_timeout默认60秒如果某个请求处理时间超过60秒比如导出大量数据Nginx会断开连接。我把它调到了300秒并在Django端用Celery做异步导出避免长时间占用worker。5.2 数据库查询优化与索引策略CRM系统慢十有八九是数据库查询的问题。Django的ORM很方便但容易写出N1查询。比如列出客户列表时如果每个客户都要查一次负责人姓名那就是N1。用select_related和prefetch_related能解决大部分问题# 差N1查询 customers Customer.objects.all() for c in customers: print(c.owner.username) # 每次循环都查一次数据库 # 好一次查询搞定 customers Customer.objects.select_related(owner).all()索引方面外键字段Django会自动建索引但经常用于筛选的字段要手动加。比如created_at、status、owner_id这些加索引后查询速度提升明显。但索引不是越多越好每个索引都会拖慢写入速度CRM系统读多写少适当多加几个没问题。慢查询日志要开PostgreSQL的log_min_duration_statement设成1000毫秒超过1秒的查询都记下来定期分析优化。我上线第一个月就是靠慢查询日志发现了好几个性能瓶颈。5.3 缓存与异步任务的引入Redis缓存主要用在两个地方一是页面级缓存比如仪表盘的统计数据变化不频繁但查询复杂缓存5分钟能省很多数据库压力二是会话存储Django的session默认存数据库改成Redis后登录态校验快了一个数量级。Celery处理异步任务比如发送邮件、生成报表、批量导入。配置Celery时要注意broker和backend都用Redis任务序列化用JSONpickle有安全风险。Celery的worker数量不用太多2-4个足够因为异步任务通常不要求实时性。还有一个坑Celery的定时任务用celery beat但beat只能起一个实例多实例会重复执行任务。如果部署了多个应用节点beat要单独部署或者用django-celery-beat把调度信息存数据库避免冲突。6. 踩坑复盘与常见问题速查6.1 部署过程中遇到的典型问题问题一静态文件404。明明collectstatic成功了但页面样式全丢。排查发现Nginx的alias路径末尾少了斜杠/static/和/static的区别导致路径拼接错误。加上斜杠后解决。问题二数据库连接数爆满。上线后不久PostgreSQL报“too many connections”。原因是Gunicorn的worker每个都保持数据库连接12个worker加上Celery和定时任务连接数超了。解决方案是用pgbouncer做连接池或者调低CONN_MAX_AGE让连接及时释放。问题三时区导致的时间错乱。跟进记录的时间比实际时间少了8小时。原因是Django的TIME_ZONE设成了UTC而USE_TZ是True。改成Asia/Shanghai后正常。但要注意数据库里存的时间始终是UTC只是在展示时转换所以不要手动去改数据库里的时间值。问题四CSRF验证失败。前端提交表单时报403。原因是Nginx转发时没有传递X-Forwarded-Proto头Django认为请求是HTTP的CSRF cookie设置失败。在Nginx配置里加上proxy_set_header X-Forwarded-Proto $scheme;解决。6.2 性能与稳定性问题排查页面加载慢。用Django Debug Toolbar定位发现某个列表页执行了200多次查询。优化get_queryset加上select_related和prefetch_related后降到5次以内。内存泄漏。运行几天后服务器内存被吃满。用memory_profiler排查发现某个自定义的导出功能把大量数据加载到内存里。改成流式输出用StreamingHttpResponse分块返回内存占用稳定在50M以内。Celery任务堆积。邮件发送任务越积越多。原因是SMTP服务器限流任务失败后不断重试。给任务加上max_retries3和retry_backoffTrue失败后指数退避重试避免雪崩。6.3 数据安全与备份策略自建系统最大的风险是数据丢失。我的备份策略是每天凌晨全量备份PostgreSQL用pg_dump导出压缩文件每小时增量备份用WAL归档。备份文件同步到另一台服务器和对象存储保留最近30天。恢复演练很重要。我每个月做一次恢复测试从备份文件恢复到测试环境确认数据完整可用。这个习惯救过我一次——有一次服务器硬盘故障靠备份在2小时内恢复了全部数据。权限方面数据库密码、SECRET_KEY、API密钥这些敏感信息不要硬编码在代码里用环境变量或者.env文件管理。.env文件要加入.gitignore避免提交到代码仓库。7. 从能用 to 好用我的二次开发实践7.1 与企业微信/钉钉的集成CRM系统如果只能网页访问销售在外跑客户时很不方便。我把DeskcommCRM和企业微信做了集成销售在企业微信里就能查客户、录跟进、看商机。实现方式是用企业微信的Webhook和APIDjango端提供REST接口企业微信端用自建应用调用。集成的关键是身份映射。企业微信的用户ID和CRM的用户ID要对应起来我在User模型里加了一个wechat_work_id字段登录时用企业微信的OAuth2获取用户信息匹配到CRM用户后自动登录。这样销售不用记两套账号密码体验好很多。7.2 自动化工作流与提醒CRM里有很多重复性工作比如“客户三天没跟进要提醒”、“合同到期前一周要通知”。这些用Celery的定时任务实现每天跑一次扫描符合条件的记录发送提醒。提醒渠道支持站内信、邮件、企业微信。站内信用Django的django-notifications邮件用django.core.mail企业微信用Webhook。提醒规则做成可配置的管理员在后台就能改不用改代码。7.3 报表与数据看板销售团队需要看漏斗、业绩排名、回款趋势这些报表。我用Django ORM做聚合查询前端用ECharts渲染。报表数据缓存到Redis避免每次刷新都查数据库。有一个性能技巧报表查询尽量在数据库层完成不要拉到Python里再计算。比如“本月每个销售的合同总额”用annotate和Sum一次查询搞定from django.db.models import Sum report Contract.objects.filter( sign_date__monthcurrent_month ).values(owner__username).annotate( totalSum(amount) ).order_by(-total)这样比循环查询快几十倍数据量大的时候差距更明显。8. 写在最后一些个人体会这套系统跑了大半年中间经历过两次服务器迁移、一次数据库版本升级、无数次小修小补。最大的感受是自建CRM不是一锤子买卖而是一个持续维护的过程。你需要定期看日志、优化查询、更新依赖、修补安全漏洞。如果团队里没有人愿意承担这个维护责任那还是用SaaS省心。但如果你有技术能力自建带来的掌控感是SaaS给不了的。数据在自己手里想怎么改就怎么改想集成什么就集成什么不用等产品经理排期不用看服务商脸色。这种自由值得付出那些维护成本。最后分享一个小技巧部署时用Docker Compose把PostgreSQL、Redis、Django、Nginx全部容器化迁移和扩容会方便很多。我后来把整套环境用Docker重写了一遍从零部署到上线只要半小时比第一次折腾两天快多了。如果你还没用Docker建议花点时间学一下对自建系统来说这是性价比最高的技能投资。 
长河君 · 2026/9/26 9:23:37 · 阅读 1.2k 基于Django的CRM私有化部署实战：从免费SaaS到自建系统
1. 从免费SaaS到自建系统为什么我最终选择了DeskcommCRM用了三年多的免费CRM从最早的表格工具到后来的在线SaaS我算是把市面上能白嫖的方案都摸了一遍。最开始觉得挺香——注册就能用不用管服务器不用操心备份销售录单、跟进记录、漏斗视图这些基础功能都有。但用着用着问题就来了客户数据存在别人服务器上导出要申请字段想改要升级套餐API调用次数卡得死死的最要命的是有一次服务商调整业务线整个系统停服三天销售团队直接抓瞎。这就是免费CRM和私人网站最本质的区别。免费CRM是租房子房东随时可能涨租、改规矩甚至收房自建系统是买地盖楼前期投入大但每一块砖都归你管。DeskcommCRM这个项目吸引我的点就在这——它是一套基于Django的CRM系统代码完全开放可以私有化部署在自己的服务器上数据、字段、流程、集成全部自主可控。我选它的理由很直接第一Django框架成熟稳定Python技术栈我熟悉二次开发成本低第二DeskcommCRM的功能覆盖了线索、商机、客户、合同、回款这些核心模块不是那种只有通讯录的半成品第三社区活跃度还行遇到问题能搜到相关讨论。当然最打动我的还是“永久在线”这个可能性——只要服务器不关系统就一直在不用看任何服务商的脸色。这篇文章适合两类人看一类是正在用免费CRM但感觉被绑住手脚的中小团队负责人另一类是有一定Python基础、想通过实战项目练手的开发者。我会把整个自建过程拆开揉碎从环境准备到部署上线从数据迁移到性能调优包括我踩过的那些坑全部摊开来讲。你不需要是Django高手但至少要能看懂Python代码和基本的Linux命令。2. 技术选型与整体架构设计2.1 为什么是Django而不是其他框架DeskcommCRM本身是基于Django开发的这省去了我很多选型纠结。但即便从零开始选Django在这个场景下也是最优解之一。CRM系统的核心需求是什么大量的表单处理、复杂的权限控制、频繁的数据库读写、需要快速搭建管理后台。Django的ORM、Admin、Auth、Form这些内置组件几乎是为这类业务系统量身定做的。对比一下其他方案Flask更轻量但什么都要自己搭FastAPI异步性能好但生态在CRM这种重后台的场景下不如Django成熟Node.js全栈方案对Python团队来说学习成本太高。Django的“batteries included”哲学在这里体现得淋漓尽致——你不需要花两周时间造一个权限系统的轮子django.contrib.auth直接拿来用配合django-rbac或者自带的Group/Permission机制半天就能把角色权限跑通。还有一个隐性优势Django的社区足够大。遇到问题搜一下Stack Overflow上大概率有现成答案。DeskcommCRM这种项目最怕的就是遇到坑没人填Django的生态让这个风险降低了不少。2.2 私有化部署的架构分层我的部署架构分三层接入层、应用层、数据层。接入层用Nginx做反向代理和静态文件服务顺便处理SSL证书应用层跑Django应用用Gunicorn做WSGI服务器Supervisor做进程守护数据层用PostgreSQL做主库Redis做缓存和会话存储Celery处理异步任务比如邮件发送和报表生成。为什么不用MySQLPostgreSQL在JSON字段、全文检索、复杂查询上的优势更明显CRM系统里自定义字段和高级筛选是刚需PostgreSQL的JSONB类型能省掉很多关联表的麻烦。Redis的引入是因为Django的session默认存数据库并发一高数据库压力很大放到Redis里既快又减轻主库负担。服务器配置方面我用的是一台4核8G的云服务器跑这套系统绰绰有余。如果团队规模在50人以内2核4G也能撑住但建议内存不要低于4GPostgreSQL和Redis都是吃内存的主。存储用SSDCRM系统虽然数据量不大但查询频繁IO性能直接影响体验。2.3 网络与安全的基础考量自建系统放在公网上安全是绕不开的话题。我的做法是Nginx层强制HTTPS用Let‘s Encrypt免费证书自动续期Django的SECRET_KEY必须改掉默认值DEBUG模式在生产环境绝对关闭数据库只监听本地回环地址不对外暴露端口服务器防火墙只开放80、443和SSH端口SSH改非标准端口并禁用密码登录只用密钥认证。还有一点容易被忽略Django的ALLOWED_HOSTS必须配置正确否则会报400错误。我一开始只写了域名后来发现用IP访问也会被拦调试了半天才想起来这个配置。另外如果用了CDN或者反向代理要正确设置SECURE_PROXY_SSL_HEADER不然Django会认为请求是HTTP的导致重定向循环。3. 环境准备与依赖安装的实操细节3.1 服务器初始化与Python环境我用的Ubuntu 22.04 LTS系统自带Python 3.10但DeskcommCRM的某些依赖可能需要特定版本。稳妥起见我用pyenv装了一个Python 3.11.6隔离系统Python避免把系统工具搞崩。安装pyenv的过程略过无非是装编译依赖、克隆仓库、配置环境变量那几步。创建虚拟环境是必须的不要图省事直接用系统Python。python -m venv venv创建后激活后续所有pip安装都在这个环境里进行。虚拟环境的好处是依赖隔离万一某个包版本冲突删掉重建就行不会影响系统。系统依赖方面PostgreSQL和Redis直接用apt装sudo apt install postgresql redis-server。PostgreSQL装完后要创建数据库和用户这里有个坑Django的createdb权限默认没有需要手动给用户授权。我当时的命令是sudo -u postgres psql CREATE DATABASE deskcomm; CREATE USER deskcomm_user WITH PASSWORD your_password; ALTER ROLE deskcomm_user SET client_encoding TO utf8; ALTER ROLE deskcomm_user SET default_transaction_isolation TO read committed; ALTER ROLE deskcomm_user SET timezone TO Asia/Shanghai; GRANT ALL PRIVILEGES ON DATABASE deskcomm TO deskcomm_user; \q注意时区设置CRM系统里时间字段很多时区不对会导致跟进记录时间错乱。Asia/Shanghai是必须的除非你的团队跨时区工作。3.2 DeskcommCRM源码获取与依赖安装从代码仓库克隆源码后先看requirements.txt。DeskcommCRM的依赖不算多核心就是Django、psycopg2、redis、celery、gunicorn这些。安装时建议加国内镜像源不然某些包下载速度感人pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simplepsycopg2在编译时可能需要libpq-dev和python3-dev如果报错就补装这两个系统包。还有一个常见问题是Pillow安装失败通常是缺少图像处理库sudo apt install libjpeg-dev zlib1g-dev能解决。依赖装完后复制一份settings.py的模板修改数据库连接、Redis地址、SECRET_KEY、ALLOWED_HOSTS这些关键配置。DeskcommCRM的配置项比较清晰注释也全照着改就行。但有一个地方要注意STATIC_ROOT和MEDIA_ROOT的路径要提前创建好并且给足权限不然collectstatic会报错。3.3 数据库迁移与初始数据python manage.py migrate是第一步但在这之前要确保数据库连接正常。我遇到过一个坑PostgreSQL的pg_hba.conf默认配置可能不允许密码登录需要改成md5或scram-sha-256。改完后记得sudo systemctl restart postgresql。迁移完成后创建超级用户python manage.py createsuperuser。然后加载初始数据DeskcommCRM可能提供了一些fixture文件比如默认的权限组、初始字段配置等。如果没有就手动在Admin里配。我建议先把角色权限体系理清楚再录数据不然返工很麻烦。静态文件收集python manage.py collectstatic。这一步会把Admin和所有app的静态文件汇总到STATIC_ROOTNginx直接从这个目录读性能比Django自己服务静态文件好得多。注意STATICFILES_DIRS和STATIC_ROOT不要设成同一个目录否则collectstatic会报错。4. 核心功能模块的配置与调优4.1 权限体系与RBAC的落地DeskcommCRM的权限控制基于Django的Permission系统但原生Permission是模型级别的CRM需要更细粒度的控制比如“销售只能看自己的客户”、“经理能看团队的客户”、“管理员能看全部”。这就需要引入对象级权限或者自定义权限逻辑。我的做法是结合Django的Group和自定义的get_queryset方法。在ViewSet里重写get_queryset根据当前用户的角色过滤数据def get_queryset(self): user self.request.user if user.is_superuser: return Customer.objects.all() if user.groups.filter(name销售经理).exists(): return Customer.objects.filter(teamuser.team) return Customer.objects.filter(owneruser)这种硬编码的方式虽然不够优雅但胜在直观、好调试。如果团队规模大、角色多可以考虑用django-guardian做对象级权限但会增加查询开销需要权衡。还有一个细节Django Admin的权限和前端API的权限是两套体系。Admin用的是has_view_permission这些方法API用的是DRF的permission_classes。配置时要确保两边一致不然会出现“Admin能看但API看不到”的诡异情况。4.2 自定义字段与动态表单CRM系统最怕的就是字段不够用。DeskcommCRM支持自定义字段但实现方式决定了灵活性和性能。我见过两种方案一种是EAV模型Entity-Attribute-Value把字段名和值存到单独的表中另一种是JSON字段把自定义字段塞进一个JSONB列。EAV的优点是查询灵活缺点是关联查询多性能差JSON字段的优点是读写快、结构简单缺点是复杂查询和索引支持弱。DeskcommCRM用的是哪种我没细看但如果是JSON方案PostgreSQL的GIN索引能大幅提升查询性能CREATE INDEX idx_customer_custom_fields ON customer USING GIN (custom_fields);动态表单的前端渲染也是个坑。如果字段是动态的前端就不能写死表单结构需要根据后端返回的字段定义动态生成。我用的是Vue的动态组件根据字段类型文本、下拉、日期、多选渲染不同的输入控件。这里要注意字段校验规则也要动态生成不然前端校验和后端校验对不上用户体验很差。4.3 数据导入与迁移策略从旧CRM迁移数据是自建系统最头疼的环节。我的旧系统能导出CSV但字段名和DeskcommCRM对不上需要做映射。我写了一个Python脚本用pandas做数据清洗和转换然后用Django的bulk_create批量导入。批量导入时要注意第一关掉Django的信号signal不然每导入一条就触发一次信号速度慢得离谱第二用事务包起来出错就回滚避免导入一半留下脏数据第三分批导入每批1000条左右太多会撑爆内存。from django.db import transaction transaction.atomic def import_customers(dataframe): customers [] for _, row in dataframe.iterrows(): customers.append(Customer( namerow[客户名称], phonerow[联系电话], # ... 其他字段映射 )) Customer.objects.bulk_create(customers, batch_size1000)导入完成后要校验数据完整性比如客户数量对不对、关键字段有没有丢失、关联关系有没有断。我当时的做法是随机抽100条和旧系统逐条对比确认无误后再全量切换。5. 部署上线与性能调优实战5.1 Gunicorn与Nginx的配置要点Gunicorn的worker数量有个经验公式(2 * CPU核心数) 1。4核机器就是9个worker。但CRM系统是IO密集型worker可以适当多一些我设了12个。worker class用gevent还是sync如果代码里有同步阻塞操作比如调用外部API用gevent能提升并发但要注意兼容性。我用的sync稳定第一。Nginx配置里client_max_body_size要调大不然上传附件会报413。我设了50M够用了。静态文件用alias指向STATIC_ROOT媒体文件指向MEDIA_ROOT并设置缓存头location /static/ { alias /path/to/static/; expires 30d; add_header Cache-Control public, immutable; } location /media/ { alias /path/to/media/; expires 7d; }还有一个容易忽略的点Nginx的proxy_read_timeout默认60秒如果某个请求处理时间超过60秒比如导出大量数据Nginx会断开连接。我把它调到了300秒并在Django端用Celery做异步导出避免长时间占用worker。5.2 数据库查询优化与索引策略CRM系统慢十有八九是数据库查询的问题。Django的ORM很方便但容易写出N1查询。比如列出客户列表时如果每个客户都要查一次负责人姓名那就是N1。用select_related和prefetch_related能解决大部分问题# 差N1查询 customers Customer.objects.all() for c in customers: print(c.owner.username) # 每次循环都查一次数据库 # 好一次查询搞定 customers Customer.objects.select_related(owner).all()索引方面外键字段Django会自动建索引但经常用于筛选的字段要手动加。比如created_at、status、owner_id这些加索引后查询速度提升明显。但索引不是越多越好每个索引都会拖慢写入速度CRM系统读多写少适当多加几个没问题。慢查询日志要开PostgreSQL的log_min_duration_statement设成1000毫秒超过1秒的查询都记下来定期分析优化。我上线第一个月就是靠慢查询日志发现了好几个性能瓶颈。5.3 缓存与异步任务的引入Redis缓存主要用在两个地方一是页面级缓存比如仪表盘的统计数据变化不频繁但查询复杂缓存5分钟能省很多数据库压力二是会话存储Django的session默认存数据库改成Redis后登录态校验快了一个数量级。Celery处理异步任务比如发送邮件、生成报表、批量导入。配置Celery时要注意broker和backend都用Redis任务序列化用JSONpickle有安全风险。Celery的worker数量不用太多2-4个足够因为异步任务通常不要求实时性。还有一个坑Celery的定时任务用celery beat但beat只能起一个实例多实例会重复执行任务。如果部署了多个应用节点beat要单独部署或者用django-celery-beat把调度信息存数据库避免冲突。6. 踩坑复盘与常见问题速查6.1 部署过程中遇到的典型问题问题一静态文件404。明明collectstatic成功了但页面样式全丢。排查发现Nginx的alias路径末尾少了斜杠/static/和/static的区别导致路径拼接错误。加上斜杠后解决。问题二数据库连接数爆满。上线后不久PostgreSQL报“too many connections”。原因是Gunicorn的worker每个都保持数据库连接12个worker加上Celery和定时任务连接数超了。解决方案是用pgbouncer做连接池或者调低CONN_MAX_AGE让连接及时释放。问题三时区导致的时间错乱。跟进记录的时间比实际时间少了8小时。原因是Django的TIME_ZONE设成了UTC而USE_TZ是True。改成Asia/Shanghai后正常。但要注意数据库里存的时间始终是UTC只是在展示时转换所以不要手动去改数据库里的时间值。问题四CSRF验证失败。前端提交表单时报403。原因是Nginx转发时没有传递X-Forwarded-Proto头Django认为请求是HTTP的CSRF cookie设置失败。在Nginx配置里加上proxy_set_header X-Forwarded-Proto $scheme;解决。6.2 性能与稳定性问题排查页面加载慢。用Django Debug Toolbar定位发现某个列表页执行了200多次查询。优化get_queryset加上select_related和prefetch_related后降到5次以内。内存泄漏。运行几天后服务器内存被吃满。用memory_profiler排查发现某个自定义的导出功能把大量数据加载到内存里。改成流式输出用StreamingHttpResponse分块返回内存占用稳定在50M以内。Celery任务堆积。邮件发送任务越积越多。原因是SMTP服务器限流任务失败后不断重试。给任务加上max_retries3和retry_backoffTrue失败后指数退避重试避免雪崩。6.3 数据安全与备份策略自建系统最大的风险是数据丢失。我的备份策略是每天凌晨全量备份PostgreSQL用pg_dump导出压缩文件每小时增量备份用WAL归档。备份文件同步到另一台服务器和对象存储保留最近30天。恢复演练很重要。我每个月做一次恢复测试从备份文件恢复到测试环境确认数据完整可用。这个习惯救过我一次——有一次服务器硬盘故障靠备份在2小时内恢复了全部数据。权限方面数据库密码、SECRET_KEY、API密钥这些敏感信息不要硬编码在代码里用环境变量或者.env文件管理。.env文件要加入.gitignore避免提交到代码仓库。7. 从能用 to 好用我的二次开发实践7.1 与企业微信/钉钉的集成CRM系统如果只能网页访问销售在外跑客户时很不方便。我把DeskcommCRM和企业微信做了集成销售在企业微信里就能查客户、录跟进、看商机。实现方式是用企业微信的Webhook和APIDjango端提供REST接口企业微信端用自建应用调用。集成的关键是身份映射。企业微信的用户ID和CRM的用户ID要对应起来我在User模型里加了一个wechat_work_id字段登录时用企业微信的OAuth2获取用户信息匹配到CRM用户后自动登录。这样销售不用记两套账号密码体验好很多。7.2 自动化工作流与提醒CRM里有很多重复性工作比如“客户三天没跟进要提醒”、“合同到期前一周要通知”。这些用Celery的定时任务实现每天跑一次扫描符合条件的记录发送提醒。提醒渠道支持站内信、邮件、企业微信。站内信用Django的django-notifications邮件用django.core.mail企业微信用Webhook。提醒规则做成可配置的管理员在后台就能改不用改代码。7.3 报表与数据看板销售团队需要看漏斗、业绩排名、回款趋势这些报表。我用Django ORM做聚合查询前端用ECharts渲染。报表数据缓存到Redis避免每次刷新都查数据库。有一个性能技巧报表查询尽量在数据库层完成不要拉到Python里再计算。比如“本月每个销售的合同总额”用annotate和Sum一次查询搞定from django.db.models import Sum report Contract.objects.filter( sign_date__monthcurrent_month ).values(owner__username).annotate( totalSum(amount) ).order_by(-total)这样比循环查询快几十倍数据量大的时候差距更明显。8. 写在最后一些个人体会这套系统跑了大半年中间经历过两次服务器迁移、一次数据库版本升级、无数次小修小补。最大的感受是自建CRM不是一锤子买卖而是一个持续维护的过程。你需要定期看日志、优化查询、更新依赖、修补安全漏洞。如果团队里没有人愿意承担这个维护责任那还是用SaaS省心。但如果你有技术能力自建带来的掌控感是SaaS给不了的。数据在自己手里想怎么改就怎么改想集成什么就集成什么不用等产品经理排期不用看服务商脸色。这种自由值得付出那些维护成本。最后分享一个小技巧部署时用Docker Compose把PostgreSQL、Redis、Django、Nginx全部容器化迁移和扩容会方便很多。我后来把整套环境用Docker重写了一遍从零部署到上线只要半小时比第一次折腾两天快多了。如果你还没用Docker建议花点时间学一下对自建系统来说这是性价比最高的技能投资。