os.path.getmtime() 返回 unix 时间戳（秒级浮点数），需用 time.localtime() 或 datetime.fromtimestamp() 转换为可读格式；注意时区、精度差异及异常处理，勿与 getctime() 混淆。
用 os.path.getmtime() 拿到的是时间戳，不是可读字符串
很多人一调 os.path.getmtime() 就直接 print，结果看到一串数字（比如 1715829342.123456），以为出错了。其实它返回的是 Unix 时间戳（秒级浮点数），单位是“从 1970-01-01 开始的秒数”，不是错误，只是没转成人类能看懂的格式。
常见错误现象：print(os.path.getmtime('test.txt')) 输出 1715829342.123456，误以为函数失效或文件不存在。
- 必须用
time.localtime()或datetime.fromtimestamp()转换才能得到结构化时间 - 注意时区：
time.localtime()用本地时区，time.gmtime()用 UTC；datetime.fromtimestamp()默认本地，datetime.utcfromtimestamp()是 UTC - 如果文件路径不存在，
os.path.getmtime()会抛FileNotFoundError，不是返回None
datetime.fromtimestamp() 格式化最灵活，但要注意 timestamp 类型
比起 time.strftime()，datetime 对象支持更直观的格式操作，比如加减、时区转换、ISO 标准输出。但它的输入必须是整数或浮点数时间戳——不能传字符串，也不能传 None。
使用场景：需要把修改时间转成 "2024-05-16 14:25:33" 这类格式，或者进一步做时间比较、偏移计算。
- 推荐写法：
datetime.fromtimestamp(os.path.getmtime(path)).strftime('%Y-%m-%d %H:%M:%S') - 如果只想要日期部分，用
.date()方法，比如datetime.fromtimestamp(...).date() - 别漏掉异常处理：路径无效、权限不足都会让
getmtime()报错，建议包在try/except (OSError, FileNotFoundError)里
Windows 和 Linux 下 getmtime() 的精度差异会影响判断逻辑
Windows 默认只记录到 100 纳秒级别，但实际 FAT32 文件系统可能只精确到 2 秒；Linux ext4 通常支持纳秒级，但 Python 的 os.path.getmtime() 默认只暴露秒+微秒（取决于底层 stat 返回）。这意味着：同一文件在不同系统上两次获取的时间戳可能看起来“没变”，即使你刚改过内容。
性能 / 兼容性影响：如果你用修改时间做缓存校验（比如“文件没变就不重读”），光比对 getmtime() 结果可能不可靠。
- 不要用
==直接比较两个getmtime()返回值来判断文件是否变更，尤其跨平台时 - 更稳妥的方式是结合
os.path.getsize()，或用hashlib算小文件的哈希 - 若需高精度，Linux 可尝试
os.stat().st_mtime_ns（纳秒整数），但 Windows 上该字段不一定有意义
别把 getmtime() 和 getctime() 搞混，尤其在 Windows 上
在 Windows 上，os.path.getctime() 返回的是“创建时间”，不是“状态改变时间”；而在 Linux 上，它其实是“inode 修改时间”（比如改权限、改硬链接数），和修改时间（mtime）完全不是一回事。很多人想监控文件内容变化，却误用了 getctime()，结果发现时间没更新——因为只是改了内容，没动属性。
使用场景：只有当你明确需要“文件首次创建时刻”（Windows）或“元数据最后变更时刻”（Linux）时才用 getctime()。
- 查内容是否被编辑，只认
getmtime() - Windows 下
getctime()一旦设置就不会再变（除非程序主动改），所以不能用于检测更新 - macOS 是个特例：它的
getctime()行为接近 Linux，但文档不保证，建议避免依赖
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
