人脸、地图与时间线

三个视图撑起整个相册

Immich 的日常使用主要由三个视图串起来：时间线、人物、地图。时间线按时间组织全部照片，是默认入口；人物页面呈现人脸识别的分组结果，点进去就是某个人的专属相册；地图视图把带定位的照片落到地图上，一次旅行就是一条轨迹。三者叠加，覆盖了“什么时候、谁、在哪里”这三个找照片的核心问题。

这三个视图的底层都依赖元数据和机器学习：时间线靠拍摄时间（来自 EXIF），地图靠经纬度（同样来自 EXIF），人物靠人脸识别。理解了这一层，遇到问题就知道该查哪里：时间线错位多半是时区或元数据问题，地图空白是定位缺失，人物分组不准是识别的锅。

还有一个视图容易被忽略：收藏与回收站。加星标的照片在收藏视图里集中展示，找回误删照片则去回收站。回收站保留一段时间后才真正删除，这个缓冲期是网页端整理时的安全绳，批量删除前确认一下回收站的保留设置，给自己留够后悔时间。

收藏功能的隐藏价值在于它是“筛选器的筛选器”。几万张照片里加星标的那几百张，是整个图库的精华索引：年终做合集、洗印相册、发朋友圈选图，先从收藏视图挑，命中率比从时间线翻高一个量级。给家人分享时也是同一个逻辑——把收藏相册共享出去，几乎就是“最好的照片”的代名词。

时间线：分组与排序的秘密

时间线把照片按日期分组，每天的组数取决于拍摄密度。分组依据是照片的拍摄时间而不是文件创建时间——这两者经常不一样，尤其经过微信转发或云盘同步的照片，文件时间会被改写。时间线偶尔混乱时，检查元数据里的实际拍摄时间就能找到原因。

时间线的体验里有一个容易忽视的细节：滑动到很久之前的某天时，缩略图加载速度取决于固态盘上是否放得下全部缩略图。部署章节里把缩略图放固态盘的建议，在每天滑动时间线时兑现。

一个看不见但重要的机制是时区分组。照片携带的拍摄时间如果没有时区信息，Immich 会按服务器设置的时区来解释。服务器时区和常用拍摄地不一致时，跨时区出差的照片会整体偏移几个小时，表现为“明明晚上拍的出现在白天”。部署章节强调过时区配置，这里是它兑现的地方。出国跨时区的那几天，时间线的日期分组偶尔会差一天。这不影响照片的安全性，看着别扭可以在详情页里修正单张。

EXIF 拍摄时间缺失的照片（比如某些截图或老扫描件）会被归到文件日期所在的位置，有时会造成“今天的截图出现在去年的位置”这类困惑。给重要扫描件手动修正时间是一个一劳永逸的任务队列上的小活。修好之后时间线会自动归位，不用手动挪动任何照片。

人物分组的使用

人物页面把人脸识别的结果展示成头像网格，每个人物显示代表照片和数量。第一次使用时，新照片较多的人物是家人，可以先给他们命名。命名之后就能像点目录一样点进“某个人”的所有照片。这是 Immich 最有幸福感的交互：点进父亲的分组，从黑发到白发一页页翻过去；点进孩子的分组，从襁褓到入学几年时间跨度摆在一起。人脸分组的真正价值不在找到了照片，而在于它把一个人的成长史压缩成了两次点击。

人物分组也有需要维护的时候。识别可能出现两种误差：同一个人被拆成两组（尤其是不同年龄段或戴眼镜前后），以及两个相似的人被合并。人为检查的方式是翻一遍人数特别少或特别多的人物条目，手动合并或拆分。给孩子命名时建议加上年龄信息，比如儿子三岁，这样几年后翻到这个分组不会混淆。

一个让分组更好用的设置是隐藏非必要分组。相册里总会拍到路人、服务员、合影里的陌生人，人物页被这些占满会很乱。把他们隐藏之后人物页只剩真正关心的人，清爽很多。隐藏不影响照片本身，只影响人物页的呈现。

家里来了新成员（新生儿或新宠物）时，识别需要几天时间才能把新脸聚成一个稳定分组。第一周可能是零星的单人条目，别急着合并，等它自己稳定。想加速的话，手动把几张照片指派到同一个新人物即可。

地图视图：轨迹与回忆杀

地图视图把带定位的照片按城市聚合，点开城市就是当地拍的照片。它带来的体验很特别：不是按时间翻，而是按地点翻，一次旅行可以沿着地图重走一遍。家庭群里发“上次去云南吃的那家店”时，这个视图比聊天记录好用。

