大多数 WordPress 站点将目录权限设为 755、文件权限设为 644 即可满足日常安全需求，关键是要确保文件所有者属于 Web 服务用户，而不是 root。

命令速用版

如果你能通过 SSH 登录服务器，可以在 WordPress 根目录下执行以下命令快速重置权限。注意将 www-data 替换为你实际的 Web 用户。

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chown -R www-data:www-data .

对于 wp-config.php，建议单独设置为 440 或 444，防止被 Web 脚本意外写入：

chmod 440 wp-config.php

为什么会这样

Linux 权限分为读（r）、写（w）、执行（x）。数字 755 表示所有者拥有全部权限，组用户和其他用户只能读取和执行（进入目录）。644 表示所有者可读写，其他人只读。WordPress 需要写入上传目录和缓存文件，所以不能完全只读；但为了防止恶意脚本修改核心文件，普通文件不应赋予写权限。

公开资料中没有看到可靠的量化数据表明特定权限组合能降低多少百分比的安全风险，但遵循最小权限原则是行业共识。

分步处理

1. 备份站点：在修改权限前，务必对文件和数据库进行备份，防止误操作导致站点不可用。
2. 确认 Web 用户：执行 ps aux | grep nginx 或 ps aux | grep apache 查看进程运行用户，常见为 www-data、nginx 或 apache。
3. 修正所有者：权限数字正确但所有者错误依然会导致问题。执行 chown -R 用户：用户 路径。
4. 批量设置权限：使用上述 find 命令区分目录和文件设置。
5. 保护配置文件：将 wp-config.php 设为只读，防止被注入。

怎么验证是否生效

修改完成后，不要立即离开，按以下顺序检查：

• 尝试在媒体库上传一张图片，确认 uploads 目录可写。
• 尝试更新一个插件或主题，确认核心目录可写。
• 查看服务器错误日志（如 /var/log/nginx/error.log），确认没有 Permission denied 报错。
• 前台页面正常访问，无 500 错误。

常见坑

• 全设 777：有些教程建议将所有文件设为 777 来解决权限问题，这会带来极大安全风险，任何用户上传脚本都能执行。
• 所有者为 root：如果文件所有者是 root，而 Web 服务是 www-data，WordPress 将无法写入任何文件，导致更新失败。
• 忽略 SELinux：在 CentOS 等开启 SELinux 的系统上，即使 chmod 正确，也可能因安全上下文被拦截，需检查 SELinux 状态。
• 缓存插件冲突：权限修改后，某些缓存插件可能因无法写入缓存文件而报错，需清理缓存重试。

参考来源

• WordPress 官方文档，Hardening WordPress，https://wordpress.org/support/article/hardening-wordpress/
• Kinsta 知识库，WordPress File Permissions，https://kinsta.com/knowledgebase/wordpress-file-permissions/