企业官网建设流程全解析

简介：面向需要快速搭建企业级 ERP 系统的开发与运维人员，这是一份基于 VMware 虚拟机中 Ubuntu 22.04 环境、通过 Docker 部署 ERPNext 14 的完整操作指南。内容从 Git、Docker 与 Docker Compose 的安装入手，包含依赖包安装、软件源与 GPG 密钥校验、用户组权限配置、docker-compose 版本检查，并针对 Docker Hub 拉取失败给出 daemon.json 镜像加速器配置方案；随后以汉化开箱即用镜像完成数据库创建与服务启动，每一步都配有命令和验证方法。资源为 docx 格式，共 1 个文件，压缩包大小 321KB；单篇步骤化部署笔记包含完整命令、配置示例与验证输出，便于实训教学或企业内部搭建时直接参照。当前已有 628 人下载学习。通过学习可完整掌握从系统准备、镜像加速到 ERPNext 14 容器化运行的关键操作，显著缩短部署时间；容器化方式也方便后续按业务需求扩展组件，并借助社区支持获得持续更新。

1. 虚拟机里跑ERPNext14：为什么这条路线最适合个人和企业内部部署

先给结论：在 VMware 虚拟机里装 Ubuntu 22.04，再在 Ubuntu 上安装 ERPNext 14，是我做过这么多企业内部系统部署里最省心、最不容易翻车的一条路径。ERPNext 是一套开源 ERP，覆盖采购、销售、库存、会计、HR 等核心模块，而 ERPNext14 是 Frappe 框架在 Python 3.10 / Node 14 生态下比较成熟的一个大版本，既避开了 v15 之后对 Node 版本和依赖包的新要求，也还没有 v16 那么多未稳定的新特性。对想低成本试水 ERP 的小团队，或者只想在一台旧服务器上跑内部系统的个人用户来说，虚拟机 + Ubuntu 22.04 + ERPNext14 这套组合，能把环境隔离、快照回滚、备份迁移都一并解决掉，比直接拿物理机裸装要稳得多。

这篇文章不绕弯子，直接从虚拟机参数怎么给、Ubuntu 22.04 装完要先调什么，到 bench 命令怎么跑、站点怎么建，再到我踩过的五个坑和最后的验收清单，全部按可复现的步骤写。新手照着做能装通，熟手也能从坑里省下半天时间。

2. 准备虚拟机与 Ubuntu 22.04：先把地基打牢

2.1 虚拟机创建时的三处关键参数：内存、磁盘与 CPU

很多人装 ERPNext 失败，不是 ERPNext 本身的问题，而是虚拟机起步参数给得太小。ERPNext14 在编译前端资源时（bench build 阶段）非常吃内存，官方建议生产环境 4GB 起步，但虚拟机里如果只给 2GB，bench 跑着跑着就会 OOM，进程被内核直接杀掉。我一般会在 VMware Workstation 里这样分配参数，这个思路也适用于 VirtualBox：

• 内存：至少 4GB，推荐 6GB。如果你的宿主机内存大于 16GB，直接给 8GB，后面跑 worker 进程和编译前端都会从容很多。
• 磁盘：至少 60GB，推荐 100GB。不要只算 Ubuntu 系统占用的 15GB，Docker 镜像、bench 的 env 目录、站点数据库、备份文件撑起来非常快，磁盘满了以后 MariaDB 报错会让你很难排查。
• CPU：至少 2 核，推荐 4 核。bench install 阶段要编译 Python 依赖和 Node 前端，核数多能明显缩短等待时间。

虚拟机创建的时候记得选择「稍后安装操作系统」，避免 VMware 自动用简易安装方式装出来的系统分区方案不合你的需求。磁盘控制器默认 NVMe 或 SCSI 都可以，不影响 Ubuntu 22.04 的安装。

