is_writable() 是判断文件或目录是否可写的最直接方法，它依据运行 PHP 的用户权限检查，在 Windows 下看只读属性，Linux/macOS 下检测真实文件系统权限，但路径不存在时返回 false，且在 NFS、SELinux 等环境可能误判。
用 is_writable() 判断文件或目录是否可写
PHP 提供了内置函数 is_writable()，这是最直接、最推荐的方式。它会检查当前运行 PHP 的用户（如 www-data、apache 或 nginx）是否有权限向目标路径写入内容。
注意：该函数在 Windows 下行为略有不同——它不依赖 Unix 权限位，而是检查文件是否为只读属性；在 Linux/macOS 下则真实检测文件系统权限（包括用户、组、其他三类权限位，以及 sticky bit、ACL 等影响）。
-
is_writable()对目录返回true，仅表示「可在该目录下创建/删除文件」，不保证能写入已有文件 - 对普通文件返回
true，表示「当前用户可打开该文件进行写操作（fopen($file, 'w')不报错）」 - 如果路径不存在，
is_writable()直接返回false（不会尝试向上追溯父目录） - 某些共享主机或启用了
open_basedir时，即使权限足够，也可能因 PHP 配置限制而返回false
为什么 is_writable() 有时返回 false，但实际能写？
常见于 NFS、容器挂载卷、SELinux 启用环境，或 PHP 运行用户与文件属主不一致但组权限生效的场景。此时 is_writable() 可能因内核或 libc 权限检查逻辑保守而误判。
更稳妥的做法是「试写 + 清理」：
立即学习“PHP免费学习笔记（深入）”；
$test_file = $path . '/.write_test_' . uniqid();
if (file_put_contents($test_file, 'test') !== false) {
unlink($test_file);
// 可写
} else {
// 不可写
}
这个方法绕过了权限位解析逻辑，直击本质——但要注意：
• 不要在高并发目录中频繁使用，避免竞态
• 确保 $path 是绝对路径，且已存在
• 若 unlink() 失败（如被其他进程占用），需额外处理残留文件
检查文件权限数字（0644、0755）不如看属主和运行用户
很多人用 decoct(fileperms($file) & 0777) 查看八进制权限，再手动比对，这容易出错。真正起作用的是：「当前 PHP 进程的 UID/GID 是否匹配文件的 owner/group/others 权限段」。
- 用
posix_getuid()和posix_getgid()查 PHP 当前用户身份 - 用
fileowner($file)和filegroup($file)查文件归属 - 再结合
fileperms($file)中对应段的 w 位是否开启 - 若启用了 ACL（如
setfacl设置），is_writable()通常仍能正确反映结果，但fileperms()不显示 ACL 细节
Web 服务重启后权限失效？重点查用户切换和 umask
常见于用 systemd 启动 PHP-FPM 或 Apache 时，服务配置里指定了 User= 和 Group=，但未同步修改 umask。导致新创建的文件权限为 0600（而非预期的 0644），后续脚本就无法写入。
验证方式：
// 在 Web 请求中执行 echo decoct(umask()); // 通常应为 0002 或 0022
修复建议：
• 在 PHP-FPM pool 配置中加 php_admin_value[umask] = 0002
• 或在 Apache 的 envvars 中设置 export UMASK=0002
• 容器环境中，确保启动命令里显式设置了 umask 0002
权限判断本身不难，难的是在复杂部署中确认「谁在跑、以谁的身份跑、文件归谁、中间有没有代理或挂载层干扰」——这些才是线上踩坑最多的地方。
