根本原因是目录缺少x权限、PHP进程用户与目录属主不匹配，或open_basedir限制；需检查并设置目录属主、u+rwX权限及open_basedir配置。
PHP 读写 JSON 文件权限不足，不是改 chmod 就能解决的——90% 的人卡在目录的 x 权限和 PHP 进程用户不匹配上。
为什么 chmod 644/755 常常没用
给 todo.json 执行 chmod 644 todo.json 或给目录执行 chmod 755 uploads/ 后仍报 Permission denied，根本原因不是文件本身，而是：
– 目录缺少 x（执行）位 → PHP 用户无法“进入”该目录，哪怕文件权限再高也打不开
– www-data（或 nginx、apache）根本不是该目录的属主或同组用户
– open_basedir 限制了路径范围，错误信息完全一样，但 chmod 完全无效
验证方式：在 PHP 脚本里加这行：echo ini_get('open_basedir'); —— 如果输出非空，先清空或扩容该配置，否则所有 chmod 都白做。
真正要改的不是文件，是目录属主和最小权限组合
JSON 文件通常由 PHP 动态生成或更新（如保存表单、缓存状态），关键操作对象是它所在的目录。安全且有效的做法是：
- 确认 PHP 进程用户：
ps aux | grep php-fpm或在脚本中运行echo posix_getpwuid(posix_geteuid())['name']; - 把整个 JSON 存放目录（如
/var/www/myapp/data/）属主设为该用户：sudo chown -R www-data:www-data /var/www/myapp/data - 设权限时用
u+rwX（注意大写 X）而非755：sudo chmod -R u+rwX,g+rwX,o-rwx /var/www/myapp/data
→X只对目录或已有执行位的文件加x，避免可执行脚本被误开权限 - 如果开发用户也要直接编辑（如
dev用户），别改属主，改用 ACL：sudo setfacl -R -m u:www-data:rwx /var/www/myapp/datasudo setfacl -R -d -m u:www-data:rwx /var/www/myapp/data
PHP 层必须配合检查，不能只信 is_writable()
is_writable() 在 NFS、Docker 卷、某些 SELinux 环境下会返回 true 但实际写入失败。更可靠的方式是“试操作 + 错误捕获”：
if (file_put_contents($jsonPath, json_encode($data, JSON_UNESCAPED_UNICODE)) === false) {
$err = error_get_last();
if ($err && str_contains($err['message'], 'Permission denied')) {
error_log("JSON write failed: {$jsonPath} – " . $err['message']);
http_response_code(500);
exit('保存失败，请联系管理员');
}
}
注意：
– 不要用 try/catch 捕获，权限错误触发的是 E_WARNING，不是异常
– 写入前建议用原子写法（先写 .tmp，再 rename()），避免 JSON 文件被截断损坏
– file_exists() 返回 true ≠ 可写，它连权限都不检查
容器或共享主机环境的特殊处理
Docker 中常见问题：镜像默认以 root 启动 PHP，但挂载的宿主机目录属主是普通用户。这时：
– 启动容器时指定用户：docker run -u www-data ...
– 或构建镜像时提前 chown -R www-data:www-data /app/data
– Alpine 镜像若要用 setfacl，得先 apk add acl
共享主机（cPanel、Plesk）通常禁用 chown 和 setfacl，只能靠 chmod 和组权限：
– 把目录属组设为 Web 组（如 chgrp www-data data/）
– 再 chmod -R g+rwX data/
– 确保你的 FTP/SFTP 用户也在该组里
事情说清了就结束。最常漏的是父目录的 x 权限、open_basedir 静默拦截、以及容器里用户 UID 不一致——这三处不查，光改 chmod 永远修不好。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