创建完成后，进虚拟机设置里把「显示」的 3D 加速关掉，显卡内存给 128MB 就够。这不是装系统必需的步骤，但 Ubuntu 22.04 默认桌面环境是 GNOME，开着 3D 加速在虚拟机上容易出现花屏或黑屏进不去桌面的问题，提前关掉能少折腾一次。

2.2 安装 Ubuntu 22.04 并完成系统初始化：换源、SSH 与快照

Ubuntu 22.04 的镜像可以从官方源下载 ISO，安装过程本身没什么特别要说的，选「最小安装」即可，不要选「第三方软件安装」，那个选项会额外拉取闭源驱动和编解码器，在虚拟机上纯属浪费时间。分区用默认的「使用整个磁盘」就行，不需要手动做 LVM 或单独挂 /data，除非你后续有特别的备份策略。

系统装完以后，第一件事不是装 ERPNext，而是把系统源换成国内镜像源，这能省下大量 apt 下载时间。顺手开启 SSH 服务，这样你就能从宿主机用终端连进去操作，比在虚拟机窗口里复制粘贴命令舒服很多。流程如下：

# 换源：把 Ubuntu 官方源替换为清华镜像源 sudo sed -i 's@//.*archive.ubuntu.com@//mirrors.tuna.tsinghua.edu.cn@g' /etc/apt/sources.list sudo sed -i 's@//security.ubuntu.com@//mirrors.tuna.tsinghua.edu.cn@g' /etc/apt/sources.list sudo apt update && sudo apt upgrade -y # 安装 openssh-server 并启动 sudo apt install -y openssh-server sudo systemctl enable --now ssh # 查看虚拟机 IP，宿主机用 ssh 连接 ip addr show | grep inet

这里换源的命令只替换了主机名前缀，没有改动 sources.list 的文件结构。Ubuntu 22.04 之前的版本如果启用了 Ubuntu Pro 或 ESM 的话，sources.list 里还会有esm.ubuntu.com这类源，不过对全新安装的 22.04 LTS 来说不会遇到，不用管。

换源后执行 apt upgrade 时如果看到「daemon.json 被修改」的提示，直接按 N 保留现有版本即可，那是 Docker 相关提示，现在还没装 Docker，保留默认值就行。

SSH 连通后，我建议做一个快照。虚拟机的好处就在于做错了能回滚，这个快照价值极高——如果后面 bench init 失败把系统环境搞乱了，直接恢复到刚装完系统的快照，重新来过，比手动清理环境快得多。VMware 里右键虚拟机 -> 快照 -> 拍摄快照，命名成 Ubuntu-22.04-base，备注写「刚完成换源与SSH，未安装任何开发依赖」。

2.3 网络与存储的两个常见误配置及检查命令

虚拟机的网络模式我强烈建议用 NAT 而不是桥接。桥接模式下虚拟机会占用局域网独立 IP，如果宿主机所在网络有 MAC 绑定或 DHCP 地址池限制，虚拟机可能会拿不到 IP，或者 IP 经常变，导致你 SSH 断连。

NAT 模式下宿主机访问虚拟机用虚拟机自己的 IP 即可，我们从宿主机 SSH 进去完全没有障碍。真正要注意的是虚拟机里的 apt 和 pip 是否放行，NAT 模式默认没问题，但如果装系统时选过「限制本地网络」之类的选项，就要检查一下：

# 检查 DNS 解析是否正常 nslookup mirrors.tuna.tsinghua.edu.cn # 检查默认路由 ip route | grep default # 测试外部连通性 ping -c 3 baidu.com

ping baidu.com能通说明网络没问题。如果 ping IP 通但域名不通，基本是 DNS 配置问题，在 /etc/resolv.conf 或 netplan 配置里改成114.114.114.114就能解决。

存储方面常见的坑是虚拟磁盘没有做 preallocated。如果你创建虚拟机时选了「将虚拟磁盘拆分成多个文件」，那么虚拟机运行时磁盘性能会略差，bench init 阶段大量小文件读写时会更明显。已经装好系统的话不需要为此重装，影响不算大，但如果是新建虚拟机，建议选「立即分配所有磁盘空间」，备份时也方便。

