用Docker跑WordPress值不值

一、Docker化WordPress的真实成本账单

先把账摊开。Docker跑WordPress不是"装个软件"，而是多了一层要管理的东西：镜像、容器、数据卷、网络、以及一个编排文件。这五样东西每一项都有成本，其中数据卷这一项是绝大多数人栽跟头的地方。

容器本身的开销比想象中小。一个空的 Ubuntu 容器镜像，解压后占用磁盘大约 72 MB，实际运行时的内存占用在 3 到 5 MB。真正吃资源的是容器里跑的东西：PHP-FPM 的进程池、MySQL 的 InnoDB 缓冲池、Nginx 或 Apache worker，这三样你用裸机也要跑，Docker 并不会让它们变多。

但有三个额外成本是裸机没有的。

第一是存储层。容器写文件时用的是 overlay2 分层机制，第一层是只读的镜像层，上面叠一个可写层。可写层会随着运行时间不断膨胀，尤其是日志和上传文件被写进容器内部时。MySQL 的 binlog、Docker 的 json 日志、以及临时文件都可能躺在这里。

第二是镜像拉取时间。这是 Docker 化最实在的一次性成本。docker pull wordpress:latest 拉的是压缩后的镜像层，解压后大约 700 MB 上下；在国内带宽下按 5 MB/s 算，一次拉取约 140 秒。算上 PHP 镜像、MySQL 镜像和依赖层，一个完整的 WordPress 栈首次部署要拉 2 到 3 GB 数据，按 5 MB/s 需要 7 到 10 分钟。这是每个新环境都要重付一遍的成本。

第三是资源开销的"隐形税"。Docker 默认的 cgroup 限制如果没配好，容器内的 PHP-FPM 会按宿主机核数来分配 worker。4 核机器上默认起 4 个 worker 是正常的，但如果你同时跑三个容器，每个容器都起 4 个 worker，内存峰值就是 12 个 worker 叠加。裸机上你只需要手工配一次 pm.max_children，容器化之后这个旋钮分散在每个容器的配置里，忘了其中一个就会出事。

查看 iwebfusion 当前月价与库存

把这笔账折算成结论：Docker 化 WordPress 的首次部署成本增加 7 到 10 分钟，磁盘占用增加 1 到 2 GB（镜像加容器层），内存占用增加不超过 50 MB。它换来的是什么？版本切换从"重装系统加数据迁移"变成"换一个 tag 重新拉起"，环境一致性从"靠记忆和文档"变成"写进 Dockerfile"，多站点管理从"复制粘贴配置"变成"复制一行 compose 定义"。值不值，取决于你一年里要改几次版本、有几个站点、团队里有几个人会搭环境。

二、数据卷：Docker跑WordPress最容易翻车的地方

如果只看一句话的总结就是：数据必须出容器。这句话说对了，但没说出怎么落地。

Docker 容器的生命周期和它里面跑的程序不是一回事。docker restart 会重启进程但保留容器，docker rm 会删除容器——而容器里的所有数据会跟着一起消失。所以你必须把两类数据挂出来：数据库的数据目录，和 WordPress 的上传目录。

正确做法是用具名卷而不是宿主机目录挂载。具名卷由 Docker 管理权限和归属，WordPress 容器里的 www-data 用户（UID 33）能正常读写；而用 -v /data/wp:/var/www/html 这种宿主机路径挂载，新建的目录属主是 root，容器内写入会直接 Permission denied，除非手动 chown。

# 建两个具名卷
docker volume create wp_db_data
docker volume create wp_uploads

# compose 文件里的正确写法
docker compose up -d

version: "3.8"
services:
  db:
    image: mysql:8.0
    command: --default-authentication-plugin=mysql_native_password
    environment:
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wpuser
      MYSQL_PASSWORD: wpuserpass
      MYSQL_RANDOM_ROOT_PASSWORD: "yes"
    volumes:
      - wp_db_data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      timeout: 5s
      retries: 5
    restart: always

  web:
    image: wordpress:latest
    depends_on:
      db:
        condition: service_healthy
    ports:
      - "80:80"
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wpuser
      WORDPRESS_DB_PASSWORD: wpuserpass
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - wp_uploads:/var/www/html/wp-content/uploads
    restart: always

volumes:
  wp_db_data:
  wp_uploads:

