find -mtime +1 漏掉一天前的文件：时间先按完整天数取整

文件明明已经修改超过一天，find . -mtime +1 却不列出它；换成按分钟筛选后又能找到。先检查时间条件的含义：GNU find 会将经过的完整 24 小时段数取整，再与 +1 比较。一个 35 小时前修改的文件只算 1 个完整时间段，不满足“大于 1”。

下面针对 GNU find，时间都指文件内容修改时间 mtime，且没有启用 -daystart。这不是文件创建时间，也不是 ls 显示的日期跨过一次零点就算一天。示例路径 /srv/archive 应换成实际待检查目录，排查阶段只打印，不删除文件。

把 +1 与 1 分开理解

对过去的文件时间，常见条件可以这样读：

• -mtime 0：修改距本次查找的起算时刻不足 24 小时。
• -mtime 1：至少 24 小时、不足 48 小时。
• -mtime +1：至少 48 小时。
• -mtime +0：至少 24 小时。

+ 表示取整后的数值严格大于给定数字，并不是“从这个时间点往前”。因此 +1 不等于“24 小时以前”，而 1 也不是一个精确时刻。

如果原意是筛选至少一天未修改的普通文件，可先查看以下结果：

find /srv/archive -type f -mtime +0 -print

如果原意是至少两天，就保留 +1。不要因为文件数量少就统一把数字减一；必须先明确保留期和边界，再检查实际文件时间。

更细的窗口用分钟，明确日期用时间点

-mmin 将单位缩小到分钟，但仍有取整规则，不是精确到秒的比较。把一天写成 -mmin +1440 并不意味着得到严格以秒计的 24 小时边界，不能据此验证紧贴边界的文件。

如果任务有明确截止时间，GNU find 可以直接比较时间点。例如下面仅列出修改时间不晚于指定 UTC 时刻的普通文件：

find /srv/archive -type f \
  ! -newermt '2026-09-01 00:00:00 UTC' -print

日期是示例，必须换成业务确认的截止时间。-newermt 判断“更新”，取反后包含等于截止时间的文件。它是 GNU 扩展；使用其他 find 实现时应核对手册，不能假定所有平台都支持相同日期字符串。

昨天与过去 24 小时不是同一个范围

任务要求按日历天查询时，可以在 GNU find 的时间测试之前使用 -daystart。例如列出昨天修改的普通文件：

find /srv/archive -daystart -type f -mtime 1 -print

它改变时间比较的起点，并且只影响后面的相关测试。不要把它放在 -mtime 后面，期待前面的条件也跟着改变。任务运行环境的时区应与保留规则一致；跨时区或夏令时边界有严格要求时，优先明确起止时间，不把“日历日”简单当成固定秒数。

验证条件后，再接回原任务

保存原查找命令与计划任务配置，挑选边界两侧的已知文件，核对其 mtime 和输出名单。找不到预期文件时，再看目录、权限和其他过滤条件，不要把创建时间或状态改变时间误当 mtime。命令出现权限等错误时，即使有部分结果，也不能据此认定检查完整。

如果原任务随后移动或删除文件，先替换成只读输出检查整份名单。时间条件改变会扩大或缩小操作范围；直接把 +1 改成 +0 后执行清理，可能处理原先还在保留期内的数据。文件名可能含换行时，机器处理名单应使用能够保留边界的输出与接收方式，不把逐行文本无条件当作安全文件列表。

回退查询配置只需恢复原条件；已经删除的文件不会因此回来。执行有副作用的后续任务前，应另行确认备份、保留期和恢复方法。本次修复的成功标准是边界文件和实际业务窗口一致，不只是命令返回了更多文件。