另外一个容易忽略的是虚拟机的「磁盘空间」其实只代表虚拟磁盘上限，Ubuntu 里的分区大小还要看 LVM 或普通分区是否自动扩展。装完后用df -h看一眼根分区容量，如果只有 20GB 多，而在 VMware 里明明给了 100GB，说明分区没有对齐虚拟磁盘大小。这时用sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv && sudo resize2fs /dev/ubuntu-vg/ubuntu-lv扩容根分区。

提示：Ubuntu 22.04 默认安装会把剩余磁盘空间全部分配给根分区，正常情况下无需手动扩容。只有使用旧版 Ubuntu 镜像或手动分区时才会遇到这个情况。

3. 安装 ERPNext14 的完整路径：bench init 到创建站点

3.1 为什么选 ERPNext14 而不是 15/16：版本与依赖定位

先明确一个背景：ERPNext14 对应的是 Frappe 框架 v14，它在 2022 年发布，是当时基于 Python 3.10 和 Node 14 的主力版本。到了 2024 年之后 ERPNext15 和 v16 陆续成为主线，但它们对底层依赖的要求更激进——v15 需要 Python 3.11 以上且默认走 Docker 安装；v16 直接不再支持 bench 方式裸装，要求强制用 Docker 或 Kubernetes。

这里不存在「哪个版本更高级」的问题，只存在「哪个版本更适合虚拟机安装」。ERPNext14 是可以直接以源码方式跑在 Ubuntu 22.04 上的最后一个稳定主线版本，它的依赖树和 22.04 的 apt 源比较匹配，不需要额外折腾 Python 版本管理器。如果你的诉求是低成本快速上一个能用的 ERP，而不是追新功能，那么 v14 是最稳的选择。

bench 是 Frappe 的命令行工具，它负责创建虚拟环境、管理依赖、构建前端、配置 Nginx 和守护进程。装 ERPNext14 本质上就是装 bench，然后通过 bench 创建站点和安装 ERPNext 应用。

3.2 安装系统依赖与 Python 环境：一段可复制的脚本

在开始之前，我惯例先做一遍系统依赖安装。ERPNext14 在 Ubuntu 22.04 上的系统依赖包括 git、curl、redis-server、mariadb-server、nginx、python3-pip 等，其中 MariaDB 是 ERPNext 默认的数据库引擎，Redis 用于缓存和队列。

有一个细节需要注意：Ubuntu 22.04 的 Python 默认是 3.10，正好落在 Frappe v14 的支持区间内，所以直接用系统自带的 Python 3.10 即可，不需要装 pyenv 或手动编译。如果你手贱装了 Python 3.11 并把它设为默认，反而可能遇到依赖包编译失败的问题。

先安装基础依赖：

sudo apt install -y git curl redis-server mariadb-server nginx \ python3-pip python3-dev python3-venv python3-setuptools \ libffi-dev libssl-dev libjpeg-dev libpng-dev \ wkhtmltopdf xvfb # 配置 MariaDB，注意这里要用交互方式设置 root 密码 sudo mariadb-secure-installation

mariadb-secure-installation 过程中会问你 root 密码、是否移除匿名用户、是否禁止 root 远程登录等问题，建议统一回答：root 密码设一个强密码，匿名用户移除，root 远程登录禁止，test 数据库移除。这步做完后，需要手动编辑 MariaDB 配置文件，加入 ERPNext 要求的字符集和排序规则：

sudo tee -a /etc/mysql/mariadb.conf.d/99-erpnext.cnf > /dev/null <<EOF [mysqld] character-set-client-handshake = FALSE character-set-server = utf8mb4 collation-server = utf8mb4_unicode_ci EOF sudo systemctl restart mariadb