这段配置里有两个细节值得单独说。第一个是 depends_on 配合 condition: service_healthy。数据库容器启动后需要十几秒到半分钟初始化数据目录，如果不做健康检查就启动 WordPress，WordPress 连不上数据库会在页面上报错，而此时数据库其实马上就好了——你会以为是配置错误，反复排查半天。加了 healthcheck 之后编排会等数据库真正可用才启动 WordPress。

第二个是 MYSQL_RANDOM_ROOT_PASSWORD: "yes"。容器里不需要留一个空密码的 root 账号，用随机密码生成一次反而不容易出事。这条不是必须，但成本为零。

第三个常见错误是 WordPress 容器里改的文件，重建容器后会丢。因为 WordPress 镜像的核心代码在镜像层里，你在容器内 vi 改 wp-config.php 或主题文件，docker compose down && up 之后修改全部消失。正确做法是把配置挂出来：

    volumes:
      - wp_uploads:/var/www/html/wp-content/uploads
      - ./wp-config-extra.php:/usr/local/etc/php/conf.d/zz-extra.ini

查 racknerd 在售套餐与库存

要改主题代码就用 bind mount 把主题目录映射出来，要改 php.ini 就挂一个 ini 文件进 conf.d。核心代码保持用镜像原版。

三、镜像与版本：一条命令的代价有多高

Docker 在 WordPress 上最大的价值是版本管理，但版本切换是有实际成本的，这个成本必须先算清楚。

一次版本升级包含三个动作：拉新镜像、重启容器、验证功能。拉镜像的耗时取决于层的大小和带宽。PHP 8.1 到 8.3 的官方镜像层约 100 MB 上下，按 5 MB/s 算约 20 秒；WordPress 主镜像从 6.x 换到 6.7 只需要拉增量层，通常几十秒。真正耗时的是验证：升级完必须手工点一遍后台、跑一次 wp core verify-checksums、检查插件是否兼容。

这里有一个必须知道的机制：WordPress 核心文件并不在容器可写层的常规位置，它挂载在 /usr/src/wordpress，容器启动脚本会把它复制到 /var/www/html。这个复制过程每次容器创建都会执行一遍，WordPress 核心文件约 60 MB，在普通 SSD 上约 1 到 3 秒，在低端 VPS 的机械盘或被限速 IOPS 的 VPS 上可能到 30 秒以上。

所以如果你要频繁切换版本，正确姿势是不要每次重建容器，而是用可持久化的方式：

# 方式一：直接换 tag 重建，wp-content 挂出来就不会丢
docker compose pull
docker compose up -d --force-recreate

# 方式二：保留挂载目录，用一次性容器执行 WP-CLI 做升级
docker compose run --rm --user 33:33 web wp core update --allow-root
docker compose run --rm --user 33:33 web wp plugin update --all --allow-root

WP-CLI 是必须装的工具，容器里没有它就得进容器手工改文件。给 WordPress 官方镜像装 WP-CLI 的标准做法是写个 Dockerfile：

FROM wordpress:latest
RUN apt-get update && apt-get install -y --no-install-recommends less \
    && curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar \
    && chmod +x wp-cli.phar && mv wp-cli.phar /usr/local/bin/wp

注意 docker compose run --rm 会创建一个临时容器并把端口留在原容器上不动，所以升级期间网站不会中断——这是它相对 docker compose down 的最大优势。

查 spinservers 在售套餐与库存

版本策略上给一条明确建议：生产站点固定在一个次版本上，只打安全补丁，不追主版本。WordPress 主版本（6.x 到 7.x）之间插件兼容性经常出状况，跨主版本升级应该在测试站点上先跑一周。测试站点和数据备份是 Docker 化唯一无法替代的价值——因为你有两套完整环境。

四、性能损耗：Docker 到底慢了多少

"Docker 有性能损耗"这句话是对的，但量级需要测出来才有意义。

文件系统层面，overlay2 的第一次读会走一遍合并目录查找，这带来的是首次访问的额外延迟。实测在 SSD 上的 WordPress 页面渲染，裸机与容器化的 TTFB 差异在 10 到 30 毫秒之间，波动主要来自数据库缓冲池的冷热状态，而不是容器本身。

网络层面，容器默认的 bridge 网络多一跳 NAT。同一台机器内的容器互通走的是虚拟网桥，延迟在 0.1 毫秒以内，几乎可以忽略。真正的区别在于：裸机上 Nginx 直连 PHP-FPM 是 Unix socket，零网络开销；用官方 WordPress 镜像时，Nginx 通过 FastCGI 连 PHP-FPM 默认走 TCP，容器内也是 localhost，但多了一次协议栈处理。改成 Unix socket 可以消除这一点。

