Docker+MySQL+WordPress搭建个人博客：配置、部署与备份全指南-北京尧图网络

开篇先聊几句掏心窝的话。我见过不少人兴冲冲想搭个人博客结果卡在“安装环境”这一步就放弃了。WordPress安装包下好其实很容易难的是之后那一串连锁反应PHP版本不对、MySQL连不上、Nginx配置改错一处就白屏折腾一晚上一篇日志都没写成。后来我换成了 Docker MySQL WordPress 这套组合整个博客环境被装进几个互相隔离的容器里所有配置集中在一个 docker-compose.yml 文件里。换机器、迁移、恢复一条命令就能把整套环境拉起来。这篇文章就把我从零到上线、再到备份迁移的完整过程写下来重点解释每一个配置项为什么这么设置以及实操中反复踩到的坑。适合第一次接触 Docker、又不想被环境问题耗光热情的读者。1. 先把方案想清楚为什么是 Docker而不是直接装环境1.1 传统安装方式的问题到底出在哪很多教程会带着你在服务器上一步步装 Nginx、PHP、MySQL也就是所谓 LNMP 环境。这套路本身没毛病但放到新手身上就是灾难。最常见的情况是系统自带的 PHP 版本和 WordPress 要求的不一致或者 MySQL 8.0 新版本的认证方式和老插件不兼容WordPress 安装页面对数据库的连接判断本来就很敏感一个环节对不上页面就提示“建立数据库连接时出错”排查起来非常打击信心。而且服务器环境一旦被手动改动过后续升级很痛苦。今天为了解决一个报错改了 php.ini明天系统更新又把你改的覆盖了。个人博客的核心是写内容不是跟服务器环境和版本纠缠能用工具解决的问题真没必要手动硬扛。1.2 容器化在这个场景下解决了什么Docker 的本质是把应用连同它的运行环境一起打包成镜像容器启动后里面就有一套完整的、一致的环境。对博客来说WordPress 镜像里已经带好了 PHP 和 ApacheMySQL 镜像里带好了数据库服务我只需要把两者拉起来再告诉它们怎么通信、数据存在哪。这套方案的最大优势有三点第一环境一致。我在本地能跑起来到服务器上照样能跑不会出现“我这边明明好的”这种玄学问题。第二迁移方便。只要把挂载出来的数据目录带走到新机器上重新执行同样的启动命令整个博客就回来了。第三心智负担低。所有配置集中在一个 compose 文件里半年后想回忆当初怎么部署的看一眼文件就全明白了。当然容器也不是银弹它引入了一层网络和存储的抽象排错的时候要多想一层。但对个人博客这个量级的使用场景这些问题几乎不会造成实际困扰。1.3 组件选型和版本选择这里明确一下组合程序用 WordPress数据库用 MySQL。WordPress 本身支持 SQLite 之类更轻量的数据库但插件生态和社区文档基本都围绕 MySQL 展开后续遇到问题搜到的解决方案更多所以不需要在数据库选型上标新立异。镜像版本上我要给一句明确的建议MySQL 用 5.7别用 8.0。不是说 8.0 不好而是 8.0 默认的认证插件是 caching_sha2_password一些旧版本的 WordPress 驱动和图形化数据库工具连接时容易报错。博客这种场景没有非要上 8.0 才能满足的需求5.7 被生产环境验证了这么多年稳就是最大的优点。WordPress 镜像用官方镜像不需要自己构建。架构上我选的是 ports 映射方案宿主机 8080 端口映射到 WordPress 容器的 80 端口。为什么我不直接映射 80因为服务器上 80 端口很容易被其他服务占用先用一个高位端口跑通流程后面想绑域名、上 HTTPS再在最前面加一层反向代理这样每一步的验证成本都低。2. 核心配置逐项解析docker-compose.yml 里的每一行都不是随便写的2.1 先看数据库服务段直接上完整的 compose 配置后面逐段拆开讲。version: 3.8 services: db: image: mysql:5.7 container_name: blog_db restart: always command: --default-authentication-pluginmysql_native_password environment: MYSQL_DATABASE: wordpress MYSQL_USER: wpuser MYSQL_PASSWORD: wp_password_123 MYSQL_ROOT_PASSWORD: root_password_456 volumes: - ./db_data:/var/lib/mysql networks: - blog_net wordpress: image: wordpress:6.2-php8.1-apache container_name: blog_app restart: always depends_on: - db ports: - 8080:80 environment: WORDPRESS_DB_HOST: db:3306 WORDPRESS_DB_USER: wpuser WORDPRESS_DB_PASSWORD: wp_password_123 WORDPRESS_DB_NAME: wordpress WORDPRESS_DEBUG: 0 volumes: - ./wp_data:/var/www/html networks: - blog_net networks: blog_net:先解释 db 服务里这些环境变量。MYSQL_DATABASE 表示容器首次启动时自动创建的数据库名这里是 wordpress。MYSQL_USER 和 MYSQL_PASSWORD 是同时创建的一个普通业务账号WordPress 后面就用这个账号连接数据库。MYSQL_ROOT_PASSWORD 是数据库超级管理员密码平时用不到只在运维和备份时用所以我建议设置得复杂一点不要和业务账号共用同一个弱密码。很多人不理解为什么既要创建业务账号还要单独设 root 密码。这是数据库的基本安全习惯系统内的应用只应该拥有它需要的最小权限root 权限永远握在管理员手里。WordPress 的容器用 wpuser 连接即使密码泄露影响面也仅限于这一个数据库数据库实例的其他库还在 root 的保护之下。volumes 里的./db_data:/var/lib/mysql是整个方案里最重要的一行。容器是随时可以被删掉重建的容器内部任何未挂载的数据都会随之消失。MySQL 的数据文件默认写在 /var/lib/mysql如果不挂载到宿主机一个误删容器所有文章数据就全没了。挂载之后数据写入宿主机 ./db_data 目录容器怎么折腾都不影响数据本身。2.2 再看 WordPress 服务段WordPress 镜像选的是 wordpress:6.2-php8.1-apache。这里具体版本号会变核心原则是用官方镜像用带 PHP 版本的 tag不要随便用 latest。latest 会跟着官方更新跳动今天和半年后拉下来的可能不是同一个版本环境的一致性就没有保证。端口8080:80的含义是宿主机 8080 端口接收到的流量转发到容器内的 80 端口。由于 WordPress 镜像内部已经跑着 Apache容器内 80 端口就是 Apache 的默认监听口。这个映射关系在后期接入反向代理时会用到先建立这个概念。WORDPRESS_DB_HOST 是新手最容易写错的地方。这里填db:3306而不是localhost或127.0.0.1。因为在 Compose 创建的专用网络里每个容器可以通过服务名访问彼此db 就是 MySQL 容器的服务名3306 是 MySQL 的默认端口。如果填 localhostWordPress 容器会认为数据库在自己容器内部结果是无论如何都连不上。volumes 里挂载的是整个/var/www/html不是只挂 wp-content。这样做的原因很实际WordPress 安装时的配置、上传的附件、安装的插件、修改过的主题都写在这目录里。只挂 wp-content 能保留内容但下次容器重建后原来的安装配置状态会丢还需要重新走一遍初始化流程。整个目录挂出来容器就是彻底无状态的动态数据全在宿主机这是容器化部署的推荐姿态。2.3 网络、启动顺序和健康检查Compose 会为项目自动创建网络但这里我显式声明了blog_net并且让两个服务都加入。显式声明的好处是概念清晰而且以后如果这个博客栈要跟其他容器比如反向代理互通可以让它们加入同一个网络服务名解析就不需要暴露端口。服务之间的连接很多人依赖depends_on。但它只保证启动顺序不保证“数据库已经就绪”。第一次执行 docker compose up 的时候MySQL 容器要先初始化数据目录这个过程可能要几十秒而 WordPress 容器可能在这期间就尝试连接数据库了结果当然是连不上安装页报错。别慌这通常不是配置问题等 MySQL 完成初始化后在浏览器里刷新页面就会恢复正常。如果想做得更严谨可以给 db 服务加健康检查让 WordPress 等数据库真正 ready 后再启动。我在后面的进阶配置里会补这个写法。顺序上的缺陷通过编排可以规避但依赖关系设计上不要想当然“只要先启动就一定成功”。2.4 重启策略和调试开关两个服务都用了restart: always意思是容器异常退出后 Docker 守护进程会自动拉起它宿主机重启后也会自动恢复。对博客这种希望长期在线的服务来说这是必须的不然服务器重启一次你手动去启一次人不可能永远守在机器旁边。WORDPRESS_DEBUG 默认我设成0。日常使用不需要开启调试但如果你在开发主题或插件需要看到 PHP 错误信息可以改成1然后去浏览器访问页面WordPress 会把警告和弃用提示直接打到页面上。注意这只在排查问题时开排完立刻关掉生产环境开着调试会暴露服务器路径等信息。3. 实操全流程从一台干净机器到博客跑起来3.1 第一步准备 Docker 运行环境假设手头是一台全新 Linux 服务器系统是 Ubuntu 或 Debian 系。先升级系统包索引然后安装 Docker 和 Compose 插件。不同系统安装命令有差异这里给一个 Ubuntu 系的参考流程sudo apt update sudo apt install -y docker.io docker-compose-v2 sudo systemctl enable --now docker docker --version docker compose version如果你用的系统默认源里的 Docker 版本太旧优先参考 Docker 官方文档按对应系统安装。装完后执行 docker --version 确认成功。这里要提醒一句不建议一上来就加什么第三方脚本直接从系统官方源安装最省事版本可能不是最新但稳定够用。香港、海外之类的机器访问 Docker Hub 通常没问题但在某些网络环境下拉镜像会慢到怀疑人生。这种时候可以考虑给 Docker daemon 配置镜像加速源具体在 /etc/docker/daemon.json 里配置 registry-mirrors 列表然后重启 docker 服务。这一步属于环境优化不同网络情况处理方式不同按需配置即可。3.2 第二步建立项目目录并编写配置文件我习惯把博客项目放在 /opt/myblog。先创建目录并进入sudo mkdir -p /opt/myblog cd /opt/myblog在当前目录创建 docker-compose.yml把上一节的完整配置贴进去。注意配置里的数据库密码在生产环境中一定要换掉不要直接照抄示例密码。wp_password_123 和 root_password_456 这俩字符串一眼就能被扫描工具识别上线前必须改。创建好配置文件后直接启动sudo docker compose up -d第一次执行会拉取镜像耗时取决于网络和镜像大小。看到两个服务都是 running 状态就成功了。用以下命令验证docker compose psNAME IMAGE COMMAND SERVICE STATUS PORTS blog_app wordpress:6.2-php8.1-apache docker-entrypoint.s… wordpress running (healthy) 0.0.0.0:8080-80/tcp blog_db mysql:5.7 docker-entrypoint.s… db running (healthy) 3306/tcp这里能看到两个容器都已经起来并且 WordPress 容器的端口映射是 8080-80。MySQL 这行没有端口映射这是正常的因为 MySQL 只在容器内部网络中被 WordPress 访问不需要暴露到宿主机公网这样反而更安全。3.3 第三步完成 WordPress 初始化安装打开浏览器访问 http://服务器IP:8080会进入 WordPress 的语言选择界面。选择简体中文继续后会要求填写数据库信息。这里再强调一遍容易出错的位置数据库主机填 db不是 localhost数据库名wordpress与 MYSQL_DATABASE 对应用户名wpuser与 MYSQL_USER 对应密码你设置的 wp_password_123数据库前缀保持 wp_ 默认即可填写无误后点击提交系统会为你创建配置文件并跳转到“欢迎”页面接着设置博客标题、用户名、密码就完成了整套安装。如果这一步出现“建立数据库连接时出错”对照检查一下数据库主机是否填了 db以及 compose 文件里的用户名密码是否和使用的一致。安装完成后进入后台 Dashboard。我建议第一时间做三个基础设置在“设置-常规”里确认站点语言和时区AWS 里“服务器地址”和“站点地址”确认填的是以后要访问的域名或 IP 加端口在“设置-固定链接”里把默认的朴素链接改成“文章名”这样文章 URL 更好看也利于搜索引擎收录然后写一篇测试文章验证整个链路是通的。3.4 第四步验证持久化和日常启停流程安装完成后最该验证的一件事就是“数据持久化”。试着执行docker compose restart等几十秒再刷新博客文章还在。再狠一点直接删掉容器并重建docker compose down docker compose up -d只要 ./db_data 和 ./wp_data 目录在博客数据就完整保留。这是我推荐大家一定要亲手做一次的实验经历过以后你才会对容器不产生畏惧知道它只是一个可以被随时丢弃的“运行壳”真正的资产在挂载的目录里。日常运维中如果你想停止博客但不删除数据用docker compose stop想临时起一个改动后的环境用docker compose up -d想把容器、网络全部清掉又保留数据用docker compose down。这几个命令之间的区别就是停机级别和清理程度的不同建议在实际操作中多试几次感受一下。4. 备份与恢复博客最值钱的东西是数据4.1 备份策略怎么设计环境崩了可以快速重建配置丢了看一眼文件就能恢复但写到一半的文章、攒了几年的评论数据丢了就是不可逆的损失。所以搭建流程跑通之后第一优先级不是换主题不是装插件而是把备份机制建立起来。我的策略很简单数据库每天自动备份一次文件目录每周整体打包一次备份文件至少保留两周。个人博客更新频率不高这个节奏完全够用。如果哪天你频繁发文章可以把数据库备份改成每天两次凌晨和中午各一次。备份要区分逻辑备份和物理备份。逻辑备份是用 mysqldump 这类工具把数据导出成 SQL 文件优点是文件小、可读、兼容性好物理备份是直接复制数据库数据文件复制的过程中如果 MySQL 还在写入容易产生不一致所以物理备份一般要先把数据库停掉或者用文件系统快照。我日常用逻辑备份简单可靠恢复时也是一条命令的事。4.2 写一个数据库定时备份脚本在宿主机上新建一个备份脚本 /opt/myblog/backup.sh#!/bin/bash BACKUP_DIR/opt/backups DATE$(date %F) mkdir -p $BACKUP_DIR docker compose -f /opt/myblog/docker-compose.yml exec -T db \ mysqldump -uwpuser -pwp_password_123 wordpress | gzip $BACKUP_DIR/db_$DATE.sql.gz find $BACKUP_DIR -name db_*.sql.gz -mtime 14 -delete注意里面有两个容易被忽视的细节。第一mysqldump 要在 db 容器内执行所以用docker compose exec -T db mysqldump这样导出的数据库版本和实际运行的 MySQL 完全一致。第二exec 后面必须加 -T。因为定时任务里没有 TTYDocker 默认想给命令分配一个伪终端没有 TTY 时会直接报 “the input device is not a TTY”加上 -T 就是明确告诉 Docker 不需要终端按非交互方式执行。然后给脚本加执行权限并配置 crontabchmod x /opt/myblog/backup.sh crontab -e在 crontab 文件里写入0 3 * * * /opt/myblog/backup.sh /opt/myblog/backup.log 21凌晨 3 点跑一次这时基本没有访客对数据库的影响最小。备份日志单独保存用来排查定时任务是否正常执行。4.3 文件备份主题、插件、图片都不能丢数据库里的内容是文章数据、评论、用户信息但博客的视觉呈现——主题、插件、上传的图片——都存在于 wp_data 目录。这个目录同样要备份。我提供的方案是用 tar 打包整个 wp_data和数据库备份放在一起tar czf /opt/backups/blog_files_$DATE.tar.gz -C /opt/myblog wp_data如果你想备份到一个单独位置比如另一台机器或云存储压缩完把文件 scp 或 rsync 过去即可。这里我额外提一个本地小技巧备份脚本里可以顺手用 rsync 把整个 /opt/myblog 目录同步到一块挂载盘这样连 docker-compose.yml 本身也一起备份了。其实最优的“完整快照”方案是直接备份整个 /opt/myblog 目录它里面既有 db_data 又有 wp_data还有配置文件。tar 打包整个目录恢复的时候一条 tar 解压命令就还原整个项目再 docker compose up -d博客直接可用。数据库逻辑备份依然每天做作为“抢救单篇文章”的细粒度手段。4.4 恢复到底怎么操作演练一次备份做得再好没演练过的恢复流程都是纸面功夫。我建议每三个月在测试机器上模拟一次灾难恢复过程其实比想象中简单。假设新机器上已经装好 Docker把备份文件解压后恢复项目目录然后启动服务cd /opt/myblog docker compose up -d因为 db_data 目录里就是之前 MySQL 的完整数据文件MySQL 容器启动后直接就能读到旧数据wp_data 目录完整保留博客程序、插件、主题和图片。整个恢复过程没有“导入数据库”这个动作全部由挂载的目录自动完成。这就是我把两个数据目录都挂载到宿主机带来的最大红利。如果只想恢复某一天数据库备份中的内容而不是回滚整个项目目录用下面的方式cd /opt/myblog docker compose exec -T db sh -c \ mysql -uroot -proot_password_456 wordpress /opt/backups/db_2025-01-01.sql.gz注意这里用了 root 账号登录并且输入是用 gzip 压缩过的文件如果不先解压直接灌入数据库会变成一堆乱码。所以恢复时要先解压或者让管道直接经过 zcatzcat /opt/backups/db_2025-01-01.sql.gz | docker compose exec -T db sh -c \ mysql -uroot -proot_password_456 wordpress恢复完成后再确认一下博客内容是否正确。任何恢复操作前建议先把当前数据再备份一份防止操作失误把现有数据覆盖掉。5. 搭建和运行中的高频问题排查实录5.1 安装页提示“建立数据库连接时出错”这是出现频率最高的报错。从原因上说基本是三类一是 WordPress 容器启动时 MySQL 还没 ready这时刷新页面可能就好了二是填写数据库主机时用了 localhost没填 db三是 compose 文件里的数据库账号密码和填写页不一致。排查顺序建议是先看服务状态。docker compose ps docker compose logs db | tail -50然后确认 WordPress 容器里能否连通数据库docker compose exec wordpress php -r \ new PDO(mysql:hostdb;dbnamewordpress,wpuser,wp_password_123); echo ok;如果能输出 ok说明网络和账号都通。如果这一步报访问拒绝或认证失败那就是密码问题。这一步把环境变量里的密码和 phpMyAdmin 之类工具里看到的账号密码一一对上改掉错误密码再 down 掉重新 up。5.2 上传主题或图片时提示文件大小超过限制WordPress 默认的上传限制很小通常只有 2M。很多人把服务器里 php.ini 改了一遍又重启 Apache还是提示超限原因是WordPress 容器里的 php.ini 在容器内部你直接改宿主机文件跟它毫无关系。正确做法是在宿主机创建自定义 PHP 配置然后挂载进容器。在 /opt/myblog/php.ini 写入upload_max_filesize 32M post_max_size 32M memory_limit 256M max_execution_time 120然后在 docker-compose.yml 的 wordpress 服务 volumes 里加一行volumes: - ./wp_data:/var/www/html - ./php.ini:/usr/local/etc/php/conf.d/99-uploads.ini执行docker compose up -d让容器以新的配置重建再去后台试一次上传。注意 post_max_size 必须大于或等于 upload_max_filesize否则 PHP 会截断请求体。这个用挂载文件覆盖容器配置的思路后续改任何 PHP 参数都用得上不用再进容器手工 vi 了。5.3 容器重建后 WordPress 目录变得不可写这是一个典型权限坑。WordPress 容器内运行的用户是 www-dataUID 是 33。而宿主机上 /opt/myblog/wp_data 目录默认属于 root。容器内的进程尝试创建缓存、写入上传目录时会因为权限不足而失败。解决办法是让宿主机的目录所有者变成 UID 33sudo chown -R 33:33 /opt/myblog/wp_data这里不要图省事直接 chmod -R 777。777 会让宿主机任意用户都能修改博客文件给恶意程序留了后门。权限管理的基本原则是最小化给到够用的程度就好。执行权限修正后容器内就能正常写入了。如果之前已经出现过写入失败可能还要顺手清理下容器内残留的缓存文件。5.4 8080 端口被其他进程占用新机器上一般不会遇到但如果你在同一台服务器上已经跑了别的服务8080 可能被占了。查看监听情况sudo ss -lntp | grep 8080找到占用进程后要么处理冲突要么改映射。我带过的方案里最简单稳妥的是改 compose 文件里的 ports 为另一个高位端口比如8081:80然后重启容器。对 WordPress 本身来说容器内 80 端口不用改改的只是宿主机入口。等以后接入 HTTPS 反向代理入口基本就用不到这个映射端口了。5.5 新版 Docker 对 compose 文件版本声明的提示有时候执行 docker compose up 会在输出里看到一句话提示 version 字段已经废弃或不再被使用。这是正常现象新版 Compose 不需要 version 字段配置文件可以直接从 services 开始写。配置里保留 version 不影响运行只是会多一行提示。你要是看着碍眼删掉它也可以。5.6 常见问题速查表现象可能原因处理方式安装页提示数据库连接错误WordPress 容器早于 MySQL 就绪等待后刷新页面或给 db 加健康检查数据库连接错误且刷新无效数据库主机填写 localhost改为 db 并重启容器上传大文件超过 2M 被拒容器内 PHP 默认限制创建 php.ini 并挂载覆盖上传或安装插件提示目录不可写wp_data 目录属主与容器用户不一致chown -R 33:33 ./wp_data容器能启动但 8080 访问不了端口被其他服务占用更换宿主映射端口并重启MySQL 容器日志一堆认证报错MySQL 8.0 认证插件不兼容换成 mysql:5.7 镜像docker compose 命令不存在未安装 Docker Compose 插件安装 docker-compose-v25.7 一个关键的配置建议给 db 加健康检查前面提到 depends_on 不保证依赖服务就绪如果屡次遇到“第一次启动连不上”的情况建议在 compose 里给 db 服务加上健康检查db: image: mysql:5.7 container_name: blog_db restart: always command: --default-authentication-pluginmysql_native_password environment: MYSQL_DATABASE: wordpress MYSQL_USER: wpuser MYSQL_PASSWORD: wp_password_123 MYSQL_ROOT_PASSWORD: root_password_456 volumes: - ./db_data:/var/lib/mysql healthcheck: test: [CMD, mysqladmin, ping, -h, 127.0.0.1, -u, root, -proot_password_456] interval: 5s timeout: 3s retries: 20然后在 wordpress 服务里把 depends_on 改写成带条件的格式wordpress: image: wordpress:6.2-php8.1-apache container_name: blog_app restart: always depends_on: db: condition: service_healthy这样 WordPress 容器会等到 MySQL 健康检查通过后才启动从根上避免竞态问题。注意如果修改了组合配置里已经保存过的环境变量比如数据库密码需要先 docker compose down 清除旧容器再 docker compose up -d 重建否则旧容器里还保留着旧环境变量没有更新。6. 进阶优化从能跑到跑得稳、跑得安全6.1 如何接入域名和 HTTPS用 IP 加端口访问博客适合本地测试和个人折腾。真要对外发布建议至少做域名绑定和 HTTPS 加密。最简单的做法是在宿主机上再装一个 Nginx 做反向代理把 80 端口和 443 端口的流量转发到 127.0.0.1:8080。关键配置片段类似server { listen 80; server_name example.com; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }这里会用到前面提到的端口映射宿主机上 Nginx 监听 80反向代理到 8080。如果你后续给 WordPress 开 HTTPS协议头要正确设置 X-Forwarded-Proto否则后台会误判请求是 HTTP出现登录态失效或无限重定向的问题。证书方面申请免费证书服务后把证书路径填进 Nginx 配置并配置自动续期这部分不同平台的操作差异比较大按你实际使用的证书服务文档来即可。6.2 几个值得长期投入的性能习惯个人博客的访问量通常不大性能问题更多集中在数据库查询和 PHP 解释执行上。我建议在后台上装一个缓存插件开启页面缓存后访客第一次访问页面生成好的 HTML 静态页面会直接返回PHP 不再重复执行这一项对响应速度的提升是最明显的。如果图片资源多可以把上传目录迁移到对象存储或 CDN 上WordPress 有现成的插件可以实现按需配置即可。MySQL 层面如果你的文章数量很大了可以让数据库做一次检查和优化。但说实话个人博客如果日均访问量在几百以内单台服务器装这套组合完全够用不建议在配置上过度优化把时间留给写作和运营。6.3 安全加固的四个必须项第一不要把 MySQL 的 3306 端口暴露到宿主机公网保持 compose 配置里 db 服务不写 ports 映射。这样外部网络直接访问不到数据库只有内网中的 WordPress 容器能连。第二后台登录用户名不要用 admin安装时可以自己取一个别人猜不到的用户名。第三wp-login.php 这个入口要限流防止暴力猜密码简单做法是在反向代理层对这个路径加访问频率限制。第四WordPress 后台定期清理不用的插件和主题不活跃的旧版本插件是客户攻击面的入口。安全这件事做不到一劳永逸但以上几条能挡住绝大多数针对个人博客的自动化攻击。遇到疑似被改文件的异常状态优先从备份恢复排查太耗时不如重来干净。6.4 版本升级的节奏和注意点WordPress 有新版本出来后台会提示更新。升级前必须先备份数据这是铁律。备份动作在 4.2 节的脚本里已经有了执行一次即可。这里特别有一个教训MySQL 大版本升级不是简单把镜像 tag 从 5.7 改成 8.0。数据库主版本升级涉及数据文件的格式转换直接换镜像极容易导致数据目录读取失败风险很大。如果确实要升 MySQL 主版本那应该先逻辑备份全部数据再拉新版本镜像把数据导入新的空数据库并花时间认真测试所有插件和页面的兼容性而不是直接覆盖数据目录。7. 最后分享一点真实体会这套方案我实际用过几个项目最大的感受是容器化最值钱的不是“高科技感”而是它把人从环境维护里解放出来。以前改一个 php.ini 要小心翼翼怕影响其他站点现在所有 PHP 配置都在项目目录下的文件里动坏了 docker compose up -d 重建一个容器就行心里有底不怕折腾。有一个小习惯我建议从第一天就养起来备份脚本里除了打包数据顺手把恢复命令也打印到日志。真碰到灾难时刻人在紧张状态下容易忘命令日志里一行现成的恢复步骤能帮你少走不少弯路。这个细节平时不起眼关键时刻能救命。如果你也想学习这套方案今天就可以动手。先跑通安装和初始化再备份一次再把容器删除重来一次这个过程比看十遍教程都管用。做完这些你的博客才算真正拥有了一个站得住的根基。

Docker+MySQL+WordPress搭建个人博客：配置、部署与备份全指南

相关推荐

MapReduce核心原理与实战：从WordCount到分布式计算

富文本编辑器 rea：从技术选型到渲染性能的工程实践踩坑记录

生产级世界国家GeoJSON数据包：WGS84+ISO标准化+拓扑修复

更多资讯

嵌入式C与标准C的差异：内存、运行时与编译器行为解析

UWB定位锚点三合一实测：中继、定位、信标如何兼顾部署效率

PLC工程师实战错题本：90条现场踩坑经验与避坑指南

从零理解电机旋转电压矢量：Clarke/Park变换与SVPWM仿真实践

从零搭建步兵机器人：硬件选型、供电与通信全解析

读懂HCU控制模块说明书：状态机、标定与故障码排查

今日更新

微信云开发旅游小程序实战：LBS打卡+UGC社交全栈方案

金融AI代理平台核心拆解：从多代理协作到财报分析实战

基于大数据的智慧旅游推荐与可视化平台架构实践

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？