character-set-server 和 collation-server 这两行不加的话，后续创建站点时数据库默认字符集是 latin1，表单里输入中文会出现乱码或者保存报错。这是很常见的一个坑，很多人前面装得很顺，到录第一张采购单的时候发现中文全变问号，返回来看数据库字符集才发现问题。

Python 侧需要把 pip 源也切换成清华镜像，否则下载依赖包时会非常痛苦。同时升级 pip 和 setuptools，避免部分老包在当前环境下安装失败：

pip3 install --upgrade pip setuptools pip3 config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple pip3 config set global.trusted-host pypi.tuna.tsinghua.edu.cn

3.3 bench init 与创建新站点：命令、参数与逐行说明

系统依赖就绪后开始安装 bench。这里有一个版本问题：bench 最新版默认是为 ERPNext15/16 设计的，直接装最新 bench 再装 v14 会报依赖冲突。所以我用指定版本的方式安装：

# 用 pip 安装指定版本 bench，v14 对应 5.x 系列 pip3 install frappe-bench==5.22.1 # 初始化 bench 目录，frappe-bench 会自动创建虚拟环境并拉取 frappe 框架 bench init --version v14.14.0 erpnext-bench

bench init 过程中会依次做：创建 virtualenv、安装 Python 依赖（几百个包）、克隆 frappe 框架代码、安装 Node 依赖、构建前端资源。这个过程耗时长，取决于网速和机器性能，一般要 15 到 30 分钟。期间如果看到某个 pip 包编译失败，先别急着重跑整个命令，看清报错的是哪个包，通常是因为系统缺少某个库，装上对应的 -dev 包后重试即可。

注意 bench init 的--version参数指定的是 frappe 框架版本，不是 ERPNext 应用版本。frappe v14.14.0 对应 ERPNext 14.x 系列的可用版本范围，我通常用 frappe v14.14.0 配合 ERPNext 14.13.0，这两个版本组合经过验证比较稳定。如果你指定了 frappe 版本且没有指定 ERPNext 版本，后面 get-app 时会自动拉取对应主版本的 ERPNext。

初始化完成后，进入 bench 目录并创建站点。站点名建议直接用域名或项目名，比如erp.example.com，不要用 IP 地址。虽然 bench 支持 IP 作为站点名，但后续配置域名时不方便：

cd erpnext-bench # 创建新站点，--force 表示忽略已存在同名目录，--mariadb-root-password 指向刚设置的 MariaDB root 密码 bench new-site erp.local.com --mariadb-root-password '你的数据库root密码' --admin-password 'admin初始密码' # 从官方仓库拉取 ERPNext 应用（v14 分支） bench get-app erpnext --branch version-14 # 将 ERPNext 应用安装到站点 bench --site erp.local.com install-app erpnext

new-site 的参数里，admin-password 是 ERPNext 系统管理员的初始密码，登录后可以在系统设置里改掉。mariadb-root-password 对应的是你在 mariadb-secure-installation 里设置的 root 密码。install-app 执行完毕后，站点数据库里会创建几百张表，这个过程大概需要几分钟，正常完成后会看到一长串表名输出。

3.4 配置 gunicorn/nginx 与后台进程：让 ERPNext 跑在浏览器里

站点安装完成后，ERPNext 实际上还没有对外提供服务。bench 默认的开发模式是bench start，但那只是前台进程，用于调试不合适。生产环境应该用 bench 自带的 production 配置：

# 生成 nginx 配置并启用后台服务 sudo bench setup production erp.local.com # 查看服务状态 sudo supervisorctl status

setup production 会做三件事：第一，为站点生成 nginx 配置文件并写入 /etc/nginx/conf.d 目录；第二，创建 supervisor 配置文件，管理 gunicorn（Web 进程）、rq-worker（后台队列进程）和 schedule（定时任务）；第三，配置日志目录和缓存目录。执行完后应看到 supervisor 里至少有 frappe-web、frappe-worker-default、frappe-worker-long、frappe-worker-short、frappe-schedule 这几个进程处于 RUNNING 状态。

