stat是唯一能直接、准确读取文件修改时间（mtime）的命令，其modify:行明确标识文件内容最后一次被写入的时间；ls -l因格式策略和缓存机制仅显示近似值，find -mtime用于范围筛选但不精确到秒。
stat 是唯一能直接、准确读取文件修改时间（mtime）的命令，ls -l 显示的只是近似值，find -mtime 用于范围筛选但不精确到秒——别拿 ls 当真相用。
直接看 Modify 行最稳
运行 stat filename，输出里明确标着 Modify: 的那一行就是文件内容最后一次被写入的时间（mtime），不是访问时间，也不是元数据变更时间。
-
Modify:对应 mtime，改内容才变；Access:是 atime（读触发），Change:是 ctime（权限/所有者等变更） - 某些挂载方式（NFS、CIFS、FUSE）下 mtime 可能滞后几秒，这不是命令不准，是服务端同步机制问题
- 别信
stat *：文件名含空格或换行会崩；安全做法是for f in *; do [ -f "$f" ] && stat "$f"; done
stat -c '%y' 提取可读时间字符串
GNU 系统（Ubuntu/CentOS）用 stat -c '%y' filename 输出带纳秒和时区的完整 mtime，例如 2026-07-09 21:50:12.345678901 +0800。
- 只要年月日时分秒？加
| cut -d. -f1截掉纳秒和时区：stat -c '%y' filename | cut -d. -f1 - macOS 或 Alpine（BusyBox）不支持
-c，得用stat -f '%Sm' -t '%Y-%m-%d %H:%M:%S' filename - 脚本跨平台时，先检测
stat --version，否则 fallback 到ls -ld --time=modify --time-style=long-iso
为什么 ls -l 显示的时间经常“不准”
不是 bug，是设计差异：ls -l 默认显示 mtime，但格式策略和底层缓存会让它看起来不可靠。
- 距今超 6 个月，
ls -l把时间部分换成年份（如Jul 12 2025），不是不准，是故意省略时分秒 - NFS 或 noatime 挂载下，内核可能缓存 mtime，
ls读的是缓存值，stat走底层接口更实时 - 想强制统一格式？用
ls -ld --time=modify --time-style=long-iso filename
按修改时间找文件，find -mmin 比 -mtime 更准
查“最近 10 分钟改过的文件”，find /path -type f -mmin -10 是唯一原生靠谱方案。
-
-mmin -10精确到分钟（含第 0 秒），不受 locale、时区影响；-mtime 0是过去 24 小时，误差可达 23h59m - 必须加
-type f：否则目录的 mtime（反映子项增删）会被误当内容修改 - 要递归找整个目录树最新改的文件？别用
ls -t /path/* | head -n1——不递归、漏子目录、遇空格崩溃；正确写法是find /path -type f -printf '%T@ %p\n' | sort -nr | head -n1 | cut -d' ' -f2-
真正容易被忽略的是：mtime 不是你“感觉上”文件被改的时间。容器里、跨时区挂载、只读文件系统、甚至某些编辑器保存策略（如原子写入+重命名），都可能导致你看到的 mtime 和预期不一致。查之前，先确认文件是否在真实可写路径、是否被中间层缓存过。
