Odoo：开源 ERP 与业务管理应用平台完全指南

评估开源 ERP 的团队，大多在两件事上纠结：功能够不够用，以及用久了会不会被厂商锁死。Odoo 对第二个问题的回答比较直接——核心框架以 LGPL-3.0 发布在 GitHub 上，任何人可以自托管、修改、二次分发；对第一个问题，它的答案是另一个形态：不是把 ERP 当成一个整体产品，而是把 CRM、销售、采购、库存、制造、财务、人力资源各自做成独立应用，装在同一个数据底座上，需要哪个装哪个。

这套思路来自一条足够长的演进线。2005 年比利时开发者 Fabien Pinckaers 发布 TinyERP，后改名 OpenERP，2014 年更名为 Odoo 并沿用至今（官方 Docker 镜像的描述至今写着 “formerly known as OpenERP”）。二十年间项目从一个开源 ERP 长成了应用套件：截至 2026-10-03，GitHub 上 odoo/odoo 仓库有 54,804 Stars、33,918 Forks，主语言 Python，默认分支 20.0——Odoo 20 于 2026 年 9 月 24 日在年度大会 Odoo Experience 上发布，仓库保持每天多次提交的活跃度。

本文基于当日仓库读数、源码与官方文档，拆解它的架构、版本策略与商业边界，最后给出采用判断。

先分清三样东西：社区版、企业版、云服务

谈 Odoo 之前先画一张地图，因为"Odoo"这个词在官方语境里至少指三样东西：

官方版本对比页对社区版与企业版关系的原话是：“Odoo Community is the core upon which Odoo Enterprise is built”——社区版是地基，企业版在地基之上加了一层闭源应用。加在上面的主要有：综合财务会计（总账、银行对账、分析会计、账单 OCR）、工资 Payroll、Documents/Sign/Spreadsheet 等办公套件、低代码定制工具 Studio、原生移动 App，以及制造排程、条码仓储等加强模块。

一个常见的误解是"开源版和企业版差不多，就是多了个 logo"。从对比表看，差异集中在会计深度与运营加强上，对以财务为中心的企业来说这恰恰是采购决策的重心。评估时值得把"我的业务能不能只靠社区版的 Invoicing 模块运转"当作第一个测试问题。

架构：一个框架 + 一层模块

仓库结构只有两个主干，对应两层职责：

odoo/          # 框架层：ORM、HTTP、模块加载、ORM 字段系统、服务、升级工具
addons/        # 模块层：642 个官方模块目录（odoo/odoo 20.0 分支实测）
odoo-bin       # 命令行入口：启动实例、初始化数据库、安装模块

框架层（odoo/ 包）提供所有业务应用共享的基础设施：ORM 引擎（odoo/orm/）、HTTP 服务与视图渲染（odoo/http/）、模块加载机制（odoo/modules/）、权限与多公司模型（addons/base 中的 ir_access、res_groups、res_company），以及国际化支持（每个模块自带 i18n/ 翻译目录，base 模块内置语言与货币模型）。

模块层（addons/）在 20.0 分支有 642 个一级目录。这个数字容易被误读——它不是"642 个业务应用"。构成大致是：约 229 个 l10n_* 国家本地化模块（各国会计科目表、税制、电子发票格式），45 个 pos_* 零售终端模块，23 个 payment_* 支付渠道适配，56 个 web* 前端组件模块，20 个 test_* 测试模块，剩下的才是 CRM、销售、库存这类业务应用本体。理解这个构成对估算定制工作量很重要：改一个国家的税务逻辑，通常意味着动对应的 l10n_ 模块而不是核心。

值得一提的是业务流程的驱动机制。Odoo 早期版本内置一套 workflow 引擎，v11 起已移除；现在的跨模块业务流转由三种机制承担：服务端动作（ir.actions.server，可配置的自动化操作）、自动化规则（base_automation 模块，在特定模型事件上触发）、计划任务（ir_cron）。读旧教程时看到"workflow 配置"的内容，基本可以判定过时。

模块怎么连起来：manifest 依赖链

每个模块目录下的 __manifest__.py 声明它的名字、分类和依赖。模块间的联动不是隐式的数据同步，而是显式的依赖安装：装 sale_stock（销售与仓储桥接模块）会自动连带安装 sale、stock_account 及其全部上游依赖。这种"应用即依赖图"的设计，是 Odoo 能把几十个应用拼成一个 ERP 而不散架的关键。

