企业官网建设流程全解析

手上如果有一套能跑 OA、CRM、ERP、HRM 的企业系统，报价能到多少？市面上一家小微公司全套 SaaS 订阅，一年少说几千块，上万的也常见。但你要是愿意自己折腾，花一台阿里云 99 元/年的云服务器，部署一套开源的一体化管理系统，整体成本几乎可以压到“一顿饭钱”。这不是什么新玩法，企业数字化领域早就有人这么干，只是大部分人被“部署”两个字劝退了。

这套方案的核心思路很简单：用一块钱一天的服务器，跑一个开源的管理系统，然后把 OA、CRM、ERP、HRM 这些模块全部装进去。听着像天方夜谭，实际上完全可行，尤其适合小微企业、初创团队、想学习企业系统架构的开发者，甚至是想做二开的软件外包团队。我这里不说理论，直接讲清楚三个问题：为什么要选 99 元的服务器、选哪套开源系统最合适、部署过程中哪些坑必须要避开。

1. 内容整体设计与思路拆解：为什么 99 元服务器能扛起整套系统

先别急着觉得“99元/年”是营销噱头，这事要从阿里云近几年针对新用户的活动说起。云厂商为了抢开发者和小微企业客户，经常拿出轻量应用服务器做低价入口，配置一般是 2 核 2G、带宽 3M 或 4M 起步，还有一定的流量包。对于跑一个单人维护、几十人使用的内部管理系统，这个配置其实不是“勉强能跑”，而是“刚好合适”。为什么？因为 ERP 和 OA 这类系统，真正的瓶颈从来不是 CPU，而是内存和磁盘 IO。多人同时在线时，数据库连接数和中间件内存占用才是大头。2 核 CPU 足够处理日常几百次的并发请求，2G 内存则需要一些调优手段来弥补，比如加 swap、按需开启模块、限制 worker 进程数。系统盘方面，轻量服务器默认给 40G 到 60G 的 SSD，对于一套部署完 1G 到 3G 的系统来说，绰绰有余。

这套部署整体怎么拆？核心思路是“把复杂的企业管理软件拆成一层层独立的组件”：

• 系统层： Ubuntu 或 CentOS，负责跑所有东西；
• 中间件层： Nginx 做反向代理，PostgreSQL 或 MySQL 做数据库，Docker 做容器管理；
• 应用层： 开源系统本体，比如 Odoo、ERPNext，它们里面天然就能分 OA、CRM、HRM、ERP 这些模块；
• 数据层： 自动备份到本地加云端对象存储，保证数据不丢。

这么拆的好处是，任何一个组件出现问题，都能单独排查和替换，而不是整个系统一起崩。尤其是应用层用 Docker 部署，升级或回滚都非常方便。

为什么推荐开源一体化系统，而不是用多个开源软件拼接？这个坑我必须先说清楚。很多人第一反应是：OA 用一个开源项目，CRM 用一个开源项目，ERP 再找一个，然后通过接口串起来。理论上叫“微服务”，实际上现实里这就是灾难现场。每个系统的登录逻辑不一样、用户体系不一样、权限模型不一样，你想打通数据就得写一堆中间接口，接口联调的工作量比部署一个系统本身还要大。更何况多数开源 OA 和 CRM 项目背后的技术栈完全不同，Java 一套、PHP 一套、Python 一套，运维也得同时维护三种环境。到头来你只有一个 IT 师傅甚至没有专职 IT，根本玩不转。

一体化系统之所以适合这种场景，就是因为它把 OA、HRM、CRM、ERP 做成模块装在一个大平台上，共用一套用户、一套权限、一套数据库。底层表结构天然关联，销售这边成交的订单，可以直接流入财务模块生成发票，库存模块自动扣减，HR 模块里员工信息和 OA 审批流也天然联动。这就像买房子：精装房虽然户型固定的，但你不用自己操心水电改造和线路规划，拎包入住就行。对于预算有限、业务逻辑又相对标准的小企业，这就是最优解。

