WordPress 权限与角色：文件权限、文章权限与角色分配
WordPress 的权限分两层：一层是文件系统的 755/644，一层是后台的角色与能力。混在一起谈就会出现「明明是管理员却传不了图」这种怪事——那其实是目录不可写，跟角色一个字节的关系都没有。
五个默认角色的能力边界
WordPress 只内置五个角色，能力（capability）一共有几十项，常见的差别集中在这八项：
| 能力 | 订阅者 | 投稿者 | 作者 | 编辑 | 管理员 |
|---|---|---|---|---|---|
| 登录并阅读后台 | 可以 | 可以 | 可以 | 可以 | 可以 |
| 撰写草稿 | 不能 | 可以 | 可以 | 可以 | 可以 |
| 上传媒体文件 | 不能 | 不能 | 可以 | 可以 | 可以 |
| 发布文章 | 不能 | 不能 | 可以 | 可以 | 可以 |
| 编辑他人文章 | 不能 | 不能 | 不能 | 可以 | 可以 |
| 管理分类与标签 | 不能 | 不能 | 不能 | 可以 | 可以 |
| 安装插件与主题 | 不能 | 不能 | 不能 | 不能 | 可以 |
| 管理用户与角色 | 不能 | 不能 | 不能 | 不能 | 可以 |
订阅者除了维护自己的资料几乎什么都做不了，是开放注册时唯一安全的默认角色。投稿者能写不能发，适合外部投稿——稿子进后台待审，编辑看过再发。作者能发自己的但碰不到别人的。编辑是全站内容的管家，却动不了插件和用户，这条边界是刻意设计的：内容权限和技术权限必须分开，否则一个被盗的编辑账号就能装后门插件。
这些能力存在 wp_usermeta 表的 wp_capabilities 字段里，序列化后的数组，形如 a:1:{s:13:”administrator”;b:1;}。改角色本质就是改这一行，所以任何角色调整前都该备份 usermeta，这一点在多人站点上尤其重要。
文件权限：755 / 644，以及 777 的代价
标准配置只有两个数字：目录 755，文件 644。拆开看，755 是所有者可读写执行、同组可读可执行、其他人可读可执行；644 是所有者可读写、其他人只读。
| 路径 | 目录 | 文件 | 说明 |
|---|---|---|---|
| 站点根目录 | 755 | 644 | wp-config.php 建议 600 或 640 |
| wp-content/ | 755 | 644 | 不要 777 |
| wp-content/uploads/ | 755 | 644 | 需要 Web 用户可写 |
| wp-content/plugins/ | 755 | 644 | 装插件时才临时提权 |
777 的意思是任何人都能读、写、执行。在共享主机上，同服务器其他站点的进程也能写你的 PHP 文件，一个站被拿下，整台机器沦陷。上传目录 777 更直接——攻击者传一个 shell 进去就能执行系统命令，这是 WordPress 被黑最常见的入口，善后流程见 被黑修复。
批量修正的命令：
cd /var/www/html
find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;
chown -R www-data:www-data .
chmod 640 wp-config.php属主比数字更重要。文件属主是 root、PHP 却以 www-data 运行，给 755 也写不进去；反过来属主是 www-data 又给了 777，等于把写权限开给所有人。先用 ps aux | grep php-fpm 确认运行用户，再把整站属主改成它，最后才调数字。
还有一类麻烦：宝塔、cPanel 这类面板会自动改权限，手动 chmod 完过一阵又变回去。这时要调面板的默认权限策略，或者关掉它的防跨站锁定，否则改了等于没改。改完用一个简单的探针验证：在 uploads 目录里手动建一个文件，能建成功就说明写权限通了。
上传失败和「无法创建目录」
后台提示「无法创建目录 wp-content/uploads/2026/11」，八成是上传目录不存在或不可写。检查顺序固定为四步：
- ls -ld wp-content/uploads 看属主和权限。
- 看 wp-config.php 里有没有 UPLOADS 常量把上传目录指到了别处。
- 看磁盘是不是满了（df -h），inode 是不是耗尽（df -i）。
- 看 SELinux 是否拦截（getenforce，临时 setenforce 0 验证）。
如果后台一直提示输入 FTP 账号，说明 WordPress 判断文件系统不可直接写。在 wp-config.php 里加一行可解：
define( 'FS_METHOD', 'direct' );
define( 'DISALLOW_FILE_EDIT', true );DISALLOW_FILE_EDIT 会关掉后台的插件和主题在线编辑器，是性价比极高的一条加固：即使管理员账号被盗，攻击者也没法直接在后台改 PHP 文件。这是文件权限之外的第二道锁，配上之后 755 的意义才完整。安全插件里同类开关很多，别重复设，设重了容易互相覆盖，参考 安全插件 的配置建议。
文章权限：私有、密码保护与可见范围
单篇文章的可见性在编辑页右侧的「公开」框里改，四种状态的实际效果差别不小：
| 状态 | 谁能看 | 出现在列表页 | 适合 |
|---|---|---|---|
| 公开 | 所有人 | 是 | 正常内容 |
| 密码保护 | 知道密码的人 | 是，标题和摘要可见 | 给客户预览 |
| 私有 | 作者本人与管理员 | 否 | 内部草稿 |
| 定时 | 到点后所有人 | 到时出现 | 预热内容 |
密码保护的文章，标题和摘要仍然出现在列表页和 RSS 里，只有正文被锁住。要连标题都藏起来只能设成私有，私有文章不进任何归档页，也不进 sitemap，这一点常被用来做客户预览。
如果需要「某个角色才能看某类内容」，WordPress 没有内置开关，只能靠插件（Members、User Role Editor）或自己写判断。用短代码包一层是最轻的做法：
add_shortcode( 'vip', function( $atts, $content = '' ) {
if ( ! is_user_logged_in() || ! current_user_can( 'read' ) ) {
return '<p>该内容仅限登录用户查看。</p>';
}
return $content;
} );但这只能挡模板输出，挡不住直接查数据库，也挡不住 REST API 和 feed。真要保护内容，得在 rest_prepare_post、the_content_feed 上一起过滤，工作量不小。所以别拿它做付费墙，商业内容还是用专门插件。
多作者站点的角色分配
一个正常运转的编辑部大概是这个结构：
- 1 个管理员：只给站长或技术负责人，日常不用它写文章。
- 1 到 2 个编辑：审稿、排期、管分类。
- 若干作者：签约写手，只能发自己的稿子。
- 外部投稿：给投稿者，或者干脆用表单收集，不进后台。
核心原则是最小权限：日常写作用作者账号，需要动插件时才切管理员。管理员被盗的损失是整站，作者被盗最多是几篇垃圾文章。同一道理，给客户开后台时永远不要给管理员，给编辑就够，交付时留一个管理员账号自己保管。
角色调整后要验证，不能凭印象。用 WP-CLI 查和改：
wp user list --fields=ID,user_login,roles
wp user add-role 12 editor
wp user remove-role 12 author
wp cap list editorwp cap list 会把该角色拥有的全部能力列出来，比自己猜准得多。想临时给某个人加一项能力用 wp user add-cap，比改角色精细，但一定要留记录，否则半年后没人知道谁为什么能删文章。反过来，怀疑某个账号权限过大时，wp user list-caps 12 能直接列出这个人实际拥有的能力，比重读角色定义快。
最后两条纪律：改角色、改权限之前先备份数据库，至少导出 wp_usermeta 和 wp_options 两张表，角色配错会导致所有人进不去后台，恢复成本很高，备份方法见 备份与恢复；文件权限和角色清单每季度过一遍，写进运维检查表，这一条通常挂在 安全加固 的清单里。
这两个层面的权限还有个隐含关系：文件权限决定了「谁能改代码」，角色决定了「谁能在后台干什么」。后台角色再严，文件权限是 777，等于前门锁着后门大开。所以排查权限问题时，永远先看文件系统，再看后台角色，顺序别倒过来。日常操作入口不熟的，可以在 后台入门 里把用户管理和媒体库的位置过一遍。