★ FEATURED ARTICLE 简介《Odoo16实施应用指南》面向刚接触Odoo与GoodERP的中小企业实施人员、运维人员和业务管理员也适合希望系统梳理开源ERP落地流程的入门读者。内容以GoodERP中国版为实践对象从基础资料配置、用户权限、资金账户、客户供应商与商品设置讲起延伸到采购、销售、仓库、现金、组装生产、委外加工、复杂工序、MRP分析、多币种及高级部署等典型场景并兼顾PostgreSQL数据库管理、模块安装升级和日常使用技巧。压缩包内为1个PDF文件约9.01MB便于离线查阅和按章节检索。整体按实施顺序组织先介绍GoodERP的定位与发展再进入配置和业务操作最后覆盖部署优化与开发实施理念适合边学边查。已有276人学习可作为入门阶段的操作参考与实施思路手册帮助读者理解从环境搭建、基础配置到业务流程贯通的具体做法并对照特定场景的处理方式积累排错与优化经验。1. Odoo 16 实施最容易翻车的地方其实是基础资料没配对接手一套 Odoo 16 的实施最先让人卡住的往往不是代码而是基础资料没配对客户期初余额录不进去、销售订单发完货结算单生成不出来、多币种订单金额对不上、科目方向反了还不知道从哪改。这份《Odoo 16 实施应用》指南覆盖的正是这些环节从系统管理员权限、公司开户行与会计属性到采购、销售、库存、组装生产、工序委外、MRP 分析再到 Ubuntu 部署、Nginx 反向代理和 PostgreSQL 调优。它面向的是要独立把一套账套从零跑到能出报表的人实施顾问、企业里兼管 ERP 的 IT、以及刚接手 Odoo 二次开发的工程师。下面按我实际落地的顺序拆一遍能抄的直接抄坑在哪我会标出来。2. 环境落地从装好 Odoo 16 到跑通第一个账套2.1 Windows 与 Ubuntu 两条安装路径怎么选指南里给了两条路Windows 下用安装包或源码起服务Ubuntu 下用源码加 systemd 托管。很多人图省事在 Windows 上把整套东西跑起来给业务演示、做培训、录操作视频这没问题但真要上生产我一般直接推 Ubuntu Server 的 LTS 版本原因是 Odoo 的服务托管、日志切割、备份脚本、Nginx 反代这一套在 Linux 上都是现成的Windows 下你要多花一倍的精力去处理开机自启、路径空格、权限继承这些琐事。Windows 路径的关键点不在安装而在 PostgreSQL。安装包会带一个数据库但很多翻车都发生在“数据库装好了Odoo 连不上”——要么是端口被占要么是pg_hba.conf里的认证方式和服务端要求对不上。我的习惯是先单独验证数据库用psql能登进去、能建库、能删库再装 Odoo 本体。这一步过了后面基本是顺的。Ubuntu 路径要手动做的事多一些但每一步都可控。核心是三件事系统依赖、Python 依赖、PostgreSQL 角色。系统依赖里libpq-dev、libxml2-dev、libxslt1-dev、libjpeg-dev、libldap2-dev、libsasl2-dev这几个别省省了会在装 Python 包时报编译错误报错信息还很不直观血泪经验就是先把它们一次性装齐。# Ubuntu 下装 Odoo 16 的系统依赖按需精简但这几个基本都要 sudo apt update sudo apt install -y git python3-pip python3-dev build-essential \ libpq-dev libxml2-dev libxslt1-dev libjpeg-dev libldap2-dev libsasl2-dev \ libssl-dev libffi-dev zlib1g-dev postgresql nginx # 建一个独立的系统用户跑服务不要用 root sudo useradd -m -d /opt/odoo -U -r -s /bin/bash odoo sudo mkdir -p /opt/odoo/app /opt/odoo/data /var/log/odoo sudo chown -R odoo:odoo /opt/odoo /var/log/odoo # 拉代码16.0 分支 sudo -u odoo git clone --depth 1 -b 16.0 https://github.com/odoo/odoo.git /opt/odoo/app这段脚本里--depth 1是为了只拉最新一次提交仓库体积能从几个 G 压到几百兆部署机上不需要完整提交历史。-b 16.0锁分支不要拉 mastermaster 的依赖和数据库结构随时在动你按 16.0 的文档配会踩空。建独立用户odoo的目的不是洁癖而是让服务进程没有写系统目录的权限出问题时影响面可控。Python 依赖装的时候记得用虚拟环境别往系统 Python 里灌不然后面系统升级一次 apt你的 Odoo 可能就起不来了。# 虚拟环境 依赖 sudo -u odoo python3 -m venv /opt/odoo/venv sudo -u odoo /opt/odoo/venv/bin/pip install --upgrade pip wheel sudo -u odoo /opt/odoo/venv/bin/pip install -r /opt/odoo/app/requirements.txt # 数据库角色Odoo 需要能建库所以要 CREATEDB sudo -u postgres createuser --createdb odoocreateuser --createdb odoo这一步是必须的Odoo 在界面上“新建数据库”的动作本质是拿配置里的数据库用户去执行CREATE DATABASE没有CREATEDB权限就会在创建账套时报权限错误。生产环境如果不想给这个权限那就关掉界面建库改成命令行createdb预先建好再在配置文件里指定db_name。2.2 配置文件参数写错就起不来Odoo 的启动参数最好全部落到配置文件里别塞在命令行。命令行参数一多改一次错一次而且 systemd 的 unit 文件里藏一长串参数排查时非常痛苦。我习惯放/etc/odoo/odoo.conf权限设成 640属主odoo。[options] ; 模块搜索路径自研模块和第三方模块各放一个目录别混在官方 addons 里 addons_path /opt/odoo/app/addons,/opt/odoo/custom/addons ; 数据库连接 db_host 127.0.0.1 db_port 5432 db_user odoo db_password 换成你自己的强口令 db_name False ; 主控密码只用于建库/备份/恢复别和业务用户密码混为一谈 admin_passwd 换成一串足够长的随机值 ; 数据目录附件、session、filestore 都在这里备份必须带上 data_dir /opt/odoo/data ; 日志 logfile /var/log/odoo/odoo.log log_level info ; 反向代理后面必须开否则 Odoo 拿到的都是 127.0.0.1报表和链接会错 proxy_mode True ; 多进程先留 0单进程调试压测后再按核数配 workers 0 max_cron_threads 2几个参数值得单独说。data_dir是最容易被忽略的很多人备份只pg_dump数据库恢复之后发现所有附件、产品图片全丢了因为附件默认存在文件系统里不在数据库中。proxy_mode不开Nginx 转发过来之后 Odoo 认为请求都来自本机生成的外部链接、附件 URL 就会指向内网地址前端表现是图片裂了、下载 404。admin_passwd不是登录密码它管的是数据库管理页面暴露在公网等于把数据库交出去所以这个值一定要长且随机并且只在需要建库/恢复的时候才临时开放那个页面。workers 0表示单进程单线程只适合调试。生产上按 CPU 核数配常见算法是2 × 核数 1比如 4 核配 9。但这不是硬公式内存才是上限每个 worker 峰值能吃到 1G 以上配多了会 OOM。参数表大致这样参数调试期生产建议说明workers02×核数1 起算超过内存就往下调max_cron_threads12定时任务并发多了抢数据库limit_memory_soft不设2G 左右超了 worker 处理完当前请求就回收limit_memory_hard不设soft 的 2~2.5 倍超了直接杀防雪崩limit_time_cpu不设60单请求 CPU 秒数上限limit_time_real不设120单请求墙钟秒数上限limit_memory_soft和hard这两个值不设一个跑飞的报表能把整台机器的内存吃干净然后系统 OOM killer 随机杀进程表现出来的现象是“Odoo 服务莫名其妙重启”排查半天找不到原因这就是典型的黑匣子场景。2.3 三方模块安装路径、依赖、重启三件事指南里拿web_responsive举例这个选得挺合适——它是个纯前端模块不依赖额外的 Python 包装坏了也不至于把账套搞崩适合拿来练手。三方模块的安装流程其实就三步放进addons_path里能扫到的目录、更新应用列表、安装并重启。# 1. 建一个给三方模块用的目录和自研模块分开方便升级时不互相覆盖 sudo mkdir -p /opt/odoo/custom/addons sudo chown -R odoo:odoo /opt/odoo/custom # 2. 把模块目录拷进去假设已经下载并解压到 /tmp sudo cp -r /tmp/web_responsive /opt/odoo/custom/addons/ sudo chown -R odoo:odoo /opt/odoo/custom/addons/web_responsive # 3. 只更新模块列表不安装 sudo -u odoo /opt/odoo/venv/bin/python /opt/odoo/app/odoo-bin \ -c /etc/odoo/odoo.conf -d 你的账套名 -u base --stop-after-init # 4. 重启服务然后去界面「应用」里搜索并安装 sudo systemctl restart odoo-u base是更新 base 模块作用是刷新模块清单让系统重新扫描addons_path。--stop-after-init表示跑完就退出不常驻这个参数在命令行升级时几乎是必带的不带的话终端会一直挂着很多人以为卡死了就 CtrlC结果升级做到一半中断模块状态变成“待安装”但数据没写全后面怎么点都装不上。真正装模块的时候用命令行的-i更稳# 安装指定模块-i 后面跟技术名不是显示名 sudo -u odoo /opt/odoo/venv/bin/python /opt/odoo/app/odoo-bin \ -c /etc/odoo/odoo.conf -d 你的账套名 -i web_responsive --stop-after-init # 升级指定模块改了自研模块的代码后必做 sudo -u odoo /opt/odoo/venv/bin/python /opt/odoo/app/odoo-bin \ -c /etc/odoo/odoo.conf -d 你的账套名 -u web_responsive --stop-after-init-i和-u的区别要记牢-i是首次安装会建表、写初始数据-u是升级会重跑模块的__manifest__.py里声明的数据文件。改了一个视图 XML 之后只-i不-u界面上看不到任何变化这是新手最常见的困惑。另外模块目录名不一定要和模块技术名一致但强烈建议一致否则升级时你自己都会找错目录。还有一件事装模块之前先备份。数据库pg_dump加data_dir打包两个都要。只备份数据库不备份 filestore恢复之后附件全空只备份 filestore 不备份数据库那更没意义。我一般写成一条脚本挂定时任务实施期间每天凌晨跑一次。3. 基础资料配置账户、币种、科目要连成一条链3.1 公司信息与会计属性进销项税率决定后面所有单据指南里把“设置公司基本信息”放在第二章第二节这个位置是对的因为后面所有单据的税额都从这里取。菜单路径是「配置 → 高级配置 → 公司」除名称、地址、税号之外真正要看的是「会计属性」选项卡里的三样进项税税率、销项税税率、开户行。进项税是采购时抵扣的税销项税是销售时开出去的税两个填反了采购订单和销售订单的价税合计会整个颠倒而且不会报错——系统照常算只是算错。这种错最麻烦因为它不会在录入时暴露往往要等到月底对账、或者财务拿着报表来问“为什么这个月税负这么奇怪”才被发现。同一个选项卡里还有一个勾选项「根据发票确认应收应付」。这个开关决定业务和财务的衔接方式两种模式差别不小模式业务动作财务动作适合场景不勾选按单据确认销售发货即产生应收直接看应收报表业务简单、发货即开票勾选按发票确认发货后生成结算单需人工确认确认结算单才产生应收有账期、开票滞后于发货勾选之后销售订单发货完成系统不会自动确认应收而是生成一张结算单需要有人去「资金 → 结算单」里点确认。这一步是很多实施项目上线后被吐槽最多的地方——业务以为发完货就完事了财务以为业务会去点确认结果两边的账都停在那里。上线前一定要把这个流程写进操作手册并且明确谁负责点这个确认。3.2 资金账户、结算方式、付款方式三个概念别揉在一起这三个词在中文里听着都像“怎么付钱”但在 Odoo 里层级完全不同配错一个后面全乱。我见过最典型的翻车是把“月结 30 天”填进了结算方式结果账龄算不出来因为账龄是从付款方式取的。概念菜单路径实质举例资金账户资金 → 设置 → 账户钱放在哪个账户里某银行对公账户、现金结算方式资金 → 设置 → 结算方式银行账户余额减少的具体形式支票、银行汇票、电汇、委托收款付款方式资金 → 设置 → 付款方式企业间约定的账期月结 30 天、货到付款、预付 30%资金账户要特别注意一点公司的对公账户必须录入并且在「配置 → 高级配置 → 公司」的「开户行」字段里选中它。这一步不做的后果是后续所有涉及银行流水的单据都可能挂到一个空的默认账户上对账时发现余额对不上回头找原因要找很久。账户的期初余额也不用手工做凭证。录了期初值之后系统会自动创建一张其他收入单并把会计凭证一起生成这是 Odoo 的设计别再去手工补一张凭证否则重复记账。我一般会先把期初录进去然后去会计凭证列表按日期搜一遍确认只生成了一张再继续往下走。3.3 客户、供应商与期初余额权限边界要提前划清客户和供应商的期初余额只有管理员账户能录入和修改。这个限制是有意为之——期初余额直接进总账属于财务数据不能让业务随手改。实施的时候要提前和客户说清楚应收期初、应付期初由谁提供、由谁录入、录完谁来复核。有未结账目的老客户、老供应商一定要在上线前把余额录进去否则上线后第一笔收款就没法核销。核销逻辑是“收款单去匹配应收单据”如果历史应收不存在这笔钱就只能挂在预收款里越积越多最后变成一堆对不上的往来。类别设置这块指南里有一句提醒很关键务必为各类别选择会计科目。客户类别、供应商类别、产品类别每个类别都要绑科目不绑的话生成凭证时系统不知道该往哪个科目记表现是凭证生成失败或者科目为空。库存的“其他入库”“其他出库”收发类别也要设成「核算」类型并选科目不然盘点调整、赠品入库这类动作产生的金额没有落脚点。3.4 商品、计量单位与多币种币种跟着科目走商品的设置分几种情况指南里举的例子挺贴实际有唯一编号的实物比如每套手册有独立编号要在「库存」选项卡勾选「管理批号」和「管理序列号」这样出库时可以追溯到具体哪一件电子版、服务类这种不发实物的勾「虚拟产品」发货时不检查库存否则订单一确认就提示库存不足有规格属性的比如封皮颜色用属性 属性值来做属性本身不影响价格只是给商品加维度方便筛选和统计采购选项卡里可以挂多个供应商各自设供货价和最低订购量比价和自动补货都靠这个。计量单位在「库存 → 设置 → 计量单位」里配。这里有个细节Odoo 支持“参考单位”和“更大单位”的换算比如 1 箱 12 个配的时候要选对换算类型固定比例还是按重量。如果单位换算配错了库存报表里的数量会以你想象不到的方式放大或缩小而且不会报错。多币种是这份指南里讲得比较克制的一块但结论很实在币种是跟着会计科目走的。先在科目上选币种再把这个科目用在客户分类上那么这个分类下的客户订单就是那个币种。这个链条意味着你不能给单个客户直接指定币种只能通过分类间接指定所以如果同一个客户要下两种币种的订单只能建两个分类或者两个客户档案。指南里也明确写了暂不支持同一客户多币种交易。如果你的业务里确实有这种情况实施阶段的处理办法一般是拆客户档案在客户名称后面加币种后缀区分或者干脆用本币结算再手工折算。这两种都不优雅但比上线后改数据强。4. 把主流程跑通采购、销售、库存、生产四条线4.1 采购到付款订单、入库、结算单三步不能跳采购的主链路是采购订单 → 采购入库 → 结算单 → 付款。这条链看起来简单但每一步都有前置条件。采购订单创建时供应商必须有商品必须配了采购选项卡价格默认从供应商报价带出来。确认订单后系统按「接收」策略生成入库单——如果商品配的是“按订单接收”入库单在订单确认时就生成了配的是“按需接收”要手工触发。这两种策略在实施时要统一同一个仓库里混着用库管会疯。采购入库单确认后库存增加同时产生应付。这里回到第 3 章那个开关如果勾了「根据发票确认应收应付」入库后要等结算单确认才真正形成应付账款没勾的话入库就确认。很多项目在这里出问题是因为业务和财务对这个开关的理解不一致导致一边在催付款、一边说系统里没钱。付款环节资金账户必须选对。选了现金账户去付一笔银行转账账面上现金减少、银行没动月底对账直接对不上。我的做法是把常用账户的名字写得非常明确比如“某银行对公-尾号 1234”让人不可能选错。4.2 销售到收款发货、结算、退货、尾款收不回怎么办销售链路比采购长坑也多。基本链路是销售订单 → 销售发货 → 销售收款。中间还夹着变更单、预收款、退货、尾款减免这几种特殊场景。销售变更单用于订单已确认但客户要改数量或价格的情况。直接改原单不是不行但如果已经发货了改原单会让已生成的出库单和订单对不上。变更单的做法是生成一张关联单据保留变更痕迹审计的时候能说清楚“什么时候谁改了什么”。这个设计在实务里很有用尤其是客户频繁改单的行业。销售预收款的处理是先收钱、后发货。收的钱挂在预收科目发货开票后再冲抵应收。操作上一般是建一张收款单类型选预收等正式订单确认后再做核销。这块容易出错的地方是核销对象选错——预收款要核销到具体的销售订单或者发票选错了就变成一笔挂在账上的孤儿款。销售退货的流程要看货有没有发。没发货直接取消订单最简单已发货的要走退货单货回仓库、库存增加、应收冲减。如果已经开票了还要处理红字发票这一步在系统里是独立的动作不做的话账上会多一笔收不回来的应收。尾款不再收取这个场景指南里专门列了一节说明它在实务中很常见。处理方式一般是做一笔坏账或者销售折让把应收冲掉同时记一笔损失。具体走哪个科目取决于公司财务政策但系统操作路径是固定的找到那笔应收做减免或者核销。别直接删单据删了之后审计追踪就断了。4.3 组装生产与产品委外BOM 是核心简单组装生产走的是「物料清单BOM 生产单」的组合。BOM 定义“一个成品由哪些半成品和原料组成、各要多少”生产单确认后系统按 BOM 自动生成原料出库和成品入库。组装生产和工序生产的区别在于要不要记录工序。组装生产只关心“投了多少料、出了多少成品”中间经过几道工序不管工序生产要记录每道工序的完成情况、工时、质检结果。选哪种取决于行业简单组装类比如把几个配件装成一个套装用组装生产就够机械加工、有明确工艺路线的必须上工序。产品委外是“把原料发给外部供应商对方加工好再送回来”。系统里的处理是委外订单 → 原料出库到委外仓 → 收回成品。这里的关键是委外仓的设置原料发出去的时候库存要转到委外仓而不是直接扣掉否则你对供应商那边的在途物料就没有账了。4.4 工序生产与 MRP 分析参数决定建议准不准工序生产要先建工序模板再建 BOM 并把工序挂上去然后才能开生产单。生产单确认后每道工序生成一个工单工人报工时、报产量、做质检。工序委外则是把某一道工序整个包给外部做系统里体现为这道工序的供应商和执行状态。MRP 分析是这套系统里最像“黑匣子”的模块因为它的输出是一堆建议而建议准不准完全取决于参数。核心参数有几个参数作用配错的后果提前期采购/生产从下单到入库的时间算出来的建议日期偏早或偏晚安全库存缓冲量设太高库存积压设太低频繁缺料最小/最大库存规则补货批量批量不合理导致频繁小单供应商交货周期影响采购建议时间与实际不符则建议不可执行我一般建议客户先跑一个月“只看不动”的 MRP 分析把建议和实际手工决策对比找出偏差最大的那几个物料回头调参数。直接拿 MRP 的建议去下单十有八九会买错。5. 避坑与排查实施现场最常见的五类翻车5.1 权限与科目类问题现象新建的用户登录后看不到「配置」菜单或者能看到菜单但点进去报权限错误。原因Odoo 的菜单可见性由用户所属组的权限决定只有拥有配置权限的组登录后主菜单才会出现「配置」。新建用户时如果只勾了业务权限比如销售、库存没勾管理权限菜单就是不出现这不是 bug。解决去「配置 → 用户」编辑该用户在权限页签里按岗位勾选。库管员给库存相关销售员给销售相关出纳给资金相关别图省事全给管理员——权限给多了误操作的风险比效率损失大得多。现象单据保存时报“科目为空”或者凭证生成失败。原因客户类别、供应商类别、产品类别没有绑定会计科目或者库存的收发类别没设成「核算」类型。解决把「配置 → 基本配置 → 类别」里所有类别过一遍逐个确认科目字段有值。这一步在新建账套时就要做别等到第一笔业务跑不通才回头补。5.2 单据与结账类问题现象误删了系统自动生成的入库单或出库单库存和订单对不上。原因自动生成的单据和业务单据是关联的直接删会破坏这个关联库存变动记录还在但来源单据没了。解决不要删改成取消。取消会保留记录并把库存回滚审计链完整。如果已经删了去库存变动记录里找到对应流水手工做一笔反向调整同时记录原因备查。现象点了折旧之后发现科目方向反了想改。原因折旧凭证一旦生成就进了总账直接改凭证会破坏已结账期间的数据一致性。解决不要改原凭证做一笔反向的调整凭证冲掉再重新按正确科目计提。同时确认这个期间有没有结账已结账的期间要先反结账再操作否则改了也不生效。5.3 部署与数据库类问题现象PostgreSQL 启动特别慢Odoo 跟着起不来。原因常见的是 WAL 日志堆积、磁盘 I/O 瓶颈或者shared_buffers等内存参数和机器规格不匹配。解决先看 PostgreSQL 的日志确认是启动阶段慢还是恢复阶段慢。恢复阶段慢说明上次是非正常关闭在重放 WAL等它跑完就行别急着 kill。参数层面shared_buffers一般给物理内存的 25%effective_cache_size给 50%~75%work_mem从小往大调别一上来给几个 G并发一高直接 OOM。现象服务偶尔自动重启日志里没有明确报错。原因八成是 OOM killer 干的或者limit_memory_hard把 worker 杀了。解决先dmesg -T | grep -i kill看有没有 OOM 记录再看 Odoo 日志里 worker 被杀的时间点。确认是内存问题就把workers降下来或者把limit_memory_soft/hard配上让 worker 主动回收而不是被系统杀。这两个参数不配问题会一直以“玄学重启”的形式出现。6. 进阶Nginx 反代与多核参数把 Odoo 16 调到能用的性能单进程的 Odoo 只适合调试一旦并发上来页面加载会明显卡顿尤其是列表页和报表页。提升性能的路径有三条按投入产出比排序是开多进程、上 Nginx 反代、调 PostgreSQL。先说多进程。workers按2 × CPU 核数 1起算比如 4 核先配 9然后压一轮看内存峰值。如果每个 worker 峰值 1.2G9 个就是 10G 以上机器内存不够就得往下砍。同时把limit_memory_soft设成 2G 左右、limit_memory_hard设成它的 2 到 2.5 倍让 worker 处理完当前请求后主动退出重建避免内存缓慢泄漏把机器拖死。另外max_cron_threads别开太大定时任务抢数据库连接比前台请求还凶。再说 Nginx。Odoo 默认跑在 8069 端口直接对外暴露有两个问题一是静态文件由 Odoo 自己处理效率低二是 HTTPS、压缩、超时控制这些都得靠 Nginx。配置的核心是 upstream 加长连接超时upstream odoo_backend { server 127.0.0.1:8069; keepalive 32; } server { listen 80; server_name erp.example.internal; # 换成你自己的域名或内网地址 # 附件上传要放开默认 1M 会让大文件上传直接 413 client_max_body_size 200m; # 长连接超时Odoo 的长轮询和报表导出会跑很久超时太短会莫名断开 proxy_read_timeout 720s; proxy_connect_timeout 720s; proxy_send_timeout 720s; location / { proxy_pass http://odoo_backend; 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_redirect off; } # 静态文件交给 Nginx 直接发减轻 Odoo 压力 location ~* /web/static/ { proxy_cache_valid 200 90m; proxy_buffering on; expires 864000; proxy_pass http://odoo_backend; } }这段配置里client_max_body_size是最容易漏的一条漏了之后表现是“上传附件到一半失败”而且前端提示很含糊。proxy_read_timeout默认 60 秒报表导出、大批量导入经常超过这个时间表现出来就是“点了没反应过一会报错”很多人第一反应是程序有 bug其实是代理把连接掐了。keepalive 32让 Nginx 到 Odoo 之间复用连接高并发下能省掉大量握手开销。最后是 PostgreSQL。Odoo 的性能瓶颈八成在数据库而数据库调优里最容易见效的是内存参数和连接数。shared_buffers给物理内存的 25%effective_cache_size给 50% 到 75%work_mem从 4MB 起复杂报表多的场景可以调到 16MB 到 32MB但要注意它是按每个排序/哈希操作分配的给太大并发一高就爆。max_connections不要盲目调大Odoo 的 worker 数乘以每个 worker 的连接数再加上定时任务的连接算出来总数要留 20% 余量。如果 Odoo 和数据库分机部署网络延迟也会影响体验这条内网链路的带宽和延迟值得单独测一次。还有个常被忽略的点pg_hba.conf的认证方式。开发环境图省事用trust上线还留着等于数据库不设防。生产环境至少用scram-sha-256并且限制来源 IP 只允许应用服务器连进来。这一条改错了会导致 Odoo 直接连不上数据库改之前一定要先备份这个文件改完reload而不是restart验证通过再继续。从那以后我每次给一套新账套做部署都会强制走一遍“配置文件检查 → 多进程压测 → 反代超时验证 → 数据库认证方式确认”这四步一步不落。踩过的坑不会因为换了个项目就消失它们只是换了个形式再出现一次。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