再看服务器选型。99 元/年的服务器大多不带独立 IP 备案优惠，但只要是大陆区域节点，就必须做 ICP 备案。备案流程看着麻烦，其实现在阿里云控制台整体引导做得不错，提前准备好营业执照或个人身份证，大概两周能走完。如果实在怕备案，想快速上线，可以选境外节点，但价格会比 99 元多不少，而且访问速度看运气。我的建议是：能用大陆节点就选大陆节点，顺便把域名备案也办了，以后加别的业务都省事。

这里必须先给出结论：那套系统适合 99 元服务器？我们来看几个主流的开源项目。Odoo 社区版是目前知识库最庞大、模块最丰富的一体化平台，社区版免费，内置 CRM、销售、采购、库存、会计、HR、招聘、休假、审批等模块，这些年国内企业用它做 ERP 改造和 OA 二次开发的非常多。ERPNext 同样是一体化系统，基于 Python 的 Frappe 框架，财务、HR、制造、CRM、采购销售库存都有，开源协议友好，适合需要大改的团队。另外还有些国产框架比如若依体系，本身偏 OA 和后台管理开发脚手架，要接 CRM 和 ERP 得自己写业务，不太适合“快速落地”的目标。所以我的建议是：如果你想开箱即用、中文资料多、生态成熟，就上 Odoo 社区版；如果你更看重开源合规和财务模块自由度，ERPNext 是很好的备选。这篇文章后面的实操部分，我以 Odoo 17 为例讲，因为它的安装最稳、Docker 镜像最官方、社区问答最全，遇到问题容易搜到答案。

2. 部署前的关键准备与基础设施配置

很多人在部署的时候会有一个误区：买了一台服务器，立刻就开始安装系统。理论上没错，但企业管理系统不是个人博客，它需要确认几个前置条件，否则后期会越用越难受。这一步做扎实，后面可以省掉 80% 的维护成本。

2.1 域名、备案与 HTTPS 的底层逻辑

这套系统上线后，员工要每天访问，安全性和可信任度很重要。直接通过 IP 访问，浏览器会提示不安全，桌面端和手机端都会容易误拦；内部审批流里还要发邮件通知，邮件里的链接如果是一串 IP，不仅容易被做垃圾邮件过滤，而且一看就不专业。所以域名几乎是必须的。

域名在哪里买不重要，便宜就行，一个 .top 或者 .xyz 域名一年也就几块钱到二十块钱。重点在于 ICP 备案。这是在阿里云这类国内服务商购买大陆服务器必须走的流程，个人备案可以选“个人博客”之类的主体，企业备案则需要营业执照。备案期间，服务器可以正常用，但 80 和 443 端口不允许对外提供服务，所以你可以先把系统装好、配置好、数据都初始化完，等备案批复后直接把域名解析过来，无缝上线。

HTTPS 证书这里有个很容易踩的坑。阿里云提供免费 SSL 证书，原来是一年有效期，后来改成了三个月一换。很多教程写的是“申请免费证书”，但没告诉你必须定期续期。如果你忘了续期，浏览器直接拦截访问，内部员工全都会来找你。解决思路有三种：第一种，手动在控制台申请新证书，然后用脚本自动替换到服务器上；第二种，用 Let’s Encrypt 这类免费证书，配置 certbot 自动续期，拿到 90 天证书后自动刷新；第三种，干脆用云厂商的负载均衡或 CDN，把证书托管在云上。对单机部署来说，我推荐用 certbot 自动续期，完全免人工。网上很多人吐槽“阿里云SSL证书免费续期”麻烦，实际是他们不知道 certbot 的存在。

2.2 安全组配置：别把漏洞留给扫描机器人

