文件内容最后一次写入时间（mtime）是可靠版本锚点，stat -c "%y" 输出ISO 8601格式、纳秒精度、跨环境一致；ls -l易受locale和宽度影响，显示不完整。
直接看 stat -c "%y" filename 输出的 Modify 时间，它就是文件内容最后一次被写入的时间——部署包解压、构建产物生成、配置文件覆盖等操作都会更新这个值，可作为版本时间锚点。
为什么 mtime 比 ls -l 更可靠
ls -l 默认显示 mtime，但它的格式受 locale 和终端宽度影响，比如年份可能省略（只显示时分）、时区不显式标注；而 stat -c "%y" 固定输出 ISO 8601 格式（如 2026-04-12 15:33:07.123456789 +0800），无歧义，适合脚本解析和跨环境比对。
- 若用
ls -l --time-style=full-iso可接近，但并非所有发行版默认支持（尤其旧版 CentOS 7） -
stat的%y始终稳定，且纳秒精度能区分同一秒内多次部署 - 注意：
ls -lt排序依赖 mtime，但不保证显示完整时间戳，别靠肉眼读
批量查部署目录下关键文件的 mtime
不要用 for f in *.jar; do stat "$f"; done —— 文件名含空格或换行会崩，且输出冗余。直接让 stat 原生处理多文件：
-
stat -c "%n %y" /opt/app/lib/*.jar：列出所有 jar 包及其 mtime，按字典序输出 -
stat -c "%n %y %s" /opt/app/conf/application.yml /opt/app/bin/start.sh：查特定配置与启动脚本，加%s防止文件被截断或替换成空文件 - 若需按时间倒序排列：
stat -c "%y %n" *.jar | sort -r | head -3，注意%y开头利于 sort
mtime 被意外覆盖？先排除 noatime 和 ctime 干扰
你看到的 Modify 时间突然“变老”，未必是回滚，可能是以下原因：
-
mount | grep noatime—— 若根分区启用了noatime，不影响 mtime，但有人误以为 atime 不更新 = mtime 也不准 - 执行了
touch -m -d "2025-01-01" app.jar等手动改时间操作，stat -c "%y %z" app.jar会发现 mtime ≠ ctime（ctime 总是当前时间） - 容器镜像层或 overlayfs 场景下，解压时若底层存储使用 XFS 且未启用 btime，
stat -c "%w"返回-，说明 birth time 不可用，别试图 fallback 到它
生产环境判断版本的真实逻辑链
单靠一个文件的 mtime 不足以确认部署版本，必须组合验证：
- 查主程序 jar 的 mtime：
stat -c "%y" myapp.jar - 查配套配置文件的 mtime：
stat -c "%y" application-prod.yml，若两者相差超 5 分钟，大概率配置未同步更新 - 查
RELEASE或VERSION文件（如有）：stat -c "%y" VERSION && cat VERSION，mtime 应 ≈ jar 的 mtime - 避免查日志文件（如
app.log）—— 它的 mtime 是最后写入时间，不是部署时间
最易被忽略的是：某些 CI/CD 流程会在打包后执行 strip 或 upx，这会触发 ctime 更新但 mtime 不变；此时若只监控 ctime，会误判为“新部署”。始终以 mtime 为准，且确保你查的是原始构建产物，而非运行时被工具二次处理过的副本。