一个具体的使用场景值得描述：和孩子一起翻地图。点开他出生医院所在的城市，翻出出生当天的照片；再点开放假去过的小城，把整段旅行沿地图重走一遍。对孩子来说这是睡前故事的新形态，对老人来说是舍不得关掉的节目。地图视图把相册从存储工具升格成了回忆的容器。

家里老人翻地图的方式和我们不同。他们可能记不住怎么操作，但如果你把家乡所在城市打开，照片一张张滑过去的时候，他们能讲出每条街的故事。这种时刻是相册存在的真正理由，也是花几个晚上把整套系统搭起来的回报之一。

地图视图的小缺点是首次加载会拉取所有坐标，照片多时稍慢。定位准确性取决于手机，室内或信号差时坐标会漂移到奇怪的地方。隐私敏感的场合拍照前关定位，或者事后在网页端清掉某张照片的定位元数据，都是可行的。地图底图源于公开地图服务，不会把你的数据上传到任何地方——所有计算都在自己的服务器上完成。

搜索：从标签到语义

搜索框背后是三种能力的叠加：按文本（文件名、描述、地点），按人物（已命名的人物），按语义（描述性的短语直接搜图）。语义搜索是 Immich 的亮点功能，输入雨后的街道、生日蛋糕、海边日落这类短语能得到语义相近的结果。

语义搜索的准确度依赖向量模型，这也是为什么部署章节强调默认模型已经够用。它不是精确搜索，结果按相关性排序，偶尔混进无关照片正常；它是“我找不到那张照片但记得画面的样子”这种场景的解法。一个使用上的预期管理：语义搜索给的是“大概像”，不是“就是它”。把它当成模糊查找工具用，体验会一直好；期待它精确到每张，则必然失望。

一个进阶用法是把搜索结果直接存成相册。比如孩子生日的语义搜索结果，存成一个相册，之后新照片入库时满足语义的会自动追加——这类动态相册是相册功能的一个隐藏维度，等于让搜索结果跟着图库一起生长。做年终照片合集时，这个玩法能省下大量手动筛选的时间。

再说一个实用技巧的组合：人物加地点的双重过滤。想找去年和父亲在杭州的照片，在人物视图选父亲，再叠加地点条件，一两秒就能锁定几十张照片。这类组合查询是自建相册对云相册形成体验反超的地方——查询完全在本地跑，没有流量成本也没有等待，第一次用会有种以前相册白用了的感觉。

搜索功能还有一个不显眼的依赖：照片描述。给重要照片手写一两句描述（详情页里可以编辑），这些文字会进入搜索索引，大幅提升文本搜索的命中率。一晚给一百张标志性照片补完描述，会明显改变之后几年的查找体验。

元数据：照片的另一面

每张照片的详情页都能看到完整元数据：设备、镜头、光圈快门、坐标、原始文件名。这些信息既是查找依据，也是整理时的排错线索。比如发现一批照片时间全差八小时，就是典型的时区问题；一批照片坐标都指向同一个奇怪地点，就是定位漂移。

详情页还有一个实用功能：显示照片在存储里的实际路径。备份和迁移时需要核对文件位置，从这里直接拿到，不用猜目录结构。

元数据还有一个温情用法：给未来的家人留线索。扫描的老照片没有拍摄信息，手动补上日期、地点和一句描述——比如外婆抱着妈妈，一九八七年夏天，武汉。这些描述会进入搜索索引，多年后晚辈输入外婆两个字就能翻出整段历史。这是整理照片这件枯燥事背后的意义，也是自建相册把控制权交给你的具体体现之一。

老照片扫描实操上多说两句。用手机扫描翻拍是最初级的方案，光线均匀、手机端正能避免反光和透视形变；条件够的可以用平板扫描仪。批量扫描之后文件名往往是序列号，上传到相册里一片混乱。进了 Immich 之后用网页端的批量改时间功能把一叠老照片归到同一个年份，再补上描述，一晚上能把几代人的照片理出眉目。这件事值得找个春节假期做一次，做完的相册价值翻倍。

小结

时间线、人物、地图三个视图回答了“什么时候、谁、在哪里”，语义搜索补上了“什么样子”。出问题时按视图往下查：时区影响时间线、定位影响地图、模型影响人物。下一章看怎么把照片分享给家人和朋友。

延伸阅读

• 上一章《网页端上传与管理》：整理照片的前置操作。
• 下一章《相册分享与外链》，把照片发给别人。
• 《群晖 DSM 实用指南》：元数据与套件相册的差异参考。
• 《自建 NAS 完全指南》：时区与系统时间对元数据的影响。