unlink() 报 Permission denied 的真正主因是父目录缺少写权限，而非文件自身权限；Linux 删除文件本质是修改目录inode表项，需PHP进程用户对父目录有w权限。
unlink() 报 Permission denied 的真正原因不是文件权限
绝大多数人第一反应是 chmod 777 文件本身，但实际失败主因几乎总是父目录缺写权限（w 位）。Linux 下删除文件本质是修改目录的 inode 表项，不依赖文件自身的 w 权限。哪怕文件是 -rwxrwxrwx，只要它所在的目录对 PHP 进程用户不可写，unlink() 就会直接报 Permission denied。
-
is_writable('file.txt')返回true≠unlink()能成功——它只检查文件可写，不校验目录权限 - 用
ls -ld /path/to/dir查父目录权限，重点看第三列（属主）、第四列（属组）和权限字段（如drwxr-xr-x）中对应位置是否有w - PHP 进程用户必须是目录属主，或属于目录属组且组位含
w，或其他用户位含w（不推荐）
怎么确认 PHP 进程用户是谁
别猜，也别信配置文件里写的默认值——运行时用户可能被改过。最可靠的方式是让脚本自己报出来：
- 新建一个临时文件（如
whoami.php），内容为<?php echo exec('whoami'); ?>，通过浏览器访问，输出就是真实执行用户（如www-data） - 若
exec()被禁用，改用<?php echo get_current_user(); ?>，再结合ps aux | grep -E '(apache|httpd|nginx|php-fpm)'看进程 USER 列 - 在容器或共享主机环境，
get_current_user()可能返回root或nobody，此时必须以ps输出为准
父目录权限修复的三个安全操作顺序
目标：让 PHP 用户能删文件，又不暴露过大权限。按以下顺序执行，跳过任意一步都可能白忙：
- 先查目录当前属主/属组：
ls -ld /var/www/html/uploads，确认是否匹配 PHP 用户（如www-data） - 若属主不匹配但属组可用：执行
chgrp www-data /var/www/html/uploads+chmod g+ws /var/www/html/uploads（s保证新文件继承组） - 若属主就是 PHP 用户：直接
chmod u+w /var/www/html/uploads；避免用chmod 777，它开放其他用户写权，有风险 - Windows 下还要额外检查：文件是否被标记为“只读”属性，或被其他进程（如日志收集器、IDE）独占打开
open_basedir 和文件句柄未关闭也会伪装成权限错误
这两类问题现象和 Permission denied 完全一致，但跟 Linux 权限无关，排查优先级仅次于父目录权限：
立即学习“PHP免费学习笔记（深入）”；
- 运行
echo ini_get('open_basedir');，如果返回非空字符串（如/var/www/html:/tmp），而你要删的路径不在其中，unlink()就会静默失败 - 检查代码中是否漏掉
fclose($fp)或fflush()—— 文件被fopen()打开后未关闭，在 Windows 和部分 Linux 文件系统下会锁死删除 - SELinux 启用时（常见于 CentOS/RHEL），即使所有传统权限都对，
ls -Z显示上下文类型不对（如unconfined_u:object_r:user_home_t:s0）也会拦截，需chcon -t httpd_sys_rw_content_t /path/to/dir
父目录写权限是硬门槛，但 open_basedir 和文件锁是「看起来修好了却还是删不掉」的高发点。别在 chmod 上反复试错，先跑一遍 ls -ld + ini_get('open_basedir') + lsof | grep your_file，三步下来，90% 的 unlink 失败就定位清楚了。
