直接用unlink()删除文件需检查返回值,否则会静默失败;必须校验路径合法性、文件存在性、可写权限及是否为目录,防范路径遍历与权限问题。

直接用 unlink() 就能删文件,但删不掉会静默失败
unlink() 是 PHP 删除文件最基础的函数,但它不会报错——哪怕文件不存在、权限不够、路径写错,都只返回 false,不抛异常。很多人卡在这一步,以为“没反应=删除成功”,结果文件还在。
- 必须手动检查返回值:
if (unlink($path) === false) { /* 处理失败 */ } - 路径必须是**绝对路径**或相对于当前工作目录(
getcwd())的路径,相对路径容易因 CLI/web 环境不同而失效 - PHP 进程需要对目标文件有
write权限(Linux/macOS)或“修改”权限(Windows),仅靠文件所有者权限不够,还得看父目录是否可写(尤其 NTFS 下) - 不能删除非空目录,误传目录路径会直接失败,且
is_dir($path)应该在unlink()前校验
删之前务必校验路径合法性,否则可能删错系统文件
用户传来的文件名(比如通过 $_GET['file'])如果没过滤,攻击者可以构造 ../../etc/passwd 这类路径遍历参数,导致任意文件被删。这不是理论风险,是真实可利用的漏洞。
- 用
basename()提取文件名,丢弃路径部分:$filename = basename($_GET['file']); - 限定允许的目录范围,用
realpath()+str_starts_with()做白名单校验:$full_path = realpath("/var/www/uploads/{$filename}"); if ($full_path === false || !str_starts_with($full_path, "/var/www/uploads/")) { die("非法路径"); } - 避免用
file_exists()单独判断——它和unlink()之间存在竞态窗口(文件可能被其他进程删掉或替换),应以unlink()返回值为准
遇到“Permission denied”错误,重点查三个地方
Linux 下常见错误信息是 Warning: unlink(...): Permission denied,不是代码写错了,而是权限链没打通。
- 确认文件本身权限:运行
ls -l /path/to/file,看属主是否为 PHP 进程用户(如www-data或nginx) - 更关键的是父目录权限:PHP 必须对**父目录有执行(x)权限**才能进入并操作其下文件;若父目录权限是
755但属主不是 PHP 用户,且组权限不含w,unlink()仍会失败 - SELinux 或 AppArmor 启用时,即使文件权限正确,策略也可能拦截删除操作,可用
ausearch -m avc -ts recent查日志
批量删文件时别用循环 unlink(),大目录会卡死
要删一个含上千个小文件的临时目录,逐个调用 unlink() 效率极低,还可能超时。这时候应该换思路。
- 用
array_map('unlink', glob("/tmp/temp_*.log"));批量匹配+删除,比 foreach 快不少 - 真正的大目录(如日志归档),优先考虑
exec("rm -rf {$escaped_dir}", $output, $return_code),但必须严格转义目录变量(用escapeshellarg()),且确保服务器允许exec - 注意
glob()不支持递归,要删子目录需配合RecursiveDirectoryIterator,但要注意跳过.和..目录项,否则可能无限循环
实际删文件最难的从来不是调哪个函数,而是搞清“为什么明明路径对、权限看着也够,还是删不掉”——往往卡在工作目录、父目录权限、SELinux 策略这些看不见的地方。
php免费学习视频:立即使用
踏上前端学习之旅,开启通往精通之路!从前端基础到项目实战,循序渐进,一步一个脚印,迈向巅峰!