云服务器默认有一层安全组防火墙，阿里云控制台里可以单独配置端口放行规则。很多人图省事，直接“放行所有端口”，结果服务器上线没几天，就发现被扫描机器人安排得明明白白，SSH 端口天天被爆破，数据库端口也暴露在外网。这是非常危险的操作。

正确的配置方式分三层：

• 云安全组： 只放行 22（SSH，可改成非标准端口）、80、443 三个端口。数据库端口（PostgreSQL 默认 5432，MySQL 默认 3306）不允许对公网开放，只允许内网访问。如果你的应用容器和数据库容器都在同一台机器上，它们通过 Docker 内网通信就够了，根本不需要暴露端口；
• 系统防火墙： 即使云安全组放行了端口，在 Ubuntu 里也建议用 ufw 再设置一层白名单，只允许指定 IP 访问 SSH。这样就算你密码泄露，远程的暴力破解也很难进来；
• SSH 加固： 修改默认端口、禁止 root 直接登录、使用密钥对登录。别怕麻烦，企业管理系统里存着员工资料和财务数据，一旦被入侵，后果比日常维护麻烦得多。

2.3 内存不够怎么办：2G 机器跑生产系统的关键武器

99 元档位一般是 2G 内存，装完系统和数据库后，剩余内存其实还有不少。但 Odoo、ERPNext 这类基于 Python 框架的系统，运行时有一些基础内存占用，再叠加数据库缓存，偶尔会达到 2G 的上限。这个问题最有效的解法是加 swap——也就是用磁盘空间充当虚拟内存。磁盘确实比内存慢，但它能防止进程被 OOM Killer 直接杀掉。对于这种偶发性的内存尖峰，swap 够用了。

操作很简单，一条命令就能创建 4G swap：

sudo fallocate -l 4G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

这里我多说一句：如果是长期用，最好把系统装在 SSD 上，这样 swap 的性能会更好。99 元档位本身配的应该都是 SSD，问题不大。还有一个最常见的调优操作：关闭不需要的常驻服务。比如 Ubuntu 自带的 cloud-init、unattended-upgrades，以及你可能用不到的打印服务，这些服务加起来也会吃掉几百 MB 内存。关了之后，系统基础内存占用能降到 500M 左右，给应用层留出更多空间。

2.4 Docker 还是宝塔面板：我的选择逻辑

聊到这里，就绕不开一个很现实的问题：普通用户喜欢用宝塔面板，因为界面化、上手快、装 Nginx 和数据库都是点两下的事。但我不推荐在这套部署里用宝塔，尤其是近期宝塔面板的某些操作会和各种云 API 权限纠缠，比如“宝塔面板不能更改阿里云 OSS 的 AccessKey ID”这类问题，就是典型的权限模型不一致导致的。而且宝塔面板本身也会占资源，它内置了监控、日志、插件商店，对 2G 内存的机器来说负担不小；再加上它把 Nginx、PHP、MySQL 等全部用自编译方式安装，后续做 Docker 容器化部署时容易产生路径和端口冲突。

我建议直接用 Docker Compose 方式部署。你可能会觉得 Docker 对新手不友好，但实际用下来你会发现：它比宝塔更简单。因为别人已经写好了完整的 docker-compose.yml，你只需要复制粘贴、改几个环境变量，然后 docker compose up -d 就能把整个系统拉起来。升级、回滚、备份都是操作容器，不会残留一堆乱七八糟的依赖文件。

当然，如果你对 Docker 实在陌生，用宝塔也不是不行，只是后面装 Odoo 和 ERPNext 这类应用时，大概率还是手动编译或手动装依赖，容易碰一鼻子灰。既然我的整套实操建议都围绕 Docker 来展开，那这一步最好跟住。

3. 核心模块解析：OA、HRM、CRM、ERP 如何在一套系统里共存

