unlink删除失败常见原因有：权限不足（文件自身无写权限）、文件被占用、路径错误（非绝对路径或Windows反斜杠问题）、符号链接误删、非普通文件误操作、目录未清空、系统限制、环境差异（CLI/Web用户权限或open_basedir）、SELinux拦截及opcache未刷新。
unlink 函数删不掉文件，常见原因有哪些
直接调用 unlink 失败，多数不是函数写错了，而是权限、路径或状态问题。PHP 进程必须对目标文件有写权限（注意：是文件自身的权限，不是父目录），且文件不能被其他进程占用（比如正被 fopen('a+') 打开、被 shell 命令锁定、或在 Windows 下被记事本/IDE 保持句柄）。
-
unlink返回false时，立刻检查error_get_last()，常见错误信息如"Permission denied"或"No such file or directory" - 路径必须是绝对路径，或确保当前工作目录（
getcwd()）符合预期；相对路径容易因 CLI / Web 环境差异失效 - Windows 下注意反斜杠转义：用
\或原始字符串r'C:path ile.txt'（但 PHP 不支持 raw string 语法，所以更推荐str_replace('/', DIRECTORY_SEPARATOR, $path)或直接用正斜杠/—— Windows 也认 - 如果文件是符号链接，
unlink删除的是链接本身，不是目标文件；要删目标得先readlink再unlink
删除前必须做的三件事：检查、确认、清理
别跳过校验直接删。尤其在用户上传、日志归档、缓存清理等场景，误删可能引发数据丢失或服务异常。
- 先用
file_exists和is_file双重判断，避免对目录、socket、设备文件等非普通文件调用unlink（会报 Warning） - 用
is_writable检查可写性，比靠unlink报错再处理更主动 - 敏感操作建议加日志：
error_log("unlink attempted: {$path} (".(file_exists($path)?'exists':'missing').")");
批量删文件时，scandir + unlink 容易出什么问题
遍历目录删文件很常见，但直接 scandir 后 foreach unlink 有隐患：目录结构变化、文件名含特殊字符、递归逻辑缺失。
- 不要用
glob('*')匹配所有文件——它不返回隐藏文件（如.htaccess），也不区分文件/目录；应配合is_file - 文件名含空格、中文、控制字符时，
unlink能正常处理，但拼接路径时若没用realpath或dirname(__FILE__)做基准，容易路径断裂 - 想删整个目录？
unlink不行，得先array_map('unlink', $files)清空，再rmdir；否则报"Directory not empty" - 大目录下频繁调用
unlink可能触发系统级限制（如 inotify 队列满），建议加usleep(1000)间隔，或改用 shell 命令（exec('rm -f ...')）但需严格过滤路径防注入
unlink 在 CLI 和 Web 环境下的行为差异
同一个脚本，在命令行跑成功，放到 Apache/Nginx 就失败，大概率是用户权限或 open_basedir 限制导致的。
立即学习“PHP免费学习笔记（深入）”；
- CLI 模式下 PHP 以当前登录用户身份运行；Web 模式下通常以
www-data、apache或nginx用户运行 —— 文件属主和权限要匹配后者 - 检查
phpinfo()中的open_basedir值，若设了限制，unlink只能操作该路径下的文件，越界直接拒绝，不报具体错误 - SELinux 或 AppArmor 开启时，即使权限 777 也可能被拦截，此时
dmesg | tail可看到拒绝日志 - 某些共享主机禁用
unlink（少见但存在），可用function_exists('unlink')提前兜底
最常被忽略的是：unlink 不触发任何钩子或事件，不会自动更新 opcache 中的文件状态，也不会通知文件监控服务。如果你依赖文件存在性做业务判断，删完最好手动清对应缓存项，或加个 clearstatcache(true, $path)。
