热榜开源CRM选型与落地：Odoo、sales-crm部署开发和数据迁移避坑

上周三凌晨刷 GitHub Trending，又看到一个 CRM 项目挂在榜上。粗粗一数，最近大半年里这个品类至少露脸过四五回，前面是某个围绕 Odoo 生态做行业插件的仓库，再往前是一套前后端分离的轻量销售系统，名字就叫 sales-crm 或者 xxx-crm 这类。做企业软件这行久了，对榜单的敏感度其实已经降下来，但同一个品类反复往上冲，就值得停下来想一想：CRM 这门老生意，为什么还能持续吸引人开源、吸引人 star、吸引人真的拿去用。

这篇文章想聊的不是"哪个 CRM 最好"，那种问题没有答案。我想聊的是更实际的东西：当你在热榜上看到一个开源 CRM，脑子里应该蹦出哪几个判断；Odoo 这种"全家桶"型平台和 sales-crm 这种"单点突破"型项目，底层设计哲学差在哪；真要把一套东西部署到能用的程度，容器拓扑、worker 数量、反向代理、备份策略这些细节该怎么定；以及二次开发和数据迁移这两道坎上，我踩过的、见过的坑。适合正在做选型的技术负责人看，也适合打算自己搭一套销售管理的小团队，以及想读源码学企业软件架构的开发者——不管你是刚接触 CRM 概念的新手，还是做过几年 ERP 实施的老手，下面这些内容应该都能对得上号。

1. 热榜上的开源CRM越来越多，这门生意到底在卖什么

1.1 CRM的本质不是功能清单，而是流程约束

很多人第一次接触 CRM，看到的是功能列表：客户管理、线索管理、商机管理、合同管理、报表。于是很容易得出一个错误结论——这东西不就是几张表加增删改查吗，我自己两周也能写一个。真上手之后才发现，难点从来不在功能，而在约束。

一套 CRM 真正在干的事，是把销售过程里那些模糊的、靠人脑记的动作，变成系统里带状态、带时间戳、带责任人的记录。线索从哪来、谁接的、多久没跟进、为什么丢了、赢单率多少，这些问题的答案必须能从数据里查出来，而不是靠销售在周会上口述。所以 CRM 的核心资产其实是三样东西：一套数据模型（客户、联系人、线索、商机、报价、活动之间怎么关联）、一套状态机（商机在哪个阶段、阶段推进的条件是什么）、一套权限体系（谁能看谁的数据、销售能不能改已成交的报价）。

这三样东西里，数据模型决定了系统能不能长大，状态机决定了销售愿不愿意用，权限体系决定了老板敢不敢把真实数据放进去。开源项目之所以在这个领域反复涌现，就是因为这三样东西有大量的共性，重复造轮子的成本被人一遍遍摊薄了。你去看任何一个像样的开源 CRM，它的表结构里必然有 lead、opportunity、pipeline stage、activity 这几类概念，差异只在于命名和粒度。

1.2 三类开源CRM的商业底盘，决定了你拿到的是什么

看一个开源 CRM 能不能长期用，我会先判断它属于哪一类商业底盘，这个比读功能文档有用得多。

这个判断方法很土，但极其实用。Odoo 属于第一类的典型，社区版已经把销售、库存、财务、制造串起来了，企业版补充的是多公司合并报表、完整的会计本地化、Studio 可视化定制这些。sales-crm 这类轻量项目更接近第二类，通常由一个团队或一两个核心维护者推动，聚焦在销售管道这一件事上，代码量小、上手快、改起来没心理负担，但你要指望它帮你管库存和开票，基本没戏。

我在做选型时有个习惯：先看仓库的 release 页面和 commit 频率，再看 issue 里维护者的回复密度，最后才看 README 的功能截图。README 谁都会写，但一个半年没发版、issue 里全是"any update"的项目，功能吹得再全也不敢往生产上放。

1.3 为什么榜单偏爱CRM，而不是别的企业软件

