Linux stat 怎么判断文件真的变过：mtime、ctime、inode 与复制验收

部署脚本说配置文件已经替换，服务却仍然读到旧内容。Linux 上不要只盯着文件名和 ls -l 的时间，先用 stat 对照 inode、mtime、ctime 以及文件大小，再结合校验和判断到底是内容没变、路径指错，还是文件被原地修改了。

先用 stat 把文件身份和时间一次列全

先针对最终生效路径取一份基线：

stat -c 'path=%n inode=%i size=%s mtime=%y ctime=%z mode=%A owner=%U:%G' /etc/myapp/app.conf

这里最关键的是 inode 和大小。时间戳带纳秒精度，适合和发布日志比对；mtime 是内容修改时间，ctime 是 inode 状态变化时间，不能理解成“创建时间”。

如果只想看人类可读的完整字段，直接执行：

stat /etc/myapp/app.conf

排障时建议把命令输出保存下来，而不是凭终端一眼记住数值，因为下一次采样需要确认到底是哪一列发生了变化。

mtime 变了，为什么服务仍可能读旧内容

文件已经变化，只能说明目录项指向的内容发生了变化，不能证明运行中的进程已经重新打开文件。先核对内容哈希：

sha256sum /etc/myapp/app.conf
sed -n '1,80p' /etc/myapp/app.conf

如果哈希和发布产物一致，再检查服务是否在启动时读取配置、是否支持热加载，以及是否需要显式重载。以 systemd 管理的服务为例，先查看状态，再执行项目约定的重载动作：

systemctl status myapp.service --no-pager
systemctl reload myapp.service

不要把 reload 和 restart 混为一谈：前者依赖服务实现，后者会重建进程。配置文件的 mtime 没有替代服务自身的生效确认。

inode 变化通常意味着替换，而不是原地编辑

很多发布工具先写临时文件，再通过 rename 替换目标文件。这样做的结果是内容和路径看起来都对，但 inode 会变化：

before=$(stat -c '%i %s %y' /etc/myapp/app.conf)
sha256sum /etc/myapp/app.conf
# 执行一次发布或复制动作后
after=$(stat -c '%i %s %y' /etc/myapp/app.conf)
printf 'before=%s\nafter=%s\n' "$before" "$after"
sha256sum /etc/myapp/app.conf

如果进程在替换前已经打开旧文件，它可能继续使用旧 inode 对应的文件描述符。此时要确认进程重新加载配置，而不是只检查新的路径：

pid=$(pidof myapp | awk '{print $1}')
sudo ls -l /proc/$pid/fd | grep app.conf || true

看到 (removed) 之类的标记，说明进程仍持有已从目录中移除的旧文件。先按服务的安全重载流程处理，再确认新进程或新配置句柄。

ctime 变了，不代表文件内容一定变了

下面几种操作都可能改变 ctime：修改权限、属主、硬链接数量，或者替换文件。可以用权限和链接数一起核对：

stat -c 'inode=%i links=%h mode=%A owner=%U:%G size=%s mtime=%y ctime=%z' app.conf
chmod 640 app.conf
stat -c 'inode=%i links=%h mode=%A owner=%U:%G size=%s mtime=%y ctime=%z' app.conf

如果只看到 ctime 变化、mtime 和 sha256sum 都没变，优先怀疑元数据操作，不要直接判定配置内容被篡改。

复制和部署后的最小验收顺序

1. 确认检查的是服务实际读取的绝对路径，而不是仓库或临时目录里的同名文件。
2. 记录目标文件的 inode、size、mtime、ctime 和 sha256sum。
3. 确认属主、权限和 SELinux 上下文等运行前提没有被复制动作改变。
4. 按服务文档执行 reload 或 restart，再从状态、日志和实际接口结果验收。
5. 如果 inode 变了，检查进程是否仍打开旧文件或标记为 removed。

常见问题

Linux 的 ctime 是创建时间吗？

不是。ctime 是 inode 状态变化时间，权限、属主、链接数和文件替换都可能触发它。创建时间需要文件系统和工具支持，不能用 ctime 代替。

mtime 没变，文件内容就一定没变吗？

通常内容修改会更新 mtime，但脚本可以手动恢复时间戳，所以涉及发布验收时仍应比较 sha256sum 和文件大小。

为什么复制后 inode 变了？

如果复制动作创建了新文件，或者通过临时文件加 rename 替换目标，inode 变化是正常现象。关键是确认服务是否重新打开了新文件。

只看 ls -l 能完成配置验收吗？

不能。ls -l 主要展示权限、属主、大小和 mtime；完整验收还需要 inode、sha256sum、实际路径和进程侧的重新加载结果。

文件验收不要把时间戳当成唯一证据。用 stat 看身份和元数据，用 sha256sum 看内容，再从进程是否重新打开文件和服务实际行为完成闭环，才能解释“文件看起来更新了，程序为什么还没生效”。