很多老板或企业负责人搞不清楚 OA 和 ERP 到底有什么区别，更理解不了为什么这两个东西能放在一个系统里。其实从业务视角来看，它们本该就是一体。OA 侧重于审批流和内部协作，比如请假、报销、用章申请、合同审批；CRM 管的是销售过程，从线索到客户到商机再到订单；ERP 管的是订单进来之后的履约，包括采购、生产、库存、会计；HRM 管的是员工全生命周期档案、招聘、考勤、薪酬。这些流程之间的天然联系是：一个销售订单被批准后，库存要扣减、财务要开票、采购要补货，而所有操作它们的人，在 HRM 里都有对应的角色和权限。

3.1 Odoo 社区版模块图谱：哪些真的能开箱即用

我以 Odoo 17 社区版为例，说说它每个模块对应企业什么需求。为了让你有个直观概念，我列一个表格：

这套模块设计最大的价值是数据天然打通。举个例子：销售在 CRM 里把一条商机变成销售订单后，系统会自动触发库存可用量检查；如果库存不足，采购模块会生成一份采购建议；订单交付后，会计模块会自动生成客户发票；后续财务收款时，这笔订单的全过程可以在一个界面上查到。对企业老板来说，这就是最想要的数据闭环。

要注意的是，Odoo 社区版的 HRM 模块不像企业版那样包含完整的薪酬管理，复杂的薪资计算和考勤硬集成需要额外开发。不过对于小微企业，员工档案、招聘、休假、审批这些刚需功能已经足够。如果你的核心诉求是复杂的排班和薪酬，那 ERPNext 的 HR 模块确实更强一些。这也是我在前面强调要在 Odoo 和 ERPNext 之间做选择的原因——没有十全十美的系统，只有更适合你业务的系统。

3.2 初始化配置：公司架构、财务日期、权限模型

系统装好之后，第一件事不是在界面上到处乱点，而是把基础数据配好。这个步骤做错了，后面改起来非常痛苦。

第一步是创建公司资料，包括公司全称、简称、地址、电话、税号、logo 等。Odoo 会把这些信息打印到发票、报价单等所有对外文档上。公司设置里的“财务开始日期”非常关键：如果你导入的初始化数据是从 2025 年初开始的，那财务开始日期就要设置为 2025 年 1 月 1 日，系统会以此日期为分界点，之前的金额统一作为期初余额，之后的业务才走正常账本。这个日期一旦设置错误，后续的财务报表全部失真，后期要修正就得动数据库表，麻烦至极。

第二步是设置会计科目表。Odoo 会根据用户所在国家自动加载一套基础科目表，国内用户可以在设置里选择中国会计准则或完全自建科目。小微企业通常不需要太复杂的会计结构，但至少要理解“收入”“成本”“资产”“负债”这几个大类的逻辑，否则发票录入时你会不知道选哪个科目。

第三步是配置部门架构和用户权限。Odoo 的权限体系基于“用户组”，大致分为内部用户、外部用户、管理员三层。管理员可以访问所有模块，普通用户按模块勾选权限。合理建议是：基层员工只开 OA 审批和休假模块；财务人员额外开会计模块；销售成员只开 CRM 和销售模块；每个模块再设置“自己的记录”和“所有人的记录”两种权限等级，避免出现员工能看到全公司薪资结构这类事故。

3.3 邮件通知与短信：为什么 SMTP 总是发不出去

内部系统的审批流依赖邮件通知。员工提交请假，主管会收到邮件提醒；客户发票生成后，系统要自动发送邮件的场景也非常多。但很多人在配置 SMTP 这一步被卡住，原因通常是出在云服务商的 25 端口封锁上。

2G 服务器部署的云服务商，默认会把对外发送邮件的 25 端口封掉，防止垃圾邮件。这时候如果用默认的 SMTP 端口（25）连接外部邮件服务器，结果就是一直超时。解决办法是使用 465（SSL）或 587（STARTTLS）端口发信。比如你用阿里云邮件推送（DirectMail），配置 SMTP 服务器时要把端口改成 465，并且打开 SSL。如果你用的是 QQ 邮箱或 163 邮箱，需要在邮箱后台开启“SMTP 服务”，拿到授权码而不是登录密码。网上那些“阿里云短信 API 发不出去”的问题，和 SMTP 配置的逻辑其实很类似，都是云厂商默认限制外发通道。短信本身和这套开源系统没有直接关系，但你如果后续要接短信通知，也会遇到类似问题。