企业软件的品类很多，财务、HR、项目管理、工单、BI，但榜单上出现频率最高的往往是 CRM 和项目管理。原因不难猜：这两个品类的使用者本身就是互联网重度用户，开发者自己就在用，做完能立刻自测、立刻发朋友圈；同时它们的边界相对清晰，一个销售管道可以独立于财务系统存在，而一套总账系统很难脱离业务单据单独跑起来。

反过来说，这也意味着榜单热度和你企业的实际需求之间存在偏差。热榜反映的是"开发者觉得有意思"，不是"你的销售团队会用"。我见过不止一个团队，看榜单选了一套项目，部署完发现没有中文界面、没有发票联查、导出的报表格式对不上老板的要求，最后又退回 Excel。这个落差在选型阶段就该预判到。

2. Odoo这条"全家桶"路线：强在语义统一，卡也在语义统一

2.1 一个ORM吃掉所有业务：Odoo的模型哲学

Odoo 最核心的设计不是那些看得见的模块，而是它那套自有的 ORM 和模型系统。所有的业务对象——客户、线索、订单、发票、库存移动——都继承自 models.Model，共享同一套字段定义、同一套权限校验、同一套视图渲染、同一套审计日志。你在销售模块里点开一个客户，能直接跳到他名下的所有订单和发票，靠的不是接口对接，而是它们在同一个数据库、同一套关联关系里。

这套设计带来的好处是语义统一。客户这个概念在整个系统里只有一个定义，就是 res.partner。销售、采购、会计、项目模块全部引用它，不会出现"销售系统里的客户"和"财务系统里的客户"对不上的情况。我在做多系统集成的项目时，最头疼的就是主数据不一致，而 Odoo 从架构上就把这个问题消掉了。

代价也很直接：学习曲线陡。你得先理解 res.partner 既是客户又是供应商又是联系人，理解 crm.lead 和 sale.order 之间的转换关系，理解模型、视图、动作、菜单这四层是怎么串起来的，才能真正动手改东西。新手最常见的困惑是"我加了个字段，为什么界面上看不到"——因为字段定义、视图引用、权限授权是三件独立的事，少做一步都不行。

2.2 模块化与视图继承：改别人的代码而不碰别人的代码

Odoo 最优雅的地方是视图继承机制。你想在商机表单上加一个"获客渠道"字段，不需要去改官方模块的 XML 文件，而是新建一个自己的模块，用 inherit_id 指向原视图，然后指定插入位置。官方升级的时候，你的改动还在，不会被覆盖。这是它能承载大量第三方行业模块的根本原因。

<?xml version="1.0" encoding="utf-8"?> <odoo> <record id="view_crm_lead_form_channel" model="ir.ui.view"> <field name="name">crm.lead.form.channel</field> <field name="model">crm.lead</field> <field name="inherit_id" ref="crm.crm_case_form_view_oppor"/> <field name="arch" type="xml"> <field name="partner_name" position="after"> <field name="x_channel_source" required="1"/> </field> </field> </record> </odoo>

配套的模型扩展同样走继承：

from odoo import models, fields class CrmLead(models.Model): _inherit = 'crm.lead' x_channel_source = fields.Selection( selection=[ ('web', '官网表单'), ('offline', '线下活动'), ('referral', '老客户转介绍'), ], string='获客渠道', tracking=True, index=True, ) x_lead_score = fields.Integer(string='线索评分', default=0)

这里有个约定俗成的规矩：自己加的字段一律用 x_ 前缀。原因很实际——Odoo 的字段名在同一个模型里是全局的，第三方模块之间撞名会导致加载失败，而官方和社区都默认把 x_ 段留给用户自定义。我见过一个项目因为两个行业模块都定义了叫 channel 的字段，升级时直接起不来，排查了大半天。

2.3 全家桶的真实代价：升级、性能与心智负担

全家桶不是白给的。第一重代价是升级。Odoo 的大版本之间 API 变动不算小，从 14 到 16 再到 17、18，视图结构、前端框架、ORM 的一些行为都在演进，你自己写的模块几乎一定要跟着改。三年不升级，等到不得不升的时候，工作量会非常可观。我的建议是跟着 LTS 版本走，每次大版本升级预留出至少两周的回归测试时间，别指望一键升级。

