php无内置自动清理冗余文件功能，需开发者主动触发；冗余文件包括session、临时上传、框架缓存、旧日志等；推荐用cron+find定时清理，注意权限、路径和安全校验。
PHP 本身不提供自动清理环境冗余文件的能力，所有清理动作必须由开发者主动触发、明确指定路径和规则——没有内置的 php_clean_temp() 或类似函数。
哪些文件算“冗余”？先定义清楚再删
所谓“冗余”，在 PHP 运行环境中通常指：
-
session文件（存于session.save_path，如/var/lib/php/sessions） - 临时上传文件（
upload_tmp_dir下未被 move_uploaded_file() 处理的残留） - 框架/应用自建缓存（如 Laravel 的
storage/framework/cache、Symfony 的var/cache） - 日志轮转后遗留的旧压缩包（
app.log.2024-01-01.gz等） - Composer 的
vendor/composer/autoload_*.php（仅在 dev 环境下可能冗余，生产不应存在）
⚠️ 切勿无差别删除 vendor/、composer.lock、.env 或任何非临时目录下的文件——它们不是冗余，是运行依赖。
用 shell 脚本定时清理最稳妥
PHP 脚本不适合长期运行或可靠调度，清理任务应交给系统级工具。推荐用 cron + find 组合：
立即学习“PHP免费学习笔记（深入）”；
#!/bin/bash # 清理 session（保留 24 小时内修改的） find /var/lib/php/sessions -name "sess_*" -mmin +1440 -delete <h1>清理 upload_tmp_dir（假设是 /tmp/php-uploads）</h1><p>find /tmp/php-uploads -type f -mmin +60 -delete</p><h1>清理 Laravel 缓存（只删过期的 .php 文件，不碰 .gitkeep）</h1><p>find storage/framework/cache -name "*.php" -mmin +30 -delete
注意点：
-
-mmin +1440表示“最后修改时间超过 1440 分钟（24 小时）”，比-mtime +1更精确（避免跨天边界问题） - 务必先用
-print替代-delete测试匹配结果，确认无误再执行真实删除 - 如果
session.save_path是用户私有目录（如/home/www/sessions），确保cron运行用户有读写权限
PHP 中调用 unlink() 要严格限定范围
仅在业务逻辑中做精准清理，比如上传后清理原始临时文件：
$tmpFile = $_FILES['avatar']['tmp_name'];
$target = '/var/www/uploads/' . uniqid() . '.jpg';
<p>if (move_uploaded_file($tmpFile, $target)) {
// ✅ 安全：$tmpFile 是 PHP 上传机制生成的，且 move_uploaded_file 成功后它已失效
@unlink($tmpFile); // 加 @ 避免 warning，但实际 move 后 unlink 总是成功
} else {
// ❌ 危险：不要在这里 unlink($_FILES['avatar']['tmp_name']) —— 可能已被 move 或不存在
}常见错误：
- 对
glob('cache/*.php')结果不做is_file()检查就unlink()，可能误删子目录 - 用
array_map('unlink', glob('logs/*.log.*'))，但没过滤掉logs/.gitkeep或符号链接 - 在 CLI 脚本中清理 session 时，用
session_start()后直接session_destroy()，这只会清 session 数据，不会删磁盘文件
真正容易被忽略的是权限与上下文隔离：web server 用户（如 www-data）能删的文件，CLI 用户（如 ubuntu）不一定能删，反之亦然。清理脚本的执行身份必须和文件属主一致，否则 Permission denied 不会报错，而是静默跳过——你以为删了，其实什么都没发生。
