linux本身不记录文件内容修改历史，唯一能还原“每次改了什么”的方法是git log -p --follow -- filename，前提是文件已纳入git管理；stat、find等仅显示时间戳，auditd和inotify只记录操作痕迹而不保存内容差异。
Linux本身不记录文件内容的修改历史，没有像Windows那样内置的“版本快照”功能。要看到“某次改了哪几行”，必须依赖外部机制——最可靠的是 Git，其次是 auditd 或 inotify 实时捕获，但后者不保存内容差异。
用 git log -p --follow -- 查看带内容变更的完整历史
这是唯一能还原“每次改了什么”的方法，前提是你已把文件纳入 Git 管理。
-
git log -p --follow -- filename显示每次提交的 diff，包括新增/删除行、函数级改动 -
--follow关键：文件重命名后仍能串起历史（不加就断在 rename 那次） - 如果文件刚被
git add还没commit，git log查不到任何记录——Git 只存提交点，不存工作区临时改动 - 注意路径：必须在仓库根目录或子目录内运行，且
filename是相对于当前目录的路径（如src/main.c，不是/home/user/src/main.c）
用 stat 和 find -mtime 只能查“什么时候改过”，不是“怎么改的”
stat filename 输出里的 Modify: 时间戳，和 find /path -mtime -1 返回的列表，都只告诉你“有改动发生”，不包含任何内容信息。
-
-mtime -1表示“过去 24 小时内”，但实际范围是 0~24 小时；-mtime 1是 24~48 小时前——这个偏移容易误判，建议优先用-mmin -60查分钟级改动 -
stat的Change:字段常被误认为“创建时间”，其实是元数据变更时间（比如chmod、chown），和内容修改无关 - 如果文件系统挂载时用了
noatime（常见于 SSD 或生产环境），Access:时间可能完全不更新，别依赖它
auditd 能记“谁在什么时候改了文件”，但默认不存改了什么
auditd 是内核级审计工具，适合安全合规场景，但配置复杂，且原始日志里只有操作类型（SYSCALL）、PID、UID、路径，没有 diff。
- 启用后需先加监控规则：
sudo auditctl -w /path/to/file -p wa -k myfile_watch，其中-p wa表示写（write）和属性（attribute）变更 - 查日志用：
sudo ausearch -k myfile_watch | grep "type=SYSCALL.*syscall=write\|open.*O_WRONLY" - 它无法告诉你“第 15 行从
foo=1改成了foo=2”，只能确认“进程 1234 在 14:22:03 写入了该文件” - audit 日志默认不持久化到磁盘，重启后丢失；需配置
/etc/audit/rules.d/下的规则并重启auditd服务
真正想回溯内容变更，Git 是唯一开箱即用的方案；其他方法要么只给时间点，要么只给动作痕迹。最容易被忽略的，是 Git 历史依赖“主动提交”——没人 git commit，再好的工具也抓不到改动内容。