第二重代价是性能调优的复杂度。因为所有模块共用一个数据库、一套 worker 进程，任何一个模块里的慢查询都可能拖垮整个系统。一个典型的例子是：某个行业模块在商机列表上加了个 computed 字段，每次列表刷新都要对几万条记录做聚合，页面直接卡死。这类问题在单体架构里会被放大，排查的时候得用 PostgreSQL 的 pg_stat_statements 去找慢 SQL，再反推是哪个字段惹的祸。

第三重是心智负担。新同事接手一套 Odoo 项目，光搞清楚现有代码里哪些是官方模块、哪些是二次开发、二次开发之间谁依赖谁，可能就要花上一周。所以我在每个项目里都会强制维护一份模块清单，标明每个自研模块的用途、依赖、以及它改了官方的哪些视图，这份清单在交接和升级时的价值远超它的维护成本。

3. sales-crm这类轻量派：把销售管道做到极致的取舍

3.1 单点突破的架构共性

轻量级 CRM 项目虽然实现各异，但从架构上看有几个高度相似的共性。它们通常采用前后端分离的结构，后端提供 REST 或 GraphQL 接口，前端是一个独立的单页应用；数据模型被压得很扁，一般就是账号、联系人、公司、商机、阶段、活动这么几张核心表，不做多公司、不做多币种、不做复杂的税率计算；权限模型也相对简单，通常是"角色 + 数据归属"两层，很少出现按字段级别的精细控制。

这种架构的优势非常明显：部署轻。一个 Docker Compose 拉起来，前后端加一个数据库，内存占用可能还不到 Odoo 的三分之一，一台 2 核 4G 的小机器就能跑得挺顺。改造也轻，你想加个"线索来源"字段，前端改一个表单组件、后端加一个字段、数据库跑一条 migration，半小时能搞定，不需要理解什么视图继承和权限组。

我个人的经验是，这类项目最适合的场景是：团队规模在 20 人以内、销售流程相对标准、不需要跟库存和财务深度打通、有人能写代码维护。在这种场景下，用 Odoo 属于典型的大炮打蚊子，配置成本远高于收益。

3.2 轻量的红利与隐性账单

红利说完了，说说账单。轻量项目最大的隐性成本是"长大以后的迁移"。业务跑两年，老板突然说要把合同和开票也管起来，这时候你会发现当初那套精简的表结构根本撑不住——没有产品目录、没有价格表、没有多币种、没有税务规则，硬加的话等于重写。

第二个隐性成本是报表能力。轻量项目的看板通常做得漂亮，漏斗图、阶段分布、转化率一应俱全，但一旦老板要"按销售区域、按产品线、按季度交叉分析"，你就得自己写 SQL 或者接一个 BI 工具。Odoo 在这方面有先天优势，因为它所有模块共享一套数据模型，透视视图和分组统计是开箱即用的。

第三个是数据安全与审计。轻量项目往往在字段级权限和操作日志上做得比较浅。如果你的行业有合规要求，需要知道"谁在什么时候改了这条商机的金额"，就得自己补一套审计表。这件事不难，但很容易被忘掉，等到出事再补就晚了。

3.3 什么时候该选轻，什么时候必须选重

我给一个相对粗暴但好用的判断标准，分三个问题问自己。

第一个问题：三年内，销售之外还有什么业务要进系统？如果答案里出现了库存、采购、生产、财务核算中的任何一个，直接考虑 Odoo 这类平台，别犹豫。因为这些东西之间的耦合远超想象，先用轻量系统再外挂，最后一定会变成两套主数据互相打架。

第二个问题：团队里有没有能长期维护代码的人？如果没有，轻量项目的优势会迅速变成劣势——出问题没人修，版本更新不敢跟，最后变成一个谁都不敢碰的黑盒。这种情况下，选一个有商业支持的开源版本，或者干脆用 SaaS，反而更稳妥。