3.4 备份策略：别等数据丢了再后悔

企业管理系统的最重要资产不是代码，而是数据。我见过太多小企业觉得“系统都在服务器上，怎么会丢”，结果服务器被入侵或者误操作删库，几年的财务数据直接化为泡影。Odoo 和 ERPNext 都提供在界面上导出备份的功能，但那只适合偶尔手动备份，不适合生产环境。正确做法是写一个定时备份脚本，每天凌晨 3 点把数据库 dump 出来，同时把系统配置目录和上传文件一起打包，传到阿里云 OSS 或者另一台独立的存储设备上。

备份脚本的思路很简单：

#!/bin/bash # 备份 PostgreSQL 数据库 docker exec -t odoo-db pg_dump -U odoo --format=custom odoo > /backup/odoo_$(date +%Y%m%d).dump # 打包上传文件目录 tar -czf /backup/filestore_$(date +%Y%m%d).tar.gz -C /var/lib/docker/volumes/odoo_filestore/_data . # 同步到阿里云 OSS ossutil cp -r /backup/ oss://your-bucket/backup/ # 只保留最近 14 天备份 find /backup/ -type f -mtime +14 -delete

备份这事没有什么技术门槛，但坚持每天做、每次恢复演练一次的团队很少。我的建议是：部署当天就先把备份脚本配好，并在测试环境做一次全量恢复，确认备份文件真的可用。这个东西没出问题时觉得是浪费时间，出问题时它就是救命稻草。

4. 实操部署全过程：从 Docker 到 HTTPS 上线的完整记录

这部分我写的是我在一台 2 核 2G 阿里云轻量服务器上部署 Odoo 17 的完整过程。我不打算只贴命令，每个关键步骤都会解释原因，尤其是那些“不这么做就会踩坑”的地方。

4.1 环境初始化：Ubuntu 的纯净安装与基础调优

购入服务器后，第一件事是在阿里云控制台把操作系统重装为 Ubuntu 22.04 LTS。这里不建议用 CentOS 7（因为它已经进入 EOL 阶段，软件源逐渐失效），也不建议用带宝塔的镜像，因为我希望所有组件都在 Docker 里跑，宿主机只需要保持纯净即可。

登录服务器后，我建议先执行一轮系统更新并安装基础工具：

apt update && apt upgrade -y apt install -y git vim htop unzip curl wget fdisk

然后创建 swap，前面已经给了命令，这里不再赘述。做完这些之后，顺手把 SSH 登录加固一下，修改 /etc/ssh/sshd_config 里的 Port 和 PermitRootLogin，然后重启 sshd 服务。注意：改 SSH 端口之前，一定要先在安全组里也放行新端口，否则你改完就掉线了。这个顺序很多人搞反，结果自己把自己锁在服务器外面。

4.2 安装 Docker 与 Docker Compose

Ubuntu 上装 Docker 有两种方式：直接用 apt 装 Docker 官方源，或者用阿里云的镜像源加速。国内服务器直接用 Docker 官方源大概率会慢到超时，所以在 /etc/apt/sources.list 里换成阿里云源是好选择。Docker 本身需要守护进程和 cgroup 支持，轻量应用服务器默认的镜像一般没问题。

安装完成之后，记得配置 Docker 镜像加速器。虽然从 Docker Hub 拉 Odoo 官方镜像可以直连，但某些时间段速度很慢，阿里云容器镜像服务会给每个账号分配专属加速地址，写在 /etc/docker/daemon.json 里即可。这个配置对于在国内部署任何 Docker 应用都适用。

