file_put_contents() 返回 false 的根本原因是权限、路径、配置等底层问题未被显式暴露；应依次验证目录存在性、可写性、系统错误、open_basedir 限制及 SELinux 等隐藏约束。
file_put_contents() 返回 false 怎么快速定位
它不报错、不抛异常，只默默返回 false——这是最让人抓狂的假“静默失败”。别猜路径对不对、权限够不够，直接用代码验证：
- 先确认目录存在：
is_dir('/path/to/dir')必须为true - 再测是否真能写：
is_writable('/path/to/dir')在 Linux 上基本可靠，但 Windows 下容易误判；更稳妥的是手动试写删：$test = '/path/to/dir/.write_test';<br>if (file_put_contents($test, 'x') !== false && unlink($test)) { /* 可写 */ } - 紧跟失败操作后立刻调用：
error_get_last()，它能捞出底层系统级错误（比如Permission denied或No such file or directory）
mkdir() 创建多级目录失败？大概率漏了递归参数
mkdir('/a/b/c', 0755) 默认只建最后一级 c，如果 /a/b 不存在，就直接返回 false。这不是 bug，是设计如此。
- 必须显式开启递归：
mkdir('/a/b/c', 0755, true)—— 第三个参数true缺一不可 - 注意权限掩码：
0755是八进制，写成755会被当十进制处理，等效于01143，结果不可控 - 创建后建议补一句
chmod()或确保父目录已有执行（x）位，否则 PHP 连进入目录都做不到
Web 和 CLI 权限完全不是一回事
你在终端用 php script.php 成功创建了文件，不等于网页访问时也能成功——因为 PHP 在 Web 环境下是以 www-data（Ubuntu/Debian）、apache（CentOS/RHEL）或 nginx 用户身份运行的，和你当前 shell 用户毫无关系。
- 查 Web 用户：
ps aux | grep -E '(apache|httpd|nginx|php-fpm)'，看 USER 列 - 查目标目录权限：
ls -ld /var/www/html/uploads，确认属主（owner）是 Web 用户，且有写（w）和执行（x）权限 - 安全做法不是
chmod 777，而是：sudo chown -R www-data:www-data /var/www/html/uploads+sudo chmod -R 755 /var/www/html/uploads
open_basedir 限制：看不见的墙
哪怕路径存在、权限正确、用户匹配，file_put_contents() 仍返回 false？十有八九是 open_basedir 在拦截。它像一道白名单防火墙，超出范围的操作不会报错，只会静默失败。
立即学习“PHP免费学习笔记（深入）”；
- 检查是否启用：
echo ini_get('open_basedir');，返回非空字符串即生效 - 典型错误日志里藏线索：
file_put_contents(): open_basedir restriction in effect（需确保log_errors = On） - 临时调试可加白名单：
open_basedir = "/var/www/html:/tmp"，重启 Web 服务生效；生产环境务必最小化授权
真正难排查的，往往不是权限数字没设对，而是某一级父目录缺 x 位、SELinux 的 httpd_write_content 被禁用、或路径里混了 Windows 风格反斜杠导致 is_dir() 判定失败——这些细节不打日志、不报错，只让 false 沉默发生。