如果执行 setup production 时提示 nginx 配置测试失败，先跑sudo nginx -t看具体语法错误，绝大多数情况是 80 端口被占或 /etc/nginx/sites-enabled/default 里的默认站点冲突。Ubuntu 上常见的处理办法是删掉默认站点再重试：

sudo rm /etc/nginx/sites-enabled/default sudo systemctl reload nginx

浏览器里打开http://虚拟机IP，如果能看到 ERPNext 的登录页面，核心安装就算完成了。首次登录用你在 new-site 里设置的 admin 密码，登录后系统会先让你确认企业名称和默认货币，这里可以直接填中文，因为前面 MariaDB 已经改成 utf8mb4，不会出现乱码。

提示：VMware 虚拟机用 NAT 模式时，宿主机浏览器访问虚拟机 IP 没问题；如果想让局域网内其他机器也能访问，虚拟机网络模式要改成桥接，并且防火墙放行 80 端口。

4. 避坑与常见问题排查：虚拟机环境下最容易翻车的五个点

4.1 内存不足导致编译中途被杀

现象：bench init 或 install-app 过程中，终端最后几行输出是Killed或Segmentation fault，没有其他报错。重跑教程里的恢复命令bench setup production时提示某个进程状态为 FATAL。

原因：虚拟机内存不满足编译 Node 前端资源的峰值要求。Node 在构建 JavaScript 资源时通常需要 3GB 以上的可用内存，内存不足时 Linux 内核 OOM Killer 会直接杀掉 node 进程，而且不留下像样的日志，看起来像程序自己崩了。

解决：关掉虚拟机，在 VMware 设置里把内存增加到 6GB 以上再开机重试。不用重装系统，也不用清理已有文件，直接重新执行bench init，bench 遇到已存在的目录会提示是否覆盖，选覆盖或删掉 erpnext-bench 目录重来。另外可以临时加 2GB swap 缓解峰值压力：

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

4.2 时区问题导致单据时间差 8 小时

现象：ERPNext 里录一张采购单，保存后创建时间显示的比当前时间早 8 个小时。

原因：Ubuntu 22.04 虚拟机默认时区是 UTC，而国内时间用 UTC+8。ERPNext 存数据库时用的是 UTC 时间，页面展示时按系统设置里的时区转换。如果虚拟机系统时区是 UTC，而浏览器所在时区也是 UTC，就会把 UTC 时间直接当作本地时间显示，看起来少了 8 小时。

解决：把系统时区改为 Asia/Shanghai，同时确认 ERPNext 系统设置里的时区参数一致。

sudo timedatectl set-timezone Asia/Shanghai

登录 ERPNext 后依次进入「设置 -> 系统设置」，把时区选成Asia/Shanghai并保存。改完以后新建单据验证一次，如果不生效，重启 supervisor 管理的 frappe-web 进程：sudo supervisorctl restart frappe-web。

4.3 Nginx 默认站点覆盖：访问 IP 看不到登录页

现象：安装完成后访问虚拟机 IP，显示的是 Nginx 欢迎页或 Ubuntu 默认页面，不是 ERPNext 登录页面。检查 /etc/nginx/conf.d 里的 erpnext 配置存在，但就是没生效。

原因：Ubuntu 22.04 的 nginx 安装后自带一个 default server，监听 80 端口并指向 /var/www/html。ERPNext 生成的 nginx 配置文件也监听 80 端口，根据 server_name 匹配路由。用 IP 访问时 nginx 找不到匹配的 server_name，就回落到 default server，展示默认页面。

解决：删掉默认站点后 reload nginx。

sudo rm /etc/nginx/sites-enabled/default sudo nginx -t sudo systemctl reload nginx

