is_writable返回true仅表示PHP进程有权限写入，不保证实际可写；它在文件不存在时必返回false，结果受SELinux、缓存、umask等影响，需结合fopen等实测验证。
is_writable 不能只靠返回 true 就认定“能写”，它只检查当前 PHP 进程是否有权限写入——而这个“当前进程”通常是以 web server 用户（比如 nobody、www-data 或 apache）身份运行的，和你的登录用户完全无关。
为什么 is_writable 返回 false，但手动 chmod 777 后还是 false？
常见于 SELinux 启用的 Linux 系统（如 CentOS/RHEL）。即使文件权限是 666 或目录是 777，SELinux 策略仍可能禁止 httpd 进程写入。错误现象是：is_writable 返回 false，fopen(..., 'w') 报 Permission denied，但 ls -l 看权限完全正常。
- 临时验证：执行
setenforce 0（不推荐生产环境）后重试，若变true，基本可确认是 SELinux 问题 - 长期解决：用
chcon -t httpd_sys_rw_content_t /path/to/dir赋予 web 进程写上下文，或用semanage fcontext持久化规则 - 别依赖
chmod修复：在 SELinux 环境下，chmod不影响策略判定，is_writable仍会返回false
检查不存在的文件时，is_writable 总是返回 false
这是设计行为，不是 bug。is_writable('nonexistent.txt') 必然返回 false，哪怕其父目录可写——因为它只判断“该路径已存在且可写”，不预测“能否在该位置创建新文件”。安装程序或配置生成逻辑中容易踩这个坑。
- 正确做法：先用
is_writable(dirname($path))检查父目录是否可写 - 补充验证：尝试
fopen($path, 'c')（c模式只创建不截断，失败时fopen返回false，且不会改变已有内容） - 注意：不要用
file_exists+is_writable组合来代替父目录检查，因为两者缓存不同步，clearstatcache(true, $path)也不能保证跨路径一致性
缓存导致判断结果“过期”
is_writable 的结果会被 PHP stat 缓存，连续调用时可能返回上次的旧值。尤其在部署脚本或安装向导中，修改权限后立刻调用，大概率拿到错误结果。
立即学习“PHP免费学习笔记（深入）”；
- 必须在权限变更后调用
clearstatcache(true, $filename)，其中第一个参数true表示清空所有缓存，第二个参数指定具体路径更安全 - 避免只调用
clearstatcache()（无参），它只清文件名缓存，不保证清目录项或 inode 层级状态 - Windows 下缓存行为更隐蔽：NTFS 权限变更有时需等几秒才被内核通知到 PHP，此时加
usleep(100000)比盲目重试更可控
真正可靠的可写性判断，从来不是单靠 is_writable 一个函数——它只是第一道过滤，后面总得跟一次实际的 fopen 或 file_put_contents 尝试，并捕获警告或返回值。否则，你永远不知道 umask、挂载选项（如 noexec、nosuid）、NFS 锁或容器卷绑定是否悄悄拦住了写操作。