第三个问题：你的销售流程有多特殊？如果流程非常标准（就是标准的线索-商机-报价-成交），轻量项目足够；如果流程里有大量分支，比如需要多级审批、需要按客户等级走不同折扣策略，那 Odoo 的工作流和审批配置能力会省下大量开发时间。

4. 从零跑起来：容器拓扑、workers计算与反向代理

4.1 最小可用拓扑与配置文件

不管选哪个项目，第一步都是把它跑起来。以 Odoo 为例，一套最小可用的生产拓扑是三个角色：PostgreSQL、Odoo 应用、反向代理。用 Docker Compose 描述大概是这样：

services: db: image: postgres:15 restart: always environment: POSTGRES_DB: postgres POSTGRES_USER: crm POSTGRES_PASSWORD: change_me_db volumes: - db-data:/var/lib/postgresql/data command: > postgres -c shared_buffers=1GB -c work_mem=16MB -c maintenance_work_mem=256MB -c max_connections=200 odoo: image: odoo:17 restart: always depends_on: - db ports: - "127.0.0.1:8069:8069" volumes: - odoo-data:/var/lib/odoo - ./addons:/mnt/extra-addons - ./odoo.conf:/etc/odoo/odoo.conf:ro volumes: db-data: odoo-data:

几个细节值得单独说。端口绑定写成 127.0.0.1:8069 而不是 8069:8069，意思是只允许本机访问，外部流量必须经过反向代理，这是最基本的一道防线。db-data 和 odoo-data 用命名卷，别图省事挂到宿主机某个随手建的目录上，后面做备份和迁移时会感谢自己。addons 目录单独挂载，自研模块放这里，容器重建不丢代码。

配置文件大概是这个形态：

[options] admin_passwd = change_me_master db_host = db db_port = 5432 db_user = crm db_password = change_me_db addons_path = /mnt/extra-addons,/usr/lib/python3/dist-packages/odoo/addons workers = 9 max_cron_threads = 2 limit_memory_soft = 805306368 limit_memory_hard = 1073741824 limit_time_cpu = 60 limit_time_real = 120 proxy_mode = True list_db = False

这里有个新手百分之百会搞混的点：admin_passwd 不是管理员用户的密码，它是数据库管理器（就是 /web/database/manager 那个页面）的超级密码，用来建库、删库、备份库。真正的 admin 用户密码是在初始化数据库时设置的，两码事。我见过有人把 admin_passwd 设成 123456 然后以为万事大吉，结果整个库被人一键删掉。

list_db = False 也是必须的，它会隐藏数据库列表，让别人没法从登录页看到你有哪些库。proxy_mode = True 则告诉 Odoo 它跑在反向代理后面，否则生成的链接和客户端的真实 IP 都会出问题。

4.2 workers到底开几个：一次按内存倒推的计算

Odoo 的 workers 参数是最容易被随手填错的地方。常见的推荐公式是workers = CPU 核数 × 2 + 1，这个公式的出发点是充分利用 CPU 时间片，但它忽略了一个致命约束：内存。

每个 worker 进程都有一个内存软上限 limit_memory_soft 和一个硬上限 limit_memory_hard，超过软限会在处理完当前请求后被回收，超过硬限会被直接 kill。默认值是 2GB 软限、2.5GB 硬限。如果你按公式在 8 核机器上开 17 个 worker，理论最坏内存占用是 17 × 2GB = 34GB，再加上 PostgreSQL 和系统本身，16G 的机器会直接被 OOM Killer 屠戮，表现就是服务莫名其妙地重启、日志里出现一堆 worker 被杀掉的记录。

所以正确的做法是反过来算：先用内存定上限，再用 CPU 校核。

以 8 核 16G 为例推一遍：留给 PostgreSQL 大概 4G，留给系统和反向代理 2G，剩给 Odoo 的约 10G。如果 soft 限设 768MB，理论能撑 13 个 worker，但实际运行时会有峰值波动，取 9 个比较安全，同时 CPU 利用率也够了。limit_memory_soft 的单位是字节，768MB 要写成 805306368，很多人以为可以直接写 768，结果填进去变成 768 字节，所有 worker 刚启动就被杀掉，日志里全是 memory limit exceeded。

