unlink删除失败主因是权限、路径或状态问题：需用绝对路径，确认file_exists且is_file为true，web用户须有写权限，windows注意反斜杠，生产环境应先realpath核对、加白名单校验并记录日志。
PHP unlink 删除文件失败的常见原因
直接调用 unlink 却提示“Permission denied”或“No such file or directory”，大概率不是函数写错了，而是权限、路径或状态问题。unlink 不会自动帮你检查文件是否存在、是否可写、是否是目录——它只做一件事：删掉那个路径指向的普通文件。
- 确保路径是**绝对路径**，或确认当前工作目录（
getcwd()）和你预期的一致；相对路径容易在 CLI 和 Web 环境中表现不一致 - 检查文件是否真实存在：
file_exists($path)和is_file($path)必须同时为true；is_dir($path)为true时调用unlink必然失败 - Web 服务器用户（如
www-data或_www）必须对文件有写权限，而不仅仅是读权限；Linux 下chmod 644的文件，若属主不是 Web 用户，unlink仍会拒绝 - Windows 下注意反斜杠转义问题，建议统一用正斜杠或
dirname(__FILE__) . '/file.txt'
安全删除前必须做的三件事
生产环境里，unlink 是不可逆操作。删错路径可能直接导致服务异常，比如误删配置文件或上传目录下的关键资源。
- 先用
realpath($path)解析出真实路径，打印出来人工核对一次，尤其当路径含../或变量拼接时 - 加一层白名单校验：只允许删除指定目录下的文件，例如
if (0 !== strpos($path, '/var/www/uploads/')) { die('Access denied'); } - 记录日志：哪怕只是
error_log("unlink: $path by user {$uid}")，事后排查能省半天
unlink 和 rm -f 的行为差异
别把 PHP 的 unlink 当成 shell 的 rm -f ——它不会静默忽略不存在的文件，也不会递归删目录。这是最常被误解的一点。
-
unlink('/nonexistent.txt')直接触发Warning: unlink(): No such file or directory，不是返回false就完事；要避免警告，得先if (file_exists($path)) { unlink($path); } - 想删目录？
unlink不行，得用rmdir($path)（仅限空目录），或手动遍历 +unlink+rmdir组合 - 大文件删除不卡 PHP 进程，但若文件正被其他进程打开（如日志被 tail -f），Linux 下虽能删成功（inode 被标记删除），磁盘空间实际不会立刻释放，直到所有句柄关闭
替代方案：什么时候不该硬上 unlink
如果业务需要“软删除”、回收站机制、或依赖文件元信息（谁删的、何时删的），硬删就埋了坑。
立即学习“PHP免费学习笔记（深入）”；
- 改名比删除更安全：
rename($path, $path . '.deleted.' . time())，保留原始内容和权限，后续批量清理也可控 - 数据库有对应记录的，务必先更新状态字段（如
is_deleted = 1），再删文件；否则异步任务或定时脚本可能重复处理已删文件 - 云存储（如 OSS、S3）场景下，PHP SDK 的删除方法（如
$ossClient->deleteObject()）才是正解，本地unlink对远程文件完全无效
unlink 就可能从工具变成事故引信。 
