Immich-go项目中文件名相同但内容不同的文件处理问题分析

问题背景

在照片备份管理过程中，用户经常会遇到文件名相同但内容完全不同的文件。这种情况在手机拍照时尤为常见，因为手机相机的文件命名机制通常是循环使用的。例如，用户可能拥有IMG_3223.PNG和IMG_3223.MOV两个文件，它们虽然文件名相同，但一个是静态图片，一个是视频，且创建时间、EXIF元数据都完全不同。

问题现象

当使用immich-go工具上传这类文件时，如果采用目录上传方式（如upload .或upload directory/），工具会错误地将这些同名文件识别为"Live Photo"（动态照片）并合并处理。然而，如果单独指定每个文件上传（如upload file1.PNG file1.MOV），则能正确识别为独立文件。

技术分析

1. 文件名匹配机制：immich-go目前主要依赖文件名匹配来关联Live Photo的图片和视频部分。这种设计源于苹果设备常见的IMG_XXXX命名模式，但缺乏对文件内容的深入验证。

2. 元数据检查不足：真正的Live Photo在EXIF数据中会包含特定的Live Photo ID标识，而普通同名文件则没有这种关联。当前版本的immich-go没有全面检查这一关键元数据。

3. 上传方式差异：批量上传和单文件上传采用不同的处理逻辑，导致行为不一致。批量上传时工具会主动尝试匹配同名文件，而单文件上传则不会。

解决方案

1. 改进匹配算法：除了文件名外，还应检查以下要素：

   • 文件创建/修改时间是否相近（真正Live Photo的图片和视频部分时间戳非常接近）
   • EXIF元数据中的Live Photo ID（如果存在）
   • 文件扩展名组合是否合理（如HEIC+MOV是常见Live Photo组合）

2. 用户临时解决方案：

   • 使用通配符上传（如upload *）而非目录上传
   • 对可疑文件进行单独上传验证
   • 上传前使用exiftool等工具检查文件元数据

最佳实践建议

1. 上传前检查：对于重要照片库，建议先进行小批量测试上传，验证工具行为是否符合预期。

2. 元数据工具准备：在运行immich-go的主机上安装exiftool，有助于提高Live Photo识别的准确性。

3. 文件整理：对于历史照片库，可考虑先进行文件名规范化处理，避免命名冲突。

4. 监控上传结果：上传完成后，应检查系统生成的识别任务（如人脸识别）数量是否与预期相符。

这个问题展示了多媒体资产管理中的常见挑战，也体现了工具设计时在便利性和准确性之间需要做出的权衡。随着immich-go的持续改进，这类问题有望得到更完善的解决。