同时确认 bench 生成的配置里 listen 80 且 server_name 包含你的站点名。如果你访问的 URL 是http://IP而没有用站点名，ERPNext 的 nginx 配置默认不会包含 IP 的 server_name，此时要么在 /etc/hosts 里把域名指向虚拟机 IP 后用域名访问，要么手动在 nginx 配置里加一行server_name _;让它成为默认站点。我一般推荐前者，保持域名访问语义清晰。

4.4 pip 下载超时或安装依赖包失败

现象：bench init 执行到安装 Python 依赖时卡住，或报Read timed out、Connection reset by peer，重试几次还是同样的位置失败。

原因：默认 pip 源访问速度太慢或连接不稳定。虽然 3.2 节已经推荐配置清华源，但如果你在 bench init 之前没有执行 pip3 config set，bench 创建的虚拟环境会使用默认源，下载大包装时极易超时。

解决：在 bench 目录下对虚拟环境单独配置 pip 源，或者直接重跑初始化。基准做法是在执行 bench init 前先跑一遍 pip config，这样虚拟环境创建时会继承全局配置：

cd /tmp python3 -m venv /tmp/piptest /tmp/piptest/bin/pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple

如果你已经装到一半失败了，不必删掉整个 bench 目录，进入 erpnext-bench 下的 env 虚拟环境里改 pip 源，再重新执行 bench init：

cd erpnext-bench source env/bin/activate pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple

再配一个超时时间避免再次卡死：pip config set global.timeout 60。改完后重新跑 bench init，注意如果刚才已经创建了 erpnext-bench 目录，要先rm -rf erpnext-bench再 init，否则 bench 会拒绝初始化到已有目录里。

4.5 重启虚拟机后服务全部丢失

现象：虚拟机重启后，浏览器访问 ERPNext 登录页面超时或连接拒绝，sudo supervisorctl status显示没有任何进程在运行。

原因：bench setup production 配置的 supervisor 服务虽然写入了 /etc/supervisor/conf.d，但 supervisor 本身没有设置开机自启，或者系统启动时 supervisor 先于 MariaDB/Redis 启动失败。另外 Redis 服务也可能因为没启用 systemd 服务而在重启后处于停止状态。

解决：先确认并启用依赖服务的自启，再看 supervisor：

sudo systemctl enable --now mariadb redis-server supervisor sudo supervisorctl reread sudo supervisorctl update sudo supervisorctl start all

这三步分别做：启用五个服务开机自启，重新读取 supervisor 配置目录里的变化，启动所有管理中的进程。之后重启虚拟机验证一次。

sudo reboot

重启后：

sudo supervisorctl status

看到所有进程都是 RUNNING，说明自启配置生效。如果某一个 worker 进程显示 FATAL，用sudo tail -n 50 /var/log/erpnext/worker.error.log查看日志，常见原因是 MariaDB 还没起来，等几秒后sudo supervisorctl restart frappe-worker-default即可。

5. 让 ERPNext14 在虚拟机里更好用：备份、域名与性能调整

5.1 定期备份的 bench 命令与恢复验证

备份这一步再懒也不能跳过。ERPNext 数据量大，SQL 文件可能上百 MB，但虚拟机场景下备份成本极低。bench 自带备份命令，可以同时导出数据库和文件：

cd erpnext-bench bench --site erp.local.com backup --with-files

这个命令会在erpnext-bench/sites/erp.local.com/private/backups/下生成一个 SQL 文件和一个文件压缩包，文件名带时间戳。加上--with-files会把私有文件目录（附件、打印格式等）一并打包，恢复时才能真正还原。

我习惯把备份目录挂到一个独立的虚拟磁盘或复制到宿主机共享目录，防止虚拟机磁盘损坏时数据跟着陪葬。另外要设置 crontab 定期执行备份，并且保留最近 7 天的备份，具体做法是用crontab -e加一行：

0 2 * * * cd /home/ubuntu/erpnext-bench && bench --site erp.local.com backup --with-files >> /var/log/erpnext-backup.log 2>&1