max_cron_threads 建议设成 2。定时任务线程太多会和应用 worker 抢资源，太少会导致定时任务排队积压，2 到 4 之间是个合理区间。

4.3 反向代理与实时通信的配置要点

反向代理这块，最容易翻车的是实时通信。较新版本的 Odoo 用 WebSocket 处理即时通知和讨论模块，如果代理没配好 Upgrade 头，表现就是页面能打开、数据能加载，但消息列表不刷新、通知不弹。配置大致如下：

upstream odoo_backend { server 127.0.0.1:8069; keepalive 32; } server { listen 443 ssl; server_name crm.example.com; client_max_body_size 64m; location /websocket { proxy_pass http://odoo_backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_read_timeout 720s; } location / { proxy_pass http://odoo_backend; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_redirect off; proxy_read_timeout 720s; } }

client_max_body_size 一定要调大，默认的 1M 会导致上传产品图片、导入 CSV 附件时直接 413。proxy_read_timeout 也别用默认的 60 秒，因为报表导出和大批量导入很容易超过这个时间，超时后前端会收到一个空响应，用户完全不知道发生了什么。

4.4 备份这件事，数据库和文件存储必须成对

这是我认为最值得强调的一条：Odoo 的数据分为两部分，一部分在 PostgreSQL 里，另一部分是 filestore——所有附件、图片、导入的原文件都存在文件系统上，路径通常是/var/lib/odoo/.local/share/Odoo/filestore/<数据库名>。

只备份数据库不备份 filestore，恢复之后所有附件都会变成裂图，单据点开一片空白。只备份 filestore 不备份数据库，那就更不用说了。而且两者必须在同一个时间点上备份，否则会出现数据库里有一条附件的记录、filestore 里却没有对应文件的情况。

#!/bin/bash set -euo pipefail DB_NAME="crm_prod" STAMP=$(date +%F_%H%M) BACKUP_DIR="/data/backup" pg_dump -Fc -h 127.0.0.1 -U crm "${DB_NAME}" > "${BACKUP_DIR}/${DB_NAME}_${STAMP}.dump" tar czf "${BACKUP_DIR}/filestore_${STAMP}.tar.gz" \ -C /var/lib/odoo/.local/share/Odoo/filestore "${DB_NAME}" find "${BACKUP_DIR}" -type f -mtime +14 -delete

恢复的时候一定要先建一个空库，把 dump 恢复进去，再把 filestore 解压到同名目录，顺序错了同样会丢附件。这个流程我建议至少演练一次，不演练的备份基本等于没有备份。

5. 二次开发第一道坎：字段、视图、权限与阶段流

5.1 加一个字段要走完的四步

前面提过，新手最常见的困惑是"字段加了但界面上看不到"。完整的链路是四步，少一步都不行。

第一步是模型层定义字段，也就是前面那段_inherit = 'crm.lead'的代码。第二步是视图层引用，通过 inherit_id 把字段插到表单的某个位置。第三步是权限层授权，在 ir.model.access 里给你的模块声明对 crm.lead 的读写权限，否则非管理员用户登录后字段是只读甚至不可见的。第四步是升级模块让改动生效，-u your_module或者界面上点升级。

id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink access_crm_lead_channel_user,crm.lead.channel.user,model_crm_lead,sales_team.group_sale_salesman,1,1,1,0

权限这块有个原则我一直在坚持：能用组权限解决的，绝不用记录规则；能用记录规则解决的，绝不动代码逻辑。因为权限配置是声明式的，出了问题容易查；写在 Python 里的权限判断是命令式的，散落在各个方法里，半年后没人记得住。

5.2 看板阶段与销售管道的数据结构

销售管道的核心是 crm.stage 这个模型。它有三个关键字段：sequence 决定阶段顺序，is_won 标记这是不是赢单阶段，team_id 决定这个阶段属于哪个销售团队。商机通过 stage_id 关联到阶段，看板视图按 stage_id 分组显示，拖拽卡片就是修改 stage_id。

这里有个容易被忽略的设计点：阶段是有团队归属的。如果你的公司有两套完全不同的销售流程，比如大客户直销和渠道分销，正确做法是建两个销售团队，各自配一套阶段，而不是在一套阶段里塞一堆判断。我见过一个项目把十几个阶段堆在一条管道上，销售每次拖卡片都要找半天，最后大家干脆不更新阶段了，数据全废。

阶段变更时通常还要联动修改商机的 probability（成交概率）。Odoo 默认会根据阶段自动带出概率，但很多团队会覆盖这个逻辑，改成按阶段停留时长、跟进次数动态计算。这种做法听起来很智能，实践中要小心——如果算法不透明，销售会觉得系统在瞎猜，反而不信任它。我的建议是前期就用固定概率，等积累了半年真实数据再考虑做模型。

5.3 记录级权限：比模型级权限更容易出事的地方

模型级权限管的是"这个组的用户能不能读这个模型"，记录级权限管的是"能读哪些记录"。后者出事概率高得多，因为它涉及业务语义。

<record id="rule_crm_lead_own_only" model="ir.rule"> <field name="name">销售只能看自己名下的商机</field> <field name="model_id" ref="crm.model_crm_lead"/> <field name="domain_force">[('user_id', '=', user.id)]</field> <field name="groups" eval="[(4, ref('sales_team.group_sale_salesman'))]"/> </record>

这条规则的意思是：销售组的用户只能看到 user_id 等于自己的商机。问题来了——销售经理也在销售组里，他也只能看到自己名下的。这时候需要再加一条不带 groups 的全局规则，或者给经理单独建一个组并配一条不加限制的规则。

Odoo 记录规则的组合逻辑要记清楚：不带 groups 的全局规则与组规则之间是"与"的关系，同一个组内的多条规则之间是"或"的关系。这个逻辑如果搞反了，结果就是要么所有人都看不到数据，要么所有人能看到所有数据，两种都很要命。上线前一定要用不同角色的账号各登录一遍，把"能看什么、能改什么、不能看什么"逐条验证，别只看管理员视角。

6. 数据迁移：字段映射只是最表层的活

6.1 去重键与外部ID：迁移的地基

从 Excel 或者老系统往 CRM 里导数据，很多人第一反应是做一个字段映射表，然后打开导入界面往里灌。这么做十有八九会翻车，因为忽略了最关键的一步：确定去重键。

CRM 里最怕的就是同一个客户存在多条记录。一旦重复，商机归属就乱了，报表也跟着错。所以迁移前必须想清楚：用什么来唯一标识一个客户？手机号？统一社会信用代码？还是老系统里的 ID？我的做法是强制在目标表里加一个外部 ID 字段，把老系统的唯一标识原样搬过来，导入时用这个字段做匹配，存在就更新、不存在就新建。

Odoo 的导入工具支持"外部标识"（External ID）这个概念，用法是在 CSV 里加一列叫id，值写成__import__.customer_001这种形式。这个机制的好处是幂等——同一份文件导两次不会产生重复数据，第二次会走更新逻辑。做迁移的时候善用它，能省掉大量手工去重的时间。

6.2 时区、编码、布尔值：三个稳定的雷

不管迁什么系统，这三个问题几乎必然出现，提前处理好能省下一整天。

时区。Odoo 数据库里所有 datetime 字段存的都是 UTC，界面上按用户配置的时区显示。如果你从老系统导出的时间是北京时间，CSV 里直接写2024-05-20 14:30:00，导进去之后会变成 UTC 的 14:30，界面上显示成 22:30，全部偏移 8 小时。解决办法是在导入前统一减 8 小时，或者用 Odoo 的导入模板里对 datetime 做显式转换。这个问题最坑的地方在于它不会报错，数据安安静静地错着，等有人发现商机创建时间对不上，可能已经过去一个月了。

编码。CSV 必须是 UTF-8，且不能带 BOM。用 Excel 另存为 CSV 的时候，中文环境默认会存成 GBK，导入后全是乱码。更隐蔽的是 BOM 头，它会让第一列列名变成\ufeff客户名称，导入工具找不到这一列，直接报"列不存在"。处理办法是用文本编辑器确认一下编码，或者用脚本统一转一遍。

布尔值。不同系统对布尔值的表示五花八门，True/False、1/0、是/否、Y/N 都见过。Odoo 导入时认 True/False 和 1/0，其他形式会被当成 False 静默处理。所以导入前一定要把布尔列标准化，不然会出现"所有客户都变成了非重点客户"这种诡异现象。

6.3 迁移后的一致性校验清单

数据导完不等于迁移完成。我每次迁移都会跑一遍下面这套校验，花不了多少时间，但能提前发现绝大多数问题。

最后一项特别值得单独做。附件丢失在迁移里太常见了，而且往往是最晚被发现的——因为日常使用中大家不会天天点开半年前的老附件。抽检 20 条，能覆盖大部分路径问题。

7. 选型对照表与五类翻车现场

7.1 一张表看清两类项目的边界

这张表不是让你二选一，而是帮你在做决策时把成本摊开看。很多人只比较功能列表，忽略了部署资源、升级成本、人员要求这些长期投入，结果选了个看起来很全的系统，用了半年发现维护不动。

7.2 五个我见过或经历过的翻车现场

第一个，把演示数据带进生产。初始化数据库时勾了"加载演示数据"，产品目录里几百个假产品、客户列表里一堆虚构公司，上线后没人敢删，因为分不清哪些是真的。正确做法是生产库初始化时坚决不加载演示数据，需要测试就单独建一个测试库。

第二个，直接在生产库上开开发者模式加字段。界面上点几下确实能加字段，但这种字段只存在于数据库里，没有任何代码记录，换台机器部署、或者从备份恢复，字段就没了。所有自定义字段必须落在模块代码里，这是铁律。

第三个，cron 任务把数据库锁死。有人写了个定时任务，每分钟遍历所有商机做评分计算，数据量上来之后这个任务跑一次要三分钟，于是下一分钟的又起来了，最后数据库连接池被占满，整个系统卡死。定时任务一定要加互斥锁，并且控制频率和数据量。

第四个，附件目录权限没配好。容器重建之后 filestore 目录属主变了，Odoo 进程读不了，所有附件 404，但数据库里记录还在，看起来像是文件丢了。解决办法是挂载卷的时候就把属主固定好，别依赖默认值。

第五个，也是最常见的：系统搭得挺好，销售不用。这个问题技术解决不了。我参与过的一个项目，功能做得非常完善，字段、流程、报表全都定制过，上线三个月后数据录入率不到 30%。后来复盘发现，根本原因是字段太多——一个商机表单有 40 多个必填项，销售宁可在微信里记也不愿意填。最后砍到 12 个字段，录入率才慢慢上来。

8. 关于"榜单量产企业软件"的几句实话

回到最开始那个观察。热榜上开源 CRM 越来越多，这件事本身说明不了哪个项目更好，它说明的是企业软件的开发门槛确实在降低——成熟的 ORM、现成的前端组件库、标准的容器化部署方案，让一个三五人的小团队也能在几个月内做出一个能跑起来的 CRM。这是好事。

但我这几年做下来，越来越确信一件事：CRM 项目的成败，八成不在选型，不在技术栈，而在"字段设计"和"使用习惯"这两件特别不性感的事上。字段设计决定了系统能不能承载业务，使用习惯决定了数据是不是真的。技术选型错了，最多是多花几周重来；字段设计错了，数据迁移的代价会跟着你好几年；使用习惯培养不起来，再贵的系统也只是个摆设。

所以如果你现在正盯着榜单上某个项目犹豫，我的建议是：先用半天时间把最核心的 10 个字段列出来，再找两个一线销售聊聊他们每天到底在记什么，最后才去看技术方案。这个顺序反了，后面所有的努力大概率都要打折扣。我在实际项目里见过太多团队跳过前两步直接开始部署，然后在第三个月开始返工，那个成本比一开始多花两天想清楚要高出一个量级。