Odoo20.0即将于9月底份发布，每次 Odoo 大版本升级，大家最先关注的通常是功能变化：界面有没有变、模块有没有新特性、老定制还能不能跑。

但对真正负责上线和运维的人来说，还有一个更早的问题：服务器环境能不能撑得住新版本。

从 Odoo 19到 Odoo 20，技术变化并不只是几个 Python API 的调整。根据我们目前对最新代码的观察，Odoo 20这条开发线已经明显提高了运行环境门槛，尤其体现在 Python、PostgreSQL、依赖包和部署参数上。

需要先说明一点：截至当前观察，Odoo master 仍处在 pre-20.0 开发阶段，本地版本标记为 19.5a1，不是最终发布版。因此本文更适合作为Odoo 20 升级前瞻和技术预警，最终要求仍需以 Odoo 官方 20.0 发布版本为准。

一、升级 Odoo 20，不能只看代码，还要先看服务器

过去很多 Odoo 项目升级时，第一反应是检查自定义模块：字段有没有改、视图有没有报错、方法签名有没有变。

这些当然重要，但从 Odoo 20 开始，环境层面的检查要更靠前。

因为如果 Python 版本、PostgreSQL 版本、系统依赖和部署脚本本身不满足要求，后面的模块迁移、数据库升级、功能回归测试都谈不上。

根据当前 master 观察，Odoo 20 开发线已经出现几个非常明确的信号：

• Python 最低版本：3.12

• PostgreSQL 最低版本：16

• 依赖环境：更贴近 Ubuntu 24.04 / Debian 12

• 配置参数：继续使用 http_port 等现代参数

• 代码质量：ruff 配置目标为 py312

这意味着，Odoo 20 不太适合直接沿用很多老项目的服务器环境。

如果客户当前还运行在 Python 3.10、PostgreSQL 13/14/15，或者系统基础环境长期没有升级，那么 Odoo 20 升级就不只是“升级 Odoo”，而是一次完整的基础设施评估。

二、Python 3.12：从“能跑”到“必须跟上”

Odoo 19已经把 Python 基线推进到更新版本，到了Odoo 20中，Python 最低要求已经提升到 3.12。

这对项目有什么影响？

第一，老系统不能再默认沿用旧 Python 环境。很多 Odoo 16、17、18 项目可能还停留在 Python 3.10 或 3.11。如果直接把 Odoo 20 代码放上去，环境层面就可能无法启动。

第二，第三方依赖需要重新审视。Odoo 的 requirements.txt 会针对不同 Python 版本约束依赖包版本，像 gevent、greenlet、lxml、Pillow、psycopg2 这类包都可能受影响。

第三，自定义模块中的老写法也要更谨慎。Python 3.12 对一些历史行为、弃用库和构建链路更严格，不能只靠“以前能装上”来判断未来也能装上。

所以，Odoo 20 升级前的第一个问题应该是：

python3 --version

如果结果还停留在 3.10 或 3.11，那就要提前规划新环境，而不是等上线当天再处理。

三、PostgreSQL 16：数据库升级会成为前置工作

除了 Python，PostgreSQL 也是一个关键门槛。

当前 Odoo master源码中，最低 PostgreSQL 版本要求已经观察到提升至 16。这对很多现有 Odoo 项目来说，是一个不小的变化。

因为不少线上 Odoo 项目仍运行在 PostgreSQL 13、14 或 15。数据库版本升级不是简单改一个配置，它涉及：

• 数据库备份
• 扩展兼容性
• 性能参数
• 迁移窗口
• 回滚方案
• 生产数据验证

尤其对于数据库体量较大的客户，PostgreSQL 升级本身就需要单独评估和演练。

建议在 Odoo 20 项目开始前，先确认当前数据库版本：

psql --version

或者在 PostgreSQL 中执行：

SHOW server_version;

如果数据库版本低于 16，就要把 PostgreSQL 升级列为 Odoo 20 项目的前置任务，而不是附带任务。

四、部署参数：继续远离老的 xmlrpc_port