备份做完了，至少要手动验证一次恢复。恢复命令是bench --site erp.local.com restore后面跟备份的 SQL 文件路径，恢复前会先要求确认覆盖当前数据库。这一步真实做过的人不多，等哪天真要用了才发现备份文件是坏的，那就晚了。

5.2 绑定域名与 HTTPS 的注意点

如果这台虚拟机只在局域网内使用，用 IP 访问完全没有问题。但如果要让同事通过域名访问，或者以后要接入企业微信、钉钉之类的第三方应用，就必须绑定正式域名，并且启用 HTTPS。ERPNext 的 nginx 配置是基于站点名生成的，所以站点名最好一开始就用你规划的域名，避免后续改站点名。

实现 HTTPS 的标准姿势：先在 DNS 解析里把域名指向虚拟机 IP，然后使用 certbot 申请证书：

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

certbot 会自动修改你的 nginx 配置，加上 SSL 证书路径和 443 端口监听。注意一个坑：申请证书时要求域名必须能从公网解析到这台虚拟机，如果你只做了内网 DNS，Let’s Encrypt 会验证失败。内网部署场景下要么用自签名证书自己信任，要么用企业内部 CA，不要死磕公网证书。自签名的方式是openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/erp.key -out /etc/ssl/certs/erp.crt，然后把 nginx 配置里的证书路径指过去。

5.3 调整 Worker 数与内存占用

ERPNext 默认创建三个 worker 类型：default、short、long，分别处理不同的队列任务。默认配置下每个 worker 会起两个进程，总共六个 RQ worker，加上 gunicorn 默认的两个进程，内存占用在 2GB 左右。虚拟机内存如果只有 4GB，跑起来会比较紧张。

worker 数量的调整在 bench 的 Procfile 里配置，修改/home/ubuntu/erpnext-bench/Procfile：

web: gunicorn -w 2 -b 0.0.0.0:8000 frappe.app:application worker_default: bench worker --queue default --worker-type default worker_short: bench worker --queue short --worker-type short worker_long: bench worker --queue long --worker-type long

gunicorn 的-w参数控制 worker 进程数，改成 1 可以省近 300MB 内存。worker_default 这个条目里的--worker-type default可以去掉，只保留bench worker --queue default，这样默认队列只会启一个进程。改完 Procfile 后执行sudo supervisorctl restart all生效。

内存偏紧的场景下，还可以把 Redis 的 maxmemory 限制往下调，避免缓存把内存吃满。编辑/etc/redis/redis.conf，找到maxmemory参数改成512mb，然后sudo systemctl restart redis-server。这个参数对单站点小团队完全够用，对多站点高并发不适用，自己酌情取舍。

提示：改 Procfile 前先备份原文件，改坏了可以恢复后再 restar。worker 数量调完建议观察一天的负载再决定要不要加回去，不要一上来就盲目追求多进程，虚拟机场景下内存比 CPU 更稀缺。

5.4 虚拟机磁盘快照与系统升级的配合

虚拟机最实用的功能就是快照。ERPNext 升级前、系统 apt 升级前、修改 nginx 或 supervisor 配置前，都可以拍一个快照。VMware 里快照和备份是两个概念，快照是虚拟机状态的瞬时记录，备份是数据文件的可恢复副本，两者配合使用才能做到进可攻退可守。

我的习惯是：重大操作前拍快照，每天晚上用 crontab 做数据备份。快照不能替代备份，因为快照依赖虚拟机的虚拟磁盘文件，如果磁盘文件所在的宿主机存储坏了，快照也没了。备份文件我会另外复制到宿主机另一个物理磁盘或者 NAS 上。

这里提醒一句：快照拍得太多且不清理，会让虚拟磁盘文件越来越大，VMware 里的虚拟磁盘从单个 60GB 膨胀到上百 GB 很常见。建议在正常稳定运行状态保留一个「干净快照」，升级或改配置前拍「临时快照」，操作成功后合并临时快照，只留干净快照。