4.3 准备 Odoo 的 docker-compose.yml 文件

这里给出一个可直接落地的 compose 模板。Odoo 官方镜像需要依赖 PostgreSQL 数据库，并用 Volume 持久化数据。

version: '3.8' services: web: image: odoo:17 container_name: odoo-web depends_on: - db environment: - HOST=db - USER=odoo - PASSWORD=odoo ports: - "127.0.0.1:8069:8069" volumes: - odoo_filestore:/var/lib/odoo - ./config:/etc/odoo - ./addons:/mnt/extra-addons restart: always db: image: postgres:15 container_name: odoo-db environment: - POSTGRES_DB=postgres - POSTGRES_USER=odoo - POSTGRES_PASSWORD=odoo volumes: - odoo_dbdata:/var/lib/postgresql/data restart: always volumes: odoo_filestore: odoo_dbdata:

有几个细节我要重点说明：

• web 服务的端口只绑定到 127.0.0.1，这意味着只有本机可以直接访问 8069，外网无法直接访问。这么做是为了安全，后面用 Nginx 作为唯一的外网入口；
• volumes 里的 ./config 和 ./addons 目录需要预先创建。config 里放 odoo.conf 配置文件，addons 里放你后续的第三方模块。如果目录不存在，Docker 会自动创建，但会以 root 权限创建，后续写文件会提示权限不足；
• odoo:17 镜像会默认等待数据库启动，但有时候数据库初始化较慢，容器可能先启动然后报连接失败，这时只要容器 restart=always，过一会它会自动恢复。

这里面还有一个隐性问题：如果你在设置里没指定数据库，Odoo 首次打开页面会让你填写数据库名、管理员密码和语言。数据库名建议用和公司业务相关的名字，方便后续管理，比如 company_prod 或 odoo_main，不要用 admin 这种默认名称。

4.4 启动并初始化首个数据库

执行 docker compose up -d 后，等待 1-2 分钟，再用浏览器访问 http://服务器IP:8069，你会看到 Odoo 的数据库设置页面。这里有几个关键字段：主密码是超级管理密码，用于后续创建数据库和远程连接；数据库名需要手动填入；勾选“演示数据”？生产环境千万别勾，这会生成一堆演示数据，清理非常麻烦。

初始化完成后，你会进入空白的 Odoo 后台。左下角一般会有一个应用切换菜单，在这个阶段系统只启用了基础后台模块。你需要点击“应用”菜单，按需安装之前列出的那些模块。这一步的正确做法是：先用几天时间把“员工”“审批”“销售”“CRM”这些最常用的模块装好，跑到顺手的程度，再逐步加采购、库存、会计。一次性全部装完，菜单会特别多，很多用不到的功能也会占内存，对 2G 服务器不太友好。

4.5 配置 Nginx 反向代理与免费 HTTPS 证书

系统跑通之后，先把 Nginx 装上。Odoo 默认监听 8069 端口，这个端口不能直接暴露给外网，一是因为不安全，二是因为 8069 是 TCP 明文端口，不经过 HTTPS 加密的话，所有登录密码都会被抓包看到。在 Nginx 里配置一个 server 块，把域名指向本机，并反向代理到 127.0.0.1:8069 即可。

关键 Nginx 配置片段如下：