内存层面，容器本身几乎不额外占内存，但 cgroup 限制和 page cache 的行为略有差异。Linux 内核的 page cache 在容器里是共享宿主机内核的，容器内的 free 命令会显示很少的可用内存，容易让人误判成"内存被吃了"。实际判断内存使用要看宿主机上的 free -m 和 docker stats。

真正的性能损耗在这三处：

磁盘 IO 争抢。容器和裸机在这一点上完全一样，但 Docker 化后你更容易在同一个卷上跑多个栈，加上 overlay2 的写放大，机械盘上的差距会放大。

镜像层膨胀导致的写放大。可写层里的每一次写都可能触发 copy-on-write，把大文件从上层拷贝出去。日志如果写在容器内 /var/log，跑几个月后这个层可能膨胀到几 GB，每次写都在做无谓的拷贝。

内存限制配置错误。容器内 free 显示的数值受 cgroup 限制影响，如果 PHP-FPM 容器设了 mem_limit 而 OPcache 又开得太大，容器会被 OOM Killer 直接干掉，表现是容器无预警重启。

# 正确判断容器真实内存占用
docker stats --no-stream

# 看容器内的 cgroup 限制（而不是 free 的输出）
docker exec wp-web cat /sys/fs/cgroup/memory.max
docker exec wp-web cat /sys/fs/cgroup/memory.current

# 查容器日志体积，看可写层有没有膨胀
docker inspect -f '{{.LogPath}}' wp-web | xargs ls -lh
docker system df

zenlayer 官网机型与实时报价

验收阈值可以直接这么定：Docker 化之后的 WordPress 首页 TTFB 必须小于裸机基线加 50 毫秒；数据库查询 P95 必须小于 200 毫秒；容器常驻内存总和必须小于宿主机可用内存的 70%；可写层大小必须小于 2 GB，超过就说明日志或上传写进了容器内部。

五、备份与恢复：Docker让备份变简单，但别做错

Docker 化在备份这件事上确实是净收益，前提是你用对了方法。

裸机备份 WordPress，你需要分别处理数据库和上传目录，还得保证两者的时间点一致——数据库备份到一半时用户上传了新文件，两边就对不上了。容器化之后，如果数据库和上传目录都在同一个卷里，docker run --rm -v vol:/source -v /backup:/backup alpine tar czf /backup/site.tar.gz -C /source . 一条命令就能得到一个时间点一致的快照。

# 备份数据库（逻辑备份，与物理卷互为补充）
docker compose exec -T db mysqldump -uwpuser -pwpuserpass wordpress | gzip > /backup/wpdb_$(date +%F).sql.gz

# 备份整个数据卷（物理快照，一致性更好）
docker run --rm \
  -v wp_uploads:/source:ro \
  -v /root/wpbackups:/backup \
  alpine tar czf /backup/uploads_$(date +%F).tar.gz -C /source .

# 列出卷，确认没漏
docker volume ls

关键是要同时做两件事：mysqldump 逻辑备份加数据卷物理备份。逻辑备份可跨版本恢复，物理备份恢复快但对版本敏感。只做其中一个都留隐患。

三个必须避免的错误：

第一，备份文件放在同一个卷里。如果卷损坏或被误删，备份跟着一起没了。备份必须落到宿主机目录或对象存储。

第二，用 docker compose down -v 做日常清理。-v 会连同具名卷一起删除，数据库和上传文件全部消失。这个参数在"重装环境"时是对的，在"清理"时是灾难性的。

第三，忘了备份 compose 文件和环境变量。数据库密码在 .env 或 compose 文件里，只备份数据不备份配置，恢复时你不知道密码是什么，照样起不来。所以版本控制里要同时管住 docker-compose.yml、.env、自定义的 Dockerfile 和 nginx 配置。

# 演练一次完整恢复：这是验证备份的唯一方式
docker compose down
docker volume rm wp_db_data wp_uploads   # 注意：这是演练，故意清空
# 用备份恢复
gunzip -c /backup/wpdb_2026-11-05.sql.gz | docker compose exec -T db mysql -uwpuser -pwpuserpass wordpress
docker run --rm -v wp_uploads:/target -v /root/wpbackups:/backup alpine \
  tar xzf /backup/uploads_2026-11-05.tar.gz -C /target
