Linux 默认并不会把文件读取行为自动记成日志，这类信息要想留得下来，通常得提前把 auditd 或 bpftrace 这类审计手段配置好。至于 stat 里看到的 Access 时间，也不能太当真：一方面，relatime、noatime 这类挂载选项很可能让它失去参考价值；另一方面，它本身也不会提供用户、进程等审计层面的信息。
stat 看到的 Access 时间不是可靠访问记录，ls -lu 更不准；inotifywait 只能捕获部分打开行为；真要追溯，得靠 auditd 或 bpftrace。
为什么 stat /path 显示的 Access 时间不可信
内核维护的 atime 字段理论上表示最后访问时间，但实际几乎失效：
- 多数系统挂载时用了
relatime（默认）或noatime，atime不再随每次读更新 - 即使启用
strictatime，它只标记“至少被读过一次”，不记录次数、进程、用户，也无法区分cat、grep或dd dd if=/dev/sda of=/dev/null这类绕过 VFS 的块设备读取，atime完全不动stat输出的Access:行只是 inode 里那个字段的快照，不是审计证据
auditctl 监控单个文件读取的实操要点
这是唯一能在生产环境稳定落地的方案，但必须手动配置规则并持久化：
- 先确认服务运行：
sudo systemctl is-active auditd，未运行则sudo systemctl enable --now auditd - 加临时规则（重启后失效）：
sudo auditctl -w /etc/shadow -p r -k shadow_read，其中-p r表示只监读操作 - 查记录用：
sudo ausearch -k shadow_read | aureport -f -i，输出含 UID、exe 路径、命令行参数 - 永久生效：把规则写进
/etc/audit/rules.d/shadow.rules，内容同上，然后sudo augenrules --load - 注意日志膨胀：
/var/log/audit/audit.log可能被高频读撑爆，别对/proc或日志轮转目录加-p r
bpftrace 抓 read 系统调用的轻量替代方案
如果觉得 auditd 过于笨重，或者当前环境里的权限卡得比较死，bpftrace 往往是更靠近底层、也更灵活的一种方案，不过前提是内核得支持 eBPF：
- 统计各进程对 fd 的读频次（无路径）：
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_read { @reads[comm, args->fd] = count(); } interval:s:5 { print(@reads); clear(@reads); }' - 想关联文件路径？eBPF 里不能直接查
/proc/PID/fd/，得先抓出高频comm+fd组合，再人工用lsof -p PID或readlink /proc/PID/fd/FD_NUM反查 - 避免性能抖动：别在 tracepoint 里做字符串拷贝或大量
printf，聚合用@count类型即可 - 不兼容旧内核：5.10+ 才推荐用
struct file路径推导，之前版本建议专注 fd+comm 统计
inotifywait 只适合短期、低频、已知文件的监听
它不是审计工具，是事件通知机制，误报漏报多，仅适用于调试或看护极少数关键配置文件：
- 启动监听：
inotifywait -m -e access /etc/hosts 2>/dev/null，每次触发输出一行/etc/hosts ACCESS - 它依赖
IN_ACCESS事件，而该事件仅在 open(O_RDONLY) + 实际 read 后才发，mmap、sendfile、/proc 读取均不触发 - 多个进程并发读同一文件时，容易漏掉中间事件；轮询脚本（如每秒 cat 一次）会导致事件堆积或丢弃
- 无法得知 UID、PID、命令行，连是 root 还是普通用户都分不清