6. 安装完成后的验收清单：从登录到第一张采购单

安装结束不等于交付，我会按固定清单走一遍才宣布「能用」。这套清单的核心逻辑：验证登录、验证文件上传、验证工作流通知、验证附件和打印格式、验证中文显示。任何一步出问题，趁数据量小赶紧修，比用了三个月再修代价小得多。

6.1 用 site diagnose 做一次健康检查

bench 自带诊断命令，可以一次性输出站点相关的关键配置：

cd erpnext-bench bench --site erp.local.com diagnose

看输出里的几项：Site verbose 显示站点路径；MariaDB 版本是否在支持范围内；Redis 连接是否成功；worker 是否在运行；文件权限是否正常。诊断命令不会告诉你所有问题，但能帮你发现最显眼的配置缺失。

然后再手动检查两个地方：一是登录页面的 favicon 和静态资源是否正常加载（浏览器按 F12 看 Network 里有没有 404）；二是随便打开一个表单页面，看右上角有没有 JS 报错。如果控制台出现红色的 500 错误，大概率是 gunicorn worker 数量太少或内存不足，看/var/log/erpnext/web.error.log。

6.2 走一遍采购到付款的最小流程

ERPNext 有几十个模块，全测一遍不现实，但核心链路必须通。我的习惯是从「采购 -> 收货 -> 付款」这条业务主链路测起，因为这条链路涉及供应商主数据、采购订单、采购收货、付款申请、应付账款，几乎把 ERP 里最常见的对象都覆盖了。

建议流程：先在「设置 -> 公司」里确认企业名称和财务报表起始日期；再在「采购 -> 供应商」里新建一个测试供应商；录一张采购订单，添加物料行并保存；提交这张采购订单；做采购收货；最后在会计模块里做应付付款。每个节点都正常流转、状态从「草稿」变「已提交」，说明最核心的库存和财务状态机没问题。

顺便验证通知和邮件：在系统设置里配置企业邮箱，提交采购订单后看系统是否能正常发送邮件通知。如果 SMTP 没配好也不影响使用，只是提醒功能不可用，加上mailing模块要稍微花点时间调，所以通常放到第二个阶段再做。

6.3 我个人的维护习惯与建议

整套装通之后，我一般会再花十分钟做三件事。第一，把 admin 密码改成强密码，并创建两个子用户：一个管理员、一个普通业务员，日常登录用业务员账号，避免所有操作都在 admin 下。第二，备份 Procfile 和 nginx 配置到/home/ubuntu/config-backup/，以后升级或调整时能对照原配置。第三，写一个简单的系统状态脚本，放在 crontab 里定期检查 MariaDB、Redis、Gunicorn 的存活状态，异常时往系统日志里写一条记录。不需要上监控软件，虚拟机场景里一条systemctl is-active的 shell 脚本就够了。

这半年里我前后在虚拟机里装过三套 ERPNext，两套 v14、一套 v15。v15 在 Ubuntu 22.04 上也能装，但依赖处理明显更费劲，光 Python 3.11 的编译就折腾了一个下午。v14 的实际体验和功能完整度对于中小团队的内部管理够用，也一直有安全更新，短期内不会有「被迫升级」的紧迫压力。如果你正在虚拟机方案和 Docker 方案之间犹豫，我的建议很直接：个人试用或快速验证用 Docker，想长期运营且需要自己改代码的地方更灵活，就用这篇文章讲的 bench 源码方式。

最后一条提醒，也是我自己的教训：虚拟机里装 ERPNext 不是装完就算结束，数据库的定时备份、虚拟机的快照清理、系统日志的/var/log分区占用，这三件事至少每隔一个月检查一次。ERP 这种系统，平常感觉不到它的存在，一旦数据丢了或者服务挂了，才是真的麻烦。这篇文章能帮你把这套环境干净利落地搭起来，后面的维护守住底线，希望帮到你。

本文还有配套的精品资源，点击获取