server { listen 80; server_name erp.example.com; # 强制跳转 HTTPS return 301 https://$host$request_uri; } server { listen 443 ssl; server_name erp.example.com; ssl_certificate /etc/nginx/ssl/erp_example_com_fullchain.crt; ssl_certificate_key /etc/nginx/ssl/erp_example_com.key; # Odoo 长连接支持 proxy_read_timeout 720s; proxy_send_timeout 720s; proxy_connect_timeout 720s; # 如果有 gzip 需求可以开启，建议压静态资源 location / { proxy_pass http://127.0.0.1:8069; 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; } # Odoo 长轮询接口，不配置这个会导致实时聊天失效 location /websocket/ { proxy_pass http://127.0.0.1:8069/websocket/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; } }

这里面最容易被忽略的是 /websocket/ 这个 location，Odoo 17 的讨论和实时消息依赖它。如果只配置了普通的 proxy_pass，系统能打开，但聊天、通知这些功能会一直转圈。我第一次部署时就栽在这个地方，花了大半天排查才发现是 WebSocket 没配对。

HTTPS 证书这里我推荐用 certbot，因为它可以自动续期。申请证书前，先在 cloudflare 或阿里云 DNS 里把域名 A 记录解析到服务器公网 IP，确保通过 http 域名访问能拿到 80 端口响应，certbot 才能完成域名验证。然后执行：

apt install certbot python3-certbot-nginx certbot --nginx -d erp.example.com

certbot 会自动修改 Nginx 配置并启用 HTTPS，同时生成一个系统定时任务，每 60 天自动续期一次。续期后它会自动重载 Nginx，所以不需要你再手动处理证书过期问题。网上那些“阿里云 SSL 证书免费续期”的求助，其实都可以用 certbot 替代，体验会好非常多。

4.6 内存优化与 worker 参数调整

Odoo 17 在生产模式下，默认 worker 数量是 2，这个参数和服务器内存密切相关。简单计算逻辑是：每个 worker 大概占用 150M 到 250M 内存，加上数据库缓存和系统基础占用，2G 内存你最多只能开 2 个 worker，再多就会触发 OOM。默认配置通常已经算好了，不需要手动改。但如果你的服务器同时跑了定时任务和邮件队列，建议在 odoo.conf 里显式设置：

[options] workers = 2 max_cron_threads = 1 limit_memory_soft = 760000000 limit_memory_hard = 960000000

这组参数的含义是：CPU 密集型任务最多 2 个进程，每个进程的内存软限制 760MB、硬限制 960MB。超过这个限制后，Odoo 会自己回收或终止 worker，而不是让整个系统被系统级 OOM 杀死。

还有一个容易被忽视的点：Odoo 默认开启多语言和时区功能，会为每个支持的时区缓存一堆日期格式数据。如果你只需要中国时区，可以在系统设置里把“默认时区”改成 Asia/Shanghai，并关闭不需要的多语言支持，能省下不少内存和 CPU。

4.7 设置员工账号、权限和公司信息

进入后台后，按顺序执行下面的操作：先到“设置”里完成公司信息的填写；再到“用户”里创建管理员之外的账号。测试工程师可以直接用自己的邮箱登录，系统会自动生成账号；人事入职新员工时，则需要在 HR 模块创建员工档案，再关联到系统用户。这里有一个经验：员工档案和系统用户是两套数据，如果只创建了系统用户而没在员工模块里关联，审批流里的“找人”就找不到这个人，会出现“请假单无法选择审批人”的情况。很多新手在这里卡很久，实际上就是数据没有打通。

首次创建账号时，可以暂时把管理员账号之外的账号都归为“内部用户”，权限按模块逐个勾选。比如行政人员，只需要给她“审批”“休假”“员工”三个模块的权限；财务和订单相关的模块一概不勾。原则是：最小权限原则。多给权限不会让系统更好用，只会增加误操作风险。

5. 常见问题排查与经验技巧实录

光看部署过程，你可能会觉得一切顺利，但真实世界里总会有各种意外。我把几个出现频率高、且官方文档不太会详细讲的问题整理成表格，顺便附上我的排查思路和解决经验，方便你直接对着操作。

5.1 2G 内存服务器的终极调优方案

如果上面的配置都做好了，系统还是偶尔偏慢，思考方向不是继续加模块，而是做减法。第一步，停用不用的数据同步；第二步，关闭 Odoo 的“开发者模式”和详细日志，尤其是生产环境绝对不要开着 debug=1，它会输出大量 SQL 查询日志，非常吃资源；第三步，把不需要的报表缓存清掉，并定期用 VACUUM 清理 PostgreSQL 的膨胀数据。

# 清理 PostgreSQL 表膨胀，建议每月执行一次 docker exec -it odoo-db psql -U odoo -d odoo -c "VACUUM ANALYZE;"

这个操作能降低数据库占用的磁盘空间和查询响应时间。执行时最好在低峰期进行，我一般在凌晨 4 点配合备份脚本一起跑。

5.2 二次开发扩展：如何给开源系统加定制字段

很多企业用这套系统用久了，会遇到“标准模块不够用”的情况。比如你需要给客户档案增加一个“区域经理”字段，或者给采购订单增加一个“预算编号”。Odoo 支持低代码方式加字段，进入开发者模式后，在设置界面里可以直接添加字段、调整表单视图，不需要写代码。但如果你要做复杂逻辑，比如审批流里根据金额自动跳级审批，那就要自己写一个自定义模块，放到 ./addons 目录下，升级模块即可。

ERPNext 的二次开发思路也类似，基于 Frappe 框架的 DocType 概念，可以用命令行快速生成一个自定义模块。这里想提醒的是：如果公司内部没有 Python 或 JavaScript 开发能力，就不要轻易尝试深度改动，尽量通过标准配置满足需求。开源的魅力在于可定制，但定制就意味着后续要有人维护，小团队在这方面必须克制。

5.3 后续扩展：对接企业微信、钉钉与移动端

这套系统上线之后，员工最抱怨的往往是“每天还要打开一个网页去审批”。其实 Odoo 和 ERPNext 都有对应的移动端适配或第三方 App，不过国内团队更习惯用钉钉或企业微信。常见做法是通过 webhook 把审批通知推送到群机器人，或者在系统里集成钉钉/企业微信的扫码登录。对 2G 服务器来说，额外跑一个低代码集成工具可能负担较大，最省资源的方案是：用系统自带的“定时动作”和“外部邮件通知”推送提醒，让审批人在邮件里直接点击链接跳到系统处理。

如果后续真要对接企业微信，可以考虑使用开源社区里的 Odoo 企微模块，但由于 Odoo 版本迭代快，第三方模块经常出现版本不兼容问题，测试时要仔细确认模块支持 Odoo 17。

5.4 迁移和升级策略：从测试环境到生产环境

随着团队壮大，将来这台 99 元服务器可能不够用了，需要迁移到更高配置的机器。Docker 化部署的优势这时候才能真正显现：只需要在主服务器上把数据备份全部打包，在新服务器上重新执行 docker compose up -d，然后把备份文件恢复进去即可。数据库迁移的关键点是版本一致性，Odoo 数据库版本必须和代码版本一致，如果跨大版本升级（比如从 16 升到 17），不能直接恢复 dump，必须先在升级环境里跑一遍 Odoo 的数据库迁移工具，确保脚本自动更新数据库结构，否则会出现一堆字段缺失或视图报错。这个概念很关键，千万不要因为省事而跳过迁移验证。

我见过不少团队在这个阶段翻车：从旧服务器复制了数据卷，直接在新服务器启动镜像，发现页面能打开但刷新就报数据库错误，最后只能从头初始化。正确步骤永远是先备份、再测试恢复、最后切换流量。

根据我部署这套系统的经验，如果你只是给二三十人的小微企业做内部管理，99 元/年这台服务器是完全够用的。Odoo 14 时代可能对内存要求确实偏高，但 Odoo 17 的优化比 14 好不少，2 核 2G 配上 4G swap 跑生产环境是实测可行的。真正限制你的不是服务器性能，而是你对业务模块的配置能力和长期维护的耐心。系统上线只是第一步，后续把审批流、物料编码、财务科目真正用起来，才能让这套开源系统真正变成企业的运转中枢。