aaron我在 Synology NAS 上部署 WordPress 时，更倾向于自己准备官方安装包，再通过 Container Manager 手动组织 WordPress、MariaDB 和可选的 Redis 服务。这样做的好处是版本和目录都掌握在自己手里，后续更新时也不必完全依赖套件中心提供的版本。
这次部署目标是 WordPress 6.9.3，适合已经熟悉 DSM、共享文件夹和容器基本操作的个人站长或 IT 管理员。需要先说明一点：Redis 不是 WordPress 初次安装的必需组件，PHP 与 MariaDB 才是基础运行环境。Redis 更适合在站点能够正常运行后，再根据缓存需求逐步加入。
开始前的准备
部署前先在 DSM 中确认 Container Manager 可以正常使用，并准备一个专门存放站点数据的共享文件夹。不要把 WordPress 文件、数据库文件和备份文件全部混在同一个临时目录里，否则后面更新或排查权限时很容易误删数据。
建议至少规划三个目录：
- WordPress 程序目录，用来保存官方安装包解压后的文件；
- MariaDB 数据目录，用来保存数据库服务的数据；
- 备份目录，用来保存数据库备份和 WordPress 文件备份。
目录名称可以按照自己的 NAS 习惯设置，关键是路径要稳定、容易识别，并且不要频繁改动。容器创建完成后，目录映射关系也不要随意调整。
同时准备好以下信息：
- NAS 在局域网中的地址；
- WordPress 对外访问的端口；
- 数据库名称；
- 数据库用户名和密码；
- WordPress 管理员账号和密码；
- 是否需要启用 Redis。
数据库密码不要与 WordPress 管理员密码重复。站点如果计划从公网访问，还应提前考虑反向代理、HTTPS 和访问控制，而不是只把容器端口直接暴露到互联网。
下载并准备 WordPress 6.9.3
从 WordPress 官方发布渠道下载 6.9.3 安装包。下载时要确认文件确实对应这个版本，不要把旧目录中的文件与新版本文件混合使用。
将压缩包上传到 NAS 后，解压到预先准备好的 WordPress 程序目录。解压完成后，应该能在该目录中看到 WordPress 的核心文件和目录，而不是多套嵌套目录。
常见的错误是解压后形成类似“程序目录/WordPress 目录/核心文件”的结构，但容器映射的却是最外层目录。这样访问站点时可能看到目录列表、空白页面或安装程序找不到文件。创建容器前，应先确认 WordPress 核心文件实际位于映射目录的根部。
如果使用文件管理器操作，还要检查文件是否因为上传过程被放入了只读位置。程序目录需要能够被 Web 服务读取，后续安装插件、更新核心或上传媒体时，还可能需要相应的写入权限。
创建 MariaDB 数据库容器
在 Container Manager 中创建 MariaDB 容器时，重点不是容器名称，而是数据目录映射和初始化参数。
数据库数据目录必须映射到 NAS 上的持久化目录。否则容器删除或重建后，数据库可能随容器一并丢失。创建完成后，不要只确认容器“正在运行”，还要确认 NAS 对应目录已经出现数据库文件。
初始化时需要设置数据库服务使用的管理员密码，并为 WordPress 单独准备数据库和数据库用户。WordPress 不建议长期使用数据库超级管理员账号连接，单独的数据库用户更容易控制权限，也便于后续撤销或更换。
数据库名称、用户名和密码需要准确记录。密码中如果包含特殊字符，填写时要特别注意是否被界面转义或截断。遇到“无法建立数据库连接”时，优先重新核对这几项，而不是立即重装 WordPress。
创建 WordPress 容器
WordPress 容器需要连接到 MariaDB。两者如果位于同一个容器网络中，数据库连接地址通常应填写数据库容器在该网络中的名称或服务名称，而不是 NAS 的公网地址。
这里要区分两个概念：
- 容器之间连接数据库，使用容器网络中的数据库地址和数据库服务端口；
- 浏览器访问 WordPress，使用 NAS 映射出来的 Web 端口。
不要把浏览器访问 WordPress 时使用的端口，误填成 WordPress 连接 MariaDB 时使用的数据库端口。前者解决用户访问，后者解决应用与数据库通信，作用完全不同。
创建 WordPress 容器时，将 NAS 上的程序目录映射到容器内的 Web 根目录。映射完成后启动容器，并通过浏览器访问 NAS 地址和映射端口。如果页面能进入 WordPress 初始安装界面，说明程序文件、Web 服务和端口映射基本正常。
安装界面中填写前面创建的数据库名称、数据库用户名、数据库密码和数据库地址。数据库地址应使用 WordPress 容器能够访问到的 MariaDB 服务名称。只有在两个容器没有使用同一个容器网络时，才需要重新检查网络连接方式。
安装完成后，先登录后台完成一次基本检查：
- 打开站点首页，确认页面可以正常加载；
- 登录后台，确认管理页面没有明显报错；
- 创建一篇测试文章并上传一张图片；
- 检查文章、媒体和固定链接是否能够正常访问；
- 确认容器重启后站点和数据库仍然存在。
这一步很重要。能打开安装页面，只能说明初始连接成功，不能证明目录权限、数据库持久化和媒体上传都没有问题。
PHP 兼容性怎么判断
WordPress 的运行依赖 PHP。不要只看 NAS 上是否安装了 PHP，也不要因为 PHP 版本较新就直接认定一定兼容。部署前应以 WordPress 6.9.3 官方要求为准，确认所使用的 PHP 版本、必要扩展和容器运行环境能够满足要求。
实际排查时，可以按照这个顺序判断：
首先确认 WordPress 容器使用的 PHP 环境，而不是只检查 DSM 中其他套件使用的 PHP。容器内的 PHP 与 Web Station 或其他站点使用的 PHP 可能完全不同。
其次检查 WordPress 后台的站点健康信息和错误提示。如果缺少 PHP 扩展，通常会表现为安装失败、媒体处理异常、后台功能缺失或页面直接报错。
最后不要一次性修改多个运行组件。PHP、MariaDB 和 WordPress 同时变动后，出现问题时很难判断根因。先固定 WordPress 6.9.3 和数据库，再单独调整 PHP 环境，排查会更容易。
是否需要 Redis
Redis 可以用于对象缓存，但不是 WordPress 初次安装的必要条件。我的做法是先让 WordPress、PHP 和 MariaDB 稳定运行，再决定是否引入 Redis。
如果需要使用 Redis，至少要确认三件事：
- Redis 服务本身已经正常运行；
- WordPress 容器能够通过容器网络访问 Redis；
- 所使用的缓存集成方式与当前 PHP 和 WordPress 环境兼容。
Redis 连接地址同样不应随意填写 NAS 的公网地址。容器之间应优先使用同一容器网络中的服务名称。Redis 如果只是为了“看起来完整”而加入，却没有验证连接状态，反而会增加排错复杂度。
启用缓存后，要观察后台和前台是否出现旧内容、登录状态异常或清理缓存无效等问题。遇到这些现象时，可以先停用 Redis 缓存，让站点恢复基础运行，再判断是缓存配置还是 WordPress 本身的问题。
手动更新 WordPress 6.9.3
手动更新前，先做两类备份：一份是 MariaDB 数据库备份，另一份是 WordPress 程序目录和上传媒体目录备份。只备份程序文件而不备份数据库是不完整的，因为文章、页面、设置和部分插件数据都保存在数据库中。
更新时不要直接删除现有程序目录。更稳妥的流程是先停止写入，再保留旧目录作为回退副本，将新的官方文件上传到临时目录，确认文件结构无误后再进行替换。
替换时要特别注意 wp-content 中的内容。媒体文件、主题、插件和部分站点自定义内容通常都依赖这个目录。更新核心文件时，不能因为追求“全量覆盖”而把现有内容一起清掉。
完成文件替换后，重新启动 WordPress 容器并访问后台。如果系统提示需要升级数据库，先确认数据库备份可用，再执行升级。升级完成后检查首页、后台、媒体库、固定链接和登录状态。
更新后的问题不一定立即显示。例如缓存可能继续提供旧页面，权限问题可能要到上传图片时才暴露。因此更新后至少应完成一次前台访问、后台登录和媒体上传测试。
常见问题排查
页面无法访问或端口冲突
先检查 WordPress 容器是否正在运行，再检查 NAS 映射端口是否已经被其他服务占用。浏览器访问的端口必须与容器映射设置一致。
如果容器一直重启，重点查看容器日志。常见方向包括环境变量填写错误、数据库尚未准备好、目录权限不足或容器网络配置不一致。不要只反复点击启动按钮，先看日志通常更快。
WordPress 无法连接数据库
依次核对数据库容器状态、数据库地址、数据库名称、数据库用户名和密码。尤其要确认数据库地址是否误填成了 localhost。在容器环境中，localhost 通常代表当前 WordPress 容器本身，并不一定是 MariaDB 容器。
还要检查两个容器是否位于同一个可通信的容器网络中。如果 MariaDB 容器刚刚创建，数据库初始化可能尚未完成，过早启动 WordPress 也可能导致首次连接失败。
上传图片提示权限不足
先确认 NAS 上的程序目录和媒体目录确实映射到了 WordPress 容器使用的位置，再检查容器运行用户是否拥有读取和写入权限。
如果只有上传失败，而首页和后台都正常，通常应优先检查媒体目录权限和映射路径，而不是重新创建数据库。更新核心后出现同样问题，则还要确认替换文件时没有改变原有目录的权限属性。
修改配置后站点出现空白或报错
一次只修改一项配置，并保留修改前的备份。PHP 环境、缓存服务、数据库连接和目录映射同时变动，会让问题难以定位。
可以先恢复到能够正常运行的配置，再逐项启用 Redis 或调整 PHP。对于个人博客而言，先保证内容可访问和数据可恢复，比一开始就追求复杂的缓存结构更重要。
部署完成后的检查重点
WordPress 6.9.3 在 Synology NAS 上正常运行后，建议把维护重点放在数据安全和变更可追踪上。每次更新前记录当前容器配置、目录映射、数据库连接方式和端口设置；每次更新后完成首页、后台、登录、文章和媒体上传检查。
如果站点暂时只供个人使用，可以先保持结构简单：WordPress、PHP 和 MariaDB 稳定运行，Redis 按需加入。等站点确实出现缓存需求，再单独配置 Redis。这样即使后续发生故障，也能明确判断问题是在程序、数据库、权限、端口还是缓存层，而不会被一套过于复杂的部署结构牵着走。