docker compose up -d

查 cloudcone 在售套餐与库存

恢复演练要定期做，季度一次足够。备份文件存在但恢复不出来，是最常见的数据事故原因。

六、算账：不同规模的站点该配几核几G

现在把 Docker 这层开销加进配置选择里，用真实价格算。

当前渠道库里的真实机型数据是这样的。sixtynet 的 LAX-STARTER 是 200 美元年付，折合每月 16.67 美元，2 核 2 GB 内存、40 GB 磁盘、2000 Mbps 端口、5000 GB 月流量，每 TB 流量 3.413 美元；LAX-MICRO 是 400 美元年付，折合每月 33.33 美元，4 核 4 GB、80 GB NVMe、4000 Mbps、10000 GB 流量，每 TB 同样是 3.413 美元；LAX-MEDIUM 是 800 美元年付，折合每月 66.67 美元，8 核 8 GB、160 GB NVMe、10000 Mbps、20000 GB 流量，每 TB 3.413 美元；LAX-LARGE 是 1600 美元年付，折合每月 133.33 美元，8 核 16 GB、320 GB NVMe、10000 Mbps、40000 GB 流量，每 TB 3.413 美元。存储特化机型 LAX-Storage-500G 是 400 美元年付、折合每月 33.33 美元，4 核 4 GB、500 GB 磁盘、10000 Mbps、10000 GB 流量，每 GB 磁盘仅 0.067 美元；LAX-Storage-1TB 是 700 美元年付、折合每月 58.33 美元，8 核 8 GB、1000 GB 盘、15000 GB 流量，每 GB 磁盘 0.058 美元。

按月计费的云途系列里，HK.DS.M 是 350 元每月、32 GB 内存、480 GB 盘、1000 Mbps、10000 GB 流量，每 GB 内存约 10.94 元；HK.DS.P 是 750 元每月、64 GB 内存、1024 GB 盘、2000 Mbps、40000 GB 流量，每 GB 内存约 11.72 元；HK.DS.S 是 800 元每月、128 GB 内存、6000 GB 盘、2000 Mbps、40000 GB 流量，每 GB 内存约 6.25 元、每 GB 磁盘约 0.133 元，超额流量重置价 500 元；HK.DS.B 是 1200 元每月、128 GB 内存、2000 GB 盘、1000 Mbps、40000 GB 流量；DS.ES.B 是 1500 元每月、256 GB 内存、1920 GB 盘、2000 Mbps、30000 GB 流量，每 GB 内存约 5.86 元。

RosCloud 系列（justg 在售，俄罗斯节点）全部按月计费、500 Mbps 端口：RosCloud-01 是 19.99 美元每月、2 核 1 GB、20 GB 盘、1024 GB 流量，每 GB 内存 19.99 美元；一路到 RosCloud-06 是 69.99 美元每月、7 核 24 GB、320 GB 盘、6144 GB 流量，每 GB 内存降到 2.92 美元、每 GB 磁盘 0.219 美元、每 TB 流量 11.665 美元。

现在把 Docker 的开销加进去。

单站点、个人博客、日 PV 500 以内。裸机 WordPress 加 MySQL 加 Nginx 的最低可用配置是 1 核 1 GB，Docker 化之后因为要加 1 到 2 GB 磁盘给镜像层、还要多留 512 MB 给 overlay 缓存，实际最低是 2 核 2 GB 起。看价格，RosCloud-01 的 19.99 美元是 2 核 1 GB，内存不够跑 Docker 版 WordPress，得往上一档；sixtynet 的 LAX-STARTER 是 2 核 2 GB、折合每月 16.67 美元、5000 GB 流量，按这个配置跑一个日 PV 500 的 WordPress，流量占用约每月 500 GB，余量充足。这条路的单价比内存单价更重要——LAX-STARTER 的每 GB 内存是 8.33 美元，比 RosCloud-01 的 19.99 美元低一半以上。

单站点、企业站、日 PV 5000 到 2 万。需要 4 核 4 GB 起步。LAX-MICRO 是 400 美元年付、折合每月 33.33 美元、4 核 4 GB、10000 GB 流量，每 GB 内存 8.33 美元、每 TB 流量 3.413 美元；流量侧按每页 500 KB、单页 3 个静态资源估算，日 PV 2 万时每月出站约 300 GB，占 10000 GB 额度的 3%。这块流量在几个方案里都不构成瓶颈。

