不能，os.stat()仅返回name()、size()、mode()、modtime()四个操作系统级元数据字段，无法提取exif拍摄时间、pdf作者等文件内容层信息，必须使用go-exiftool、go-ffprobe或pdfcpu等专用工具。
os.Stat() 能不能直接提取 EXIF 或 PDF 作者？不能，别试了
它只返回 os.FileInfo，字段就四个：Name()、Size()、Mode()、ModTime()。这些是操作系统给的“外壳信息”，不是文件内容里藏的“身份证”。JPEG 的拍摄时间、MP4 的帧率、PDF 的作者名——全都不在 os.Stat() 范围内。
常见误判是看到 ModTime() 和照片里 “DateTimeOriginal” 接近，就以为能替代。其实前者是文件被复制/保存的时间，后者才是快门按下那一刻；两者差几小时很常见。真要读内容层元数据，必须绕过标准库。
- 图片/PDF/Office 文档 → 用
go-exiftool（依赖系统已装exiftool） - 视频时长/流信息 → 用
go-ffprobe（调ffprobe，别自己解析 MP4 Box） - PDF 元信息 → 用
pdfcpu info或unidoc，os.Stat()返回空是正常现象
go-exiftool 初始化失败卡住？先检查 exiftool 是否在 PATH
go-exiftool 不是纯 Go 库，它 fork 并执行系统命令 exiftool -ver。如果失败，NewExiftool() 直接返回 error，不会等你调 ExtractMetadata() 才报错——所以卡住大概率是进程启动失败，不是超时。
部署时容易漏掉依赖：
- Debian/Ubuntu：
sudo apt-get install exiftool - macOS：
brew install exiftool - Windows：下载
exiftool.exe，加到PATH，别只放项目目录下 - Docker 容器：Dockerfile 里显式
RUN apt-get install -y exiftool，别只COPY exiftool.exe（缺 Perl 运行时）
初始化后建议复用单个 exiftool.Exiftool 实例，开启 StayOpen 模式（库默认开），否则每文件启一次进程，性能暴跌。
归档时按日期移动文件，为什么 os.Rename 会静默失败？
因为跨文件系统时，os.Rename() 报 invalid cross-device link，但错误信息里不提“跨设备”——你只看到失败，日志里找不到线索。尤其当源路径在 /home、目标在挂载的 NAS /mnt/nas 时，极易中招。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
安全做法分三步：
- 归档前用
os.SameFile(srcInfo, dstInfo)检查是否同设备 - 跨设备时改用
io.Copy+os.RemoveAll：先复制，再删源，最后校验大小 - 目标路径写入前务必
os.MkdirAll(dstDir, 0755)并检查权限，否则io.Copy会因无写权限 panic
别从文件名硬抠日期（如 log_20260618.txt），一律用 entry.Info().ModTime()。它由 os.ReadDir 预加载，零额外开销，且真实反映修改意图。
批量处理万级小文件元数据，为什么 filepath.Walk 越跑越慢？
它触发太多隐式 os.Stat()，且遍历顺序不可控、符号链接行为不透明。真正快的是 os.ReadDir()（Go 1.16+）：一次系统调用读完目录项，返回有序 fs.DirEntry 列表，Name() 和 IsDir() 是零成本的。
关键点在于：别无脑调 entry.Info()。只需过滤名称或类型？直接用 entry.Name() 和 entry.IsDir()。需要大小或时间？只对筛选后的条目调 entry.Info()，否则就失去性能优势。
更深层问题：小文件本身不是 Go 慢，是文件系统扛不住高频 inode 操作。100 万个小文件 ≈ 100 万次元数据操作。真要高性能，得跳过单文件直存，走合并存储（如 go-fastdfs 的 small_file_size = 131072）+ 元数据索引路径。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