一张销售订单的完整流转

抽象机制看一张单据怎么走。销售员在 CRM 里把线索转成报价单（crm → sale），客户确认后订单进入执行：

1. 发货控制：sale_stock 模块（manifest 自述 “Quotation, Sales Orders, Delivery & Invoicing Control”）接管订单，按订单行在库存模块生成发货单（delivery order），支持一次或分批交付。
2. 库存计价：仓库发货时，stock_account 模块（自述 “makes the link between the ‘stock’ and ‘account’ modules”）为库存移动生成会计分录，完成出库成本结转。
3. 开票：按订单上选择的开票策略（按交付、按数量等），sale_stock 控制何时生成客户发票，发票落入 account 模块的会计账套。
4. 报表联动：由于全程共用同一个数据模型，销售分析、库存价值、应收账款读的是同一套底层数据，不需要对账接口。

这条链路上每个环节都是独立模块，企业可以只用其中一段——比如只装 sale 做报价管理不开票，或者只装 account 记账。这也是 Odoo 与传统 ERP 最实际的差别：模块边界即部署边界。

版本策略：一年一大版，滚动维护四个版本

Odoo 每年发布一个大版本，惯例是 9 月末的 Odoo Experience 大会（Odoo 19 于 2025 年 9 月、Odoo 20 于 2026 年 9 月发布）。仓库里保留着从 5.0 到 20.0 的全部 17 个版本分支（外加 6.1 这个特例和大量内部 saas-* 分支），但"存在分支"不等于"仍在维护"——判断依据应看仓库的 SECURITY.md，其支持版本表当前列出 16.0、17.0、18.0、19.0 四个受支持版本，15.0 及更早版本已停止安全维护（20.0 刚发布，该表尚未更新）。

这给自托管用户划出一条硬边界：停在超出窗口的版本上，意味着安全修复也没有。升级跨越大版本涉及数据迁移，官方提供付费的数据库升级服务，社区也有迁移工具——评估时应把"每年跟版"或"买升级服务"计入运维成本。

采用建议：谁适合，谁该谨慎

成本口径（官网定价页，2026-10 读数，按年付）：社区版自托管免费；One App Free 档 €0（单应用、不限用户、Odoo Online 托管）；Standard 档 €19/用户/月（全部应用、Odoo Online）；Custom 档 €35/用户/月（在 Online 之外增加自托管企业版或 Odoo.sh 私有云两个选项）。月付价格更高（Standard €24.90、Custom €44.90）。创业团队用 One App Free 起步试单模块是零成本路径。

适合：需要 CRM+库存+财务一体化、且有 Python 开发能力的中小团队；想以单模块起步、验证后再扩到全链路的公司；需要本地化部署以满足数据合规的组织——社区版 LGPL-3.0 允许商用与定制，不存在许可证陷阱。

该谨慎：以深度财务核算为中心的企业（社区版会计功能弱于企业版，缺口见上文对比）；完全没有技术团队的组织（自托管社区版需自行处理部署、备份、升级；纯 SaaS 体验应直接看 Odoo Online）；需要 APS 级高级排程的复杂离散制造（企业版制造模块在增强，但这一向不是 Odoo 的主场）。

上手路径：官方文档给出打包安装器（Debian/Windows）、源码包（tarball）、Git 源码、Docker 镜像四条部署路径（Docker 官方 odoo 镜像累计拉取超 5,400 万次）；学习走 Odoo eLearning 的免费课程与 Scale-up 商业模拟游戏；开发者从开发教程进入，第一个里程碑通常是写一个带模型、视图、权限的最小自定义模块。发现安全问题走官方负责任披露渠道，不要提公开 Issue。

结尾判断

Odoo 的护城河不在单个应用——单论 CRM 或电商，市面上专精产品很多——而在两件事：一是同一套数据模型上的应用矩阵，让"先装一个、后装全套"成为平滑路径而非迁移工程；二是开源核心加商业增值的双层模式，既养得起每年一个大版本的持续投入，又给用户留了不被锁死的退路。对评估者来说，真正要做的判断只有两个：你的业务重心落在社区版的能力圈内还是企业版的付费墙外，以及团队有没有能力承担一年一版的升级节奏。想清楚这两个问题，选型结论自然就出来了。