Odoo 新版本部署中，另一个容易被忽视的点是配置参数。

在较新的 Odoo 版本中，http_port 已经是更明确的服务端口配置方式。到了当前 master观察中，服务端继续围绕：

--http-interface--http-port--gevent-port

这一套参数运行。

这意味着老项目里如果还保留大量类似 xmlrpc_port 的旧配置习惯，就应该趁升级前统一清理。

例如，现代部署中更推荐关注：

http_port = 8069

而不是继续依赖历史命名。

这类变化表面看只是参数名，但对自动化部署、systemd 服务、Docker 启动命令、反向代理配置、无停机升级脚本都会产生影响。

尤其是我们在生产环境中常用的模块升级方式：

odoo -c /etc/odoo/odoo.conf -d <database> -u <module> --stop-after-init --workers=0 -p <another_port>

这里的 -p 本质上仍然要避开线上服务端口。到了 Odoo 20，部署脚本更应该统一使用现代 HTTP 端口概念，减少历史参数混用带来的误判。

五、系统环境：Ubuntu 24.04 / Debian 12 会更合适

从当前依赖文件观察，Odoo 20开发线的依赖组合更贴近新一代 Linux 发行版，例如 Ubuntu 24.04、Debian 12 这类环境。

这不代表旧系统一定完全不能跑，但对企业项目来说，我们更关注“稳定、可维护、可复现”。

如果为了兼容旧系统不断手工编译依赖、固定奇怪版本、绕过系统包限制，短期可能能启动，长期运维成本会越来越高。

因此，Odoo 20 项目更建议采用新服务器或新容器基础镜像来承接，而不是在老生产机上原地硬升。

更稳妥的升级思路是：

新环境准备-> 安装 Python 3.12+-> 安装 PostgreSQL 16+-> 部署 Odoo 20 代码-> 迁移数据库副本-> 安装依赖与自定义模块-> 完成功能回归-> 制定正式切换计划

这种方式比直接在老环境上改来改去更安全，也更容易回滚。

六、升级前建议做一张环境体检表

在真正讨论模块迁移之前，我们建议先做一张 Odoo 20 环境体检表。可以从这些项目开始：

这张表的意义，不是制造复杂度，而是把风险提前暴露出来。真正危险的升级，往往不是“发现问题太多”，而是上线前以为没问题。

七、给企业的建议：先做环境演练，再谈正式升级

对于计划升级 Odoo 20 的企业，我们建议把项目拆成两个阶段。

第一阶段，不急着改业务模块，先做环境演练：

• 准备新服务器或新容器镜像

• 安装目标 Python 和 PostgreSQL

• 拉取 Odoo 20 对应代码

• 安装依赖

• 启动空库

• 恢复测试库

• 记录所有环境问题

第二阶段，再进入模块和业务迁移：

• 检查自定义模块

• 处理 API 变化

• 升级视图和前端资产

• 验证销售、采购、库存、财务核心流程

• 做性能和权限回归

• 准备正式切换方案

这样做的好处是，环境问题和业务问题不会混在一起。

如果一边处理 Python 依赖，一边处理业务模块报错，再一边处理数据库升级，项目就很容易失控。分阶段做，节奏会稳很多。

八、结语：Odoo 20 升级，第一步不是改代码

Odoo 20 的技术变化，提醒我们一件事：大版本升级不能只看功能，也不能只看代码。

环境基线、数据库版本、依赖包、部署参数、CI/CD 镜像，这些基础设施问题，往往决定了升级项目能不能顺利开始。

从目前观察看，Odoo 20 对运行环境提出了更高要求。对企业来说，这不是坏事。更现代的 Python、更高版本的 PostgreSQL、更清晰的部署参数，长期来看都有助于系统稳定和性能提升。

但前提是：升级前要看清门槛，提前规划，不要把环境升级留到最后一天。

青岛欧姆网络科技在接下来的两个月内会持续跟踪 Odoo 19 到 Odoo 20的技术变化，并结合真实项目经验，整理成系列技术文章，帮助企业和开发者更稳地完成版本演进。