多站点、每天发布更新。多个站点共用一套 MySQL 服务、每个站点一个容器，加一个反向代理统一入口，内存需求是所有站点之和再加 30% 的余量。这个场景下内存单价成为主要变量：云途 HK.DS.S 每 GB 内存 6.25 元、128 GB 总内存 800 元每月，是大内存场景里性价比最高的；DS.ES.B 每 GB 内存 5.86 元更低但只有 30000 GB 流量且每 TB 流量单价 51.2 元，流量不敏感的业务更划算。

大存储型媒体站。上传量大、可写层容易膨胀、要做镜像快照，看存储单价：LAX-Storage-1TB 每 GB 磁盘 0.058 美元、LAX-Storage-500G 每 GB 磁盘 0.067 美元，都远低于按普通机型折算的水平。但要注意这类机型的流量并没有同步放大，LAX-Storage-1TB 是 15000 GB 流量、每 TB 3.982 美元。

digitalocean 官网机型与实时报价

统一结论：Docker 化对配置的要求比裸机高半档到一档，主要压力在内存和磁盘，不是 CPU 和带宽。所以选型时把裸机方案往上抬一档就是安全余量。

七、什么情况下不该用 Docker 跑 WordPress

这一节是本文最该被记住的部分。以下几种情况，Docker 化带来的成本明确大于收益。

机房位置决定了运维成本被放大的程度。俄罗斯节点的机器，跨境回程本身就慢，你每次 docker pull 要多花几分钟、每次 SSH 进去执行命令都要等延迟。RosCloud 系列虽然配置单价随档位下降很划算——RosCloud-06 每 GB 内存 2.92 美元、每 TB 流量 11.665 美元，配置性价比确实好——但每 TB 流量单价是美西方案的数倍，跨境拉镜像的流量本身也要计费。替代方案：如果业务确实需要俄罗斯方向的 IP 或地理位置，就把它定位成生产节点，日常部署和镜像仓库放到美西或就近节点，用私有仓库同步镜像，把拉取距离压到最短。

存储类型决定可写层的代价。Docker 的 overlay2 写放大在机械盘上非常明显，容器可写层每次写文件都可能触发 copy-on-write 拷贝。上面提到的 LAX-MEDIUM 和 LAX-LARGE 明确标注 NVMe SSD，这一点很重要；而标注 SAS HDD 的机型（如云途 HK.DS.S 是 SAS HDD）上跑 Docker，日志写入和数据库 binlog 会明显拖慢。替代方案：在 SAS HDD 机型上不用 Docker，直接裸机装；或者把容器日志转到 stdout 让 Docker 走 json-file 并加 max-size 限制，把可写层压到最小。

计费方式按流量走的时候，Docker 的镜像层是净成本。云途 HK.DS.S 的 40000 GB 流量用完后重置价是 500 元，HK.DS.B 只有 1000 Mbps 端口。每拉一次镜像就要消耗出站流量，跨节点同步、数据库迁移、副本备份全都要算流量。替代方案：部署用的镜像提前拉好并保留在机器上（docker image prune 别乱删），用 docker save / docker load 在内网节点之间传镜像避免重复走公网。

IP 资源需要频繁更换的场景。容器化后重建容器会换 IP 吗？取决于你怎么配网络。用 bridge 网络的话容器内网 IP 会变，如果你的站点依赖固定 IP 做白名单、SSL 绑定或者第三方回调白名单，重建容器就会断。替代方案：给需要固定 IP 的服务用 network_mode: host 或者 macvlan 网络；或者干脆把这一层用 Nginx 反代统一收口，外部只认宿主机的固定 IP。

IP 数量受限。上面几个套餐的 IPv4 数量在数据里普遍没有标注，需要以官网当日报价为准。有些商家对每个 VPS 只分配一个 IPv4，如果你需要在同一台机器上跑多个需要独立 IP 的站点，容器化并不能帮你绕过这个限制。

查 hostwinds 在售套餐与库存

团队只有一个人且站点只有一个。这时候 Docker 带来的主要是 YAML 文件、镜像体积、命令变长这些学习成本，而收益（多环境、多人协作、版本切换）都用不上。替代方案：裸机 + 一键脚本，比 compose 文件更好维护。

八、监控与日常运维命令

Docker 化之后运维的重心变了。不再是"这个服务还活着吗"，而是"这个容器在正常消耗资源吗、有没有在偷偷重启"。

