filemtime()返回false主因是权限不足而非路径错误，需用is_readable()校验可读性，配合clearstatcache()解决缓存问题，并统一时区避免date()输出偏差。
filemtime() 返回 false 是权限问题，不是函数坏了
绝大多数人第一次遇到 filemtime() 返回 false，第一反应是“文件路径写错了”，其实更大概率是 Web 进程用户（比如 www-data 或 nginx）没权限读取该文件。尤其在 Docker、SELinux 或 NFS 挂载环境下，is_file() 可能返回 true，但 filemtime() 仍失败——因为 is_file() 只检查 inode 存在，而 filemtime() 需要读取文件元数据。
- 先确认：运行
ls -l /path/to/file，看属主/属组是否匹配 Web 用户，且权限位含读（r） - 容器中常见：挂载目录未加
:z或:Z（SELinux），或宿主机文件属主 UID 不匹配 - 别只靠
file_exists()前置判断——它不保证可读，is_readable($path)才是必要条件 - 错误信息通常是：
Warning: filemtime(): stat failed for /xxx，此时@filemtime($path)可压制警告，但必须配合显式判false
时区混乱导致 date() 输出和 ls -l 对不上
filemtime() 返回的是纯 Unix 时间戳（秒级整数），本身**不带时区信息**；而 date() 的输出完全取决于 date_default_timezone_set() 设置。服务器系统时区（timedatectl）、PHP 时区、你本地电脑时区三者不一致，就会出现 ls -l 显示 14:00，PHP 输出却显示 22:00 的情况。
- 查系统时区：
cat /etc/timezone或timedatectl | grep "Time zone" - 查 PHP 时区：
echo date_default_timezone_get(); - 安全做法：统一设为 UTC：
date_default_timezone_set('UTC')，再按需格式化，避免隐式转换 - 若必须用本地时区展示，确保
date_default_timezone_set()和系统时区一致，否则比较逻辑（如缓存过期判断）会出错
symlink 和 NFS 下 filemtime() 行为不可靠
符号链接默认解析目标文件的 mtime，NFS 则常因客户端缓存导致返回旧值——这两个场景下，filemtime() 的结果不能直接用于强一致性判断。
- 对 symlink 敏感场景（比如部署软链切换版本），改用
lstat($path)['mtime']获取链接自身元数据，它不触发 warning，也不追踪目标 - NFS 环境下，单次调用前加
clearstatcache(true, $path)强制刷新，但别在循环里滥用，I/O 开销明显 - 不要依赖
filemtime()做精确到秒的定时触发（如“文件修改后 5 秒执行”），ext4 默认 mtime 精度是 1 秒，XFS 虽支持纳秒但 PHP 不暴露 - 高频访问时，优先用
stat($path)一次性获取 size/mtime/ctime 等字段，比多次调用filemtime()+filesize()更高效
缓存机制让 filemtime() 两次调用返回相同值
filemtime() 结果默认被 PHP stat 缓存，连续调用不会重新查询文件系统——这在开发阶段容易误判“时间没更新”，上线后又因缓存失效显得“行为不一致”。
立即学习“PHP免费学习笔记（深入）”；
- 开发调试时，加
clearstatcache()在每次调用前（仅限调试，勿上生产） - 生产环境若需实时性（如热更新检测），应在关键路径手动清除：
clearstatcache(true, $path) - 注意：
clearstatcache()全局清除开销大，clearstatcache(true, $path)仅清指定路径，但 PHP 7.4 不支持传数组，只能单次单路径 - 缓存的存在意味着：即使文件刚被
touch修改，filemtime()仍可能返回旧值，除非缓存被清或过期（默认 TTL 由底层决定）
