time() 返回 Unix 时间戳，是备份清理逻辑的可靠基础；应统一用 time() 与 filemtime() 计算天数差，避免字符串比较和时区混用，命名用 date() 保证可读性，清理严格依赖文件真实修改时间。
time() 返回值直接影响备份文件清理逻辑
PHP 的 time() 函数返回当前 Unix 时间戳（秒级整数），它是计算“哪些备份该删”最直接、最可靠的基础。别用 date("Y-m-d") 字符串去比对，字符串比较易出错，也难处理跨月/跨年边界；时间戳做减法再除以 86400（一天的秒数），就能精确算出天数差。
常见错误现象：脚本里写 if (filemtime($f) 看似简洁，但 <code>strtotime() 在时区不明确或服务器时间异常时可能返回 false，导致条件恒真或恒假，误删或漏删。
- 始终用
time() - filemtime($f) > 7 * 86400判断是否超期 - 确保所有时间相关操作统一使用 UTC 或系统本地时区，避免混用
date_default_timezone_set()和未设时区的strtotime() - 注意
filemtime()返回的是文件修改时间——对备份脚本来说，这恰好就是生成时间，可直接用
保留 N 天备份的 PHP 实现要点
保留最近 7 天的 SQL 备份文件，不是简单地取文件名里的日期解析，而是基于文件元数据做真实时间判断。这样即使手动复制旧文件进去，也不会被误留；即使脚本某次执行延迟，也不会多留一天。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 遍历备份目录下所有
*.sql文件，用filemtime()获取其最后修改时间 - 用
time() - $mtime > $keep_seconds做硬性判断，$keep_seconds = 7 * 86400 - 删除前先
unlink()，失败时记录日志并跳过，不要中断整个清理流程 - 避免在备份主流程中同步清理——建议单独拆成
cleanup.php，由 crontab 在备份后 5 分钟调用，解耦更稳
mysqldump + time() 组合下的命名与清理一致性
文件名带时间戳（如 medical_2026-05-21_23-45-12.sql）方便人工识别，但不能依赖它做自动清理。因为文件名可伪造、可重命名，而 filemtime() 是内核维护的真实时间，不可篡改（除非 root 权限 touch）。
所以正确做法是：命名仍用 date("Y-m-d_H-i-s") 保证可读性，清理则严格走 filemtime() + time() 计算。两者目的不同，不该混为一谈。
- 命名示例：
$backupFile = "/backups/medical_" . date("Y-m-d_H-i-s") . ".sql"; - 清理示例：
if (time() - filemtime($f) > 7 * 86400) { unlink($f); } - 如果业务要求“保留最近 7 个文件”而非“7 天”，那才该按文件名排序取
array_slice(scandir(), -7)，但这种策略容易因失败导致空档，不推荐
时区与 32 位系统的时间戳溢出风险
2038 年问题虽远，但如果你的备份脚本要长期运行（比如部署在嵌入式设备或老旧 VPS 上），得确认底层系统是否为 32 位。一旦 time() 超过 2147483647，某些环境会回绕为负数，导致 time() - filemtime() 计算结果异常，可能批量误删。
检查方式：echo PHP_INT_SIZE === 4 ? '32-bit' : '64-bit';
- 64 位 PHP 环境无需担心，
time()可安全用到公元 292477 年 - 32 位环境建议尽快升级，或改用
DateTimeImmutable::createFromFormat()解析文件名中的日期（仅限你完全控制命名格式时） - 生产脚本中加一行防御性判断：
if (time()
真正容易被忽略的是：清理逻辑没做原子性保障。比如遍历中某个 unlink() 失败，后续文件就全跳过了。应该用 foreach + 单独 try/catch，或至少用 @unlink() 避免报错中断——毕竟删不掉一个旧文件，不该影响下一次备份。