# 一次性看全部容器的资源占用
docker stats --no-stream

# 看容器有没有在重启循环（RestartCount 是关键指标）
docker inspect -f '{{.Name}} {{.RestartCount}} {{.State.Status}}' $(docker ps -q)

# 看容器日志的最后 100 行
docker compose logs --tail=100 web

# 实时跟日志
docker compose logs -f web

# 进容器（注意用 www-data 用户，否则生成的属主是 root）
docker compose exec --user 33:33 web bash

# 看容器内的 PHP 错误日志和 WordPress 调试日志
docker compose exec web tail -50 /var/log/php/error.log
docker compose exec web tail -50 /var/www/html/wp-content/debug.log

有三个指标必须建告警：

RestartCount 增长。任何容器重启次数持续上涨都说明有问题，常见原因是 OOM 被杀或者数据库连接失败。超过 3 次就该查。

可写层大小。用 docker inspect -f '{{.GraphDriver.Data.UpperDir}}' 拿到路径后 du -sh，超过 2 GB 就说明有东西在往容器里写垃圾。

磁盘整体水位。df -h 看宿主机根分区，Docker 的镜像和容器层都在 /var/lib/docker，这个分区满了会直接导致所有容器写失败。超过 80% 要清理。

# 清理无用镜像和停止的容器
docker image prune -a -f
docker container prune -f
# 注意：docker volume prune 会删掉未挂载的卷，务必确认里面没有数据

WordPress 自身的健康检查用 WP-CLI 一行就能做：

docker compose exec web wp core is-installed --allow-root && echo OK
docker compose exec web wp db check --allow-root
docker compose exec web wp option get siteurl --allow-root

查看 interserver 当前月价与库存

把这几条塞进 cron 做定时巡检，比人工点后台靠谱得多。

九、选型结论：四类人的明确建议

第一类：只有一个站点、一个人维护、只是想尽快把站上线。 不要用 Docker。用裸机装 LNMP，把内存留给 PHP 和 MySQL。看配置的话，2 核 2 GB 是起点，sixtynet 的 LAX-STARTER 是 200 美元年付、折合每月 16.67 美元，2 核 2 GB、40 GB 盘、2000 Mbps、5000 GB 流量，每 GB 内存 8.33 美元、每 TB 流量 3.413 美元；内存更多的话 LAX-MICRO 是 400 美元年付、折合每月 33.33 美元、4 核 4 GB NVMe、10000 GB 流量。这两个配置跑个人博客都绰绰有余，把省下来的时间花在内容和推广上更划算。

第二类：手上有多个 WordPress 站点，或者要同时维护测试环境和生产环境。 用 Docker，这正是它价值最大的地方。配置上建议 4 核 4 GB 起步（LAX-MICRO 那档），内存要留出所有站点之和的 30% 余量；站点数量超过 10 个或者内存需求超过 32 GB，就看云途 HK.DS.S（800 元每月、128 GB、6000 GB SAS HDD 盘、2000 Mbps、40000 GB 流量，每 GB 内存 6.25 元）或 HK.DS.P（750 元每月、64 GB、1024 GB、2000 Mbps、40000 GB 流量），后者磁盘是 SSD 系更适配 Docker 的写放大。数据库要独立成一栈，不要和网站容器混在一起。

第三类：做外贸、建站群、或者要批量铺站。 Docker 几乎是必需品，因为你会需要几十上百套完全一致的环境，并且随时能推掉重来。选型上优先看单价能压到什么程度：LAX-Storage-500G 是 400 美元年付、4 核 4 GB、500 GB 盘、10000 GB 流量，每 GB 磁盘 0.067 美元；批量铺站还要给每套环境预留独立 IPv4，这一条必须以官网当日报价为准，确认每台机器的 IP 数量和更换政策。

第四类：做开发、测试、或者临时演示环境。 用 Docker，按量或者按月付费，用完就删。看单价的话，RosCloud-01 是 19.99 美元每月、2 核 1 GB、20 GB 盘、1024 GB 流量、500 Mbps 端口，每 GB 内存 19.99 美元——单价看起来高，但它是最便宜的一档，跑个演示绰绰有余。需要更大内存时往上一档到 RosCloud-03 是 39.99 美元、4 核 4 GB、80 GB 盘、3072 GB 流量，每 GB 内存降到 10 美元、每 GB 磁盘 0.5 美元。注意这是俄罗斯节点，跨境访问延迟高，只适合后台型用途。

