WordPress更新为何要求FTP凭据?

后台点下更新，页面却弹出要填 FTP 用户名和密码——很多人第一反应是 WordPress 又在刁难人，明明已经在服务器上开了 SSH。实际上，这个弹窗是 WordPress 文件权限自检失败后的一次“优雅降级”，它挡住更新恰恰说明机制在工作。

它问的不是密码，是身份

WordPress 更新文件时并不直接写盘，而是先做一次身份核对：当前执行 PHP 的进程用户，是否就是目标文件的属主。内核层面用 getmyuid() 拿到进程自身所属用户，再与待更新文件的属主比对，一致才走直连写入；不一致，它无法保证写入后文件归属不被打乱，于是退回 FTP 凭据模式，让用户显式提供一组有权限的账号代为写入。

所以弹窗的真实含义是：Web 服务进程（如 www-data）与站点文件属主（可能是一个独立的运维账号）不是同一个用户。

为什么不能干脆全站放开写权限

把整站 chmod 777 确实能让弹窗立刻消失，代价是把安全边界一并拆掉。标准 linux 隔离模型下，PHP 进程用户若拥有整站文件所有权，任何一次非预期的代码执行都会升级为全站沦陷：核心脚本、主题、插件、配置文件都能被改写。规范做法是把属主交给受控的运维账号，Web 进程只以组身份在必要路径上持有写能力——wp-content/uploads/ 供媒体上传，而 wp-config.php 始终只读。

排查从三处入手

先确认 PHP-FPM 或 Web 服务实际以哪个用户运行，再在站点根目录查看核心文件与 wp-content 各子目录的属主分布。若大量文件归属 root 或出现混乱的 UID，基本可以断定比对会失败。第三处常被忽略：系统临时目录。即使属主正确，若 /tmp 与站点不在同一分区或用户不兼容，WordPress 仍会判定临时文件不属于自己。此时可在配置中指定站点内的临时目录，并让它归属运维账号、Web 用户组可写。

然后做取舍

生产环境的严格模式是：文件归运维账号、目录 755、文件 644，仅上传目录组可写，升级通过命令行工具以属主身份执行，或安排维护窗口临时放权。如果确实依赖后台一键更新，那就得让 Web 用户组对插件与主题目录具备写权限，本质上是把便利性换成了更大的攻击面。

弹窗本身并不可怕，它只是把一条本该由人决定的边界摆到了台面上：谁拥有这些文件，谁就有权改写它们。