查看 itldc 当前月价与库存

综合判断：Docker 化 WordPress 在"多环境、多站点、需要版本可控"的场景下是明确的正收益；在"单站点单人生"场景下是负收益。至于选哪家的机器，判断顺序应该是——先看机房位置对不对，再看流量额度够不够，最后才比配置和价格。上表里每 GB 内存和每 TB 流量的单价可以直接横向比，不必被总价迷惑。

按你的情况，下一步该看哪家

上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：

• 只想搭个站、预算优先：先看价格最低那档够不够用，别为用不上的配置付钱。看 iwebfusion 当前机型与价格
• 做跨境或店群、需要多 IP：优先看 IP 类型与换 IP 政策，别只看配置。看 racknerd 当前机型与价格
• 主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 spinservers 当前机型与价格
• 只是开发测试、临时用：按小时或月付，用完就删，别买年付。看 zenlayer 当前机型与价格

价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。

十、常见问题

Docker 跑 WordPress 会损失多少性能？ 实测 SSD 上 TTFB 差异在 10 到 30 毫秒之间，数据库查询和页面渲染的 P95 延迟差异基本在噪声范围内。真正的损失来自磁盘写放大和错误的内存限制配置，不是容器机制本身。验收时把"TTFB 不得比裸机基线高出 50 毫秒"作为红线即可。

容器里改了 wp-config.php，重启后为什么丢了？ 因为 WordPress 镜像的核心代码在镜像层，你改的是可写层。要持久化有两种办法：把配置文件 bind mount 挂进 /usr/local/etc/php/conf.d/，或者把核心代码目录整个挂出来。推荐前者，配置文件本身很小。

数据卷用具名卷还是宿主机目录？ 具名卷。宿主机目录挂载新建目录属主是 root，容器内 www-data 写不进去，直接 Permission denied。具名卷的权限由 Docker 处理好，备份时用 docker run --rm -v 卷名:/source ... tar 导出即可。

docker compose down -v 能不能用？ 只能在明确要销毁全部数据时用。-v 会删除具名卷，数据库和上传文件全部丢失。日常清理用 docker compose down（不带 -v）加 docker container prune，卷会保留。

两个容器之间怎么让 WordPress 连上数据库？ 用 compose 里的服务名而不是 localhost。同一个 compose 项目内，服务名会解析到容器网络里的内部地址，WordPress 的 WORDPRESS_DB_HOST 应该写 db:3306。写 localhost 是最常见的错误，会报 Can't connect to MySQL server。

Docker 版的 WordPress 怎么更新？ 生产环境用 docker compose exec --user 33:33 web wp core update --allow-root 加 wp plugin update --all --allow-root，用 run --rm 创建临时容器执行，这样网站不中断。更新前先备份，且固定在同一个次版本上打补丁，不要跨主版本追新。

容器里 MySQL 一直显示 starting 或者 unhealthy 怎么办？ 首次启动 MySQL 需要初始化数据目录，耗时十几秒到半分钟，属正常。但如果超过两分钟还不行，看日志确认是不是磁盘空间不足、或者旧版本的 mysql 数据目录与新镜像不兼容。跨大版本升级时，MySQL 8.0 的数据目录不能直接给 8.4 用，需要先在旧版本做逻辑导出。

怎么知道容器有没有在被 OOM 杀掉？ docker inspect -f '{{.RestartCount}} {{.State.OOMKilled}}' 容器名，OOMKilled 为 true 就是被内存限制杀了。dmesg -T | grep -i "killed process" 也能看到内核日志。解决办法是提高容器的内存限制，或者降低 PHP-FPM 的 pm.max_children 数量。

能在 Docker 里跑宝塔面板吗？ 技术上可以，但不推荐。宝塔面板自己会装一套 LNMP 和数据库，和容器里的 WordPress 镜像功能重叠，两套环境抢同一个 80 端口还容易互相覆盖配置。宝塔更适合裸机环境，Docker 环境用 docker compose 管理更干净。

Docker 化之后站点变慢了，先查什么？ 顺序是：先 docker stats --no-stream 看有没有容器内存打满或 CPU 打满，再看可写层大小是否异常，然后查 MySQL 慢查询日志，最后才看宿主机有没有其他负载。绝大多数情况问题出在某个容器的 pm.max_children 配得太大、或者日志文件在容器里无限增长。