多年的照片一直存在 Google Photos 里，最近这件事却总让你心里不太踏实。倒不是 Google 做错了什么，只是每一张脸、每一个地点、每一条“那年今日”，都归它索引。每当有人说“这些东西你完全可以搬到自己的服务器上”，被反复提起的工具就是 Immich。人脸识别、自然语言搜索、手机自动备份、“回忆”（Memories）信息流，全套都有，而且跑在一台由你自己管理的服务器上。
我实际跑了一段时间 Immich，想验证这套说辞到底站不站得住。这不是功能清单复读，而是用出来的结论。时机也很重要：Immich 发布了 v3.0.0 ，时间是 2026 年 7 月 1 日。这次更新对产品的改动之大，让不少旧评测描述的已经不是现在这个东西了。本文看的就是 v3，评判标准只有一个：你敢不敢把它当作全家照片的主存放地，包括它在哪些地方仍然输给 Google。
简短版本
如果你想把照片库握在自己手里，并且愿意承担日常维护，Immich v3 已经可以取代 Google Photos。 在日常使用中，它的移动备份、搜索和人脸识别已经足够接近 Google 的水准，你未必会想念什么。使用默认的本地机器学习配置时，照片分析全程留在你的部署内部。代价是：不弄丢照片库这件事从此归你负责；有用户在升级时翻过车，尤其是较老或深度定制的部署；一套像样的备份不是可选项。如果你想要零维护、开箱即用的照片服务，请留在 Google Photos。
按维度拆开，我的实际体验是这样：
- 移动备份： 强项。Immich 支持在 iOS 和 Android 上自动后台备份，正是这个功能让它成为 Google Photos 的替代品，而不只是一个照片存档。
- 搜索与人脸识别： 扎实。语义搜索（“海滩上的狗的照片”）确实可用，而且 Immich 能 自动为人脸分组；给分组命名后就能按人名搜索。在我的测试中，长相相似的人是薄弱环节，我偶尔得手动纠正分组。
- 资源占用： 比多数人预期的重。整套服务包括 Immich、Postgres、Redis 和机器学习服务，至少需要 6 GB 内存，推荐 8 GB。完整的机器学习栈并不适合内存偏小的 Raspberry Pi。如果禁用或外移机器学习，它也能在受限硬件上跑，但那会放弃或复杂化一部分让 Immich 值得替代 Google Photos 的功能。
- 维护与升级风险： 软肋所在，也是结论里那个“如果”的来源。有用户在较老或定制化的部署上遇到过迁移失败。无论如何，你都需要 3-2-1 备份。
- 数据主权： 换过来的最大理由。使用 Immich 默认内置的机器学习容器时，照片分析、人脸向量和语义搜索处理都留在你的部署内部。如果配置了远程机器学习，图片预览会被发送到那台主机，隐私边界就取决于你怎么部署。在你永久删除 Google Photos 上的副本或清空 Google Photos 的回收站之后，Google 表示从活跃系统中删除通常需要大约两个月，而加密备份副本最长可能保留六个月。
推荐给： 以隐私为出发点、能熟练打理 Docker Compose 的自托管用户；愿意替他人扛下备份和升级的家庭或小型组织系统管理员；看重活跃开发、想要一套经得住考验的移动备份体验的技术评估者。 不适合： 只想“让全家人共享照片”、完全不想碰维护的人，或者身边没有人能负责升级的非技术用户。
这篇评测覆盖什么，不覆盖什么
我用了大约 10 天时间测试 Immich v3，评测结束时运行的是 v3.0.2。我按官方 Docker Compose 方案把它部署在一台 8 GB 内存的 Ubuntu VPS 上，用的是我自己约 9,000 张照片的个人照片库。Immich 免费且开源。本文没有任何赞助，也没有人为这篇评测提供任何东西。
开始之前，先把预期设定清楚：
- 这是一篇评测，不是部署教程。我不会逐步讲安装，也不会讲 docker-compose.yml，那值得另开一篇。这里要回答的问题是你该不该用它，而不是怎么装它。
- 在这段时间里，我完成了一次完整部署和一次小版本升级。10 天的窗口不足以证明跨越多个升级周期的长期稳定性，所以凡是需要更长期证据支撑的维度，我都会明说。
- 替代品（PhotoPrism、Ente）会在更适合特定读者的地方被点名，但这不是一篇三方对比。想看对比的话，那是另一篇文章。
Immich 能取代 Google Photos 了吗？
简短回答：对合适的人来说，能。而“合不合适”的判断标准完全在于你想不想承担维护，而不是软件够不够好。软件已经够好了。 Immich v3 把 Google Photos 的核心任务（移动端自动备份、人脸与语义搜索、“回忆”信息流）做得足够好，用了一周之后，我就不再习惯性地打开 Google Photos 了。你真正要决定的，是你想不想成为那个让它持续运转的人。
这个区别很重要，因为多数人换工具时不是这么想的。他们对着功能清单比一遍，认定 Immich 已经完成了 90%，就切换了。但决定他们六个月后是否满意的，并不是缺失的那 10% 功能，而是他们有没有搭好备份、有没有扛过第一次大版本升级。所以这篇评测的权重也照此分配：在我的结论里分量最重的两个维度是维护风险和数据主权，而不是功能数量。一个移动上传和搜索都做得漂亮、却在一次升级中弄丢你照片库的工具，恰恰砸了最重要的那一件事。
换过来的最大理由是主权：你的照片，你的服务器，在默认本地机器学习配置下，没有任何外部照片服务在索引你的家庭照片库。不换的最大理由是：你等于签约成为一个“一人 IT 部门”，管的还是你手上最不可替代的数据。这两条同时成立，哪条占上风取决于你，而不是 Immich。
有一点值得先说，写给那些看过今年早些时候的评测然后被劝退的人：v3 补上了曾经那条硬伤。无损照片编辑现在可以在手机上用了，裁剪、旋转、调整都不会动原始文件。如果“手机上连照片都没法编辑”曾是你观望的理由，这个理由已经不存在了。
本节要点：结论的关键不在于 Immich 够不够好，它够好。关键在于你想不想接下随之而来的这份活儿。
Immich 做得好的地方
Immich 有三件事做得好：整个测试期间经得起日常主力使用的移动端自动备份；日常体验接近 Google 水准的机器学习搜索和人脸分组；以及把机器学习处理留在你掌控的基础设施之内的默认部署模型。 正是这些功能让它成为 Google Photos 的替代品，而不是一个花哨的图片文件夹。三项在测试中都站住了。
真正打动人的是移动备份。我在手机上装好应用、指向我的服务器，新照片就在后台自动上传，完全不用我操心。v3 还围绕新的周期性任务调度器重写了 Android 备份。在我 10 天的测试里，后台上传一直可靠。这个功能必须无聊且可靠，否则整套方案就散架了。它做到了。
搜索是第一次用会觉得像魔法的部分。Immich 使用 CLIP 系列模型 为语义搜索生成向量，你可以直接输入“雪地里的红色汽车”，不打任何标签也能找到那张照片。人脸识别基于 InsightFace 的检测和识别模型。Immich 自动为整个照片库做了人脸分组，我给几个人命名之后，“人物”视图就成了快速找人的利器。这两项功能都在你的服务器上作为后台任务运行；语义搜索索引由 Postgres 里的 VectorChord 驱动。
关于搜索质量的保留意见值得说具体一点。在我的照片库里，类别识别很强（它能稳定地认出猫就是猫），但区分五官相似的人就难多了。 人脸分组的结果也会随一些因素变化 ：所选的模型、 聚类设置，以及照片库本身的构成。在我的使用中，用它找某个具体的人已经够用，只是偶尔出现错误分组，需要我手动修正。
接下来是对为隐私而切换的人最重要的部分。Immich 的 内置机器学习工作进程 以独立容器的形式运行在你的部署内部，而不是调用第三方图像分析服务。在这套默认配置下，照片预览、人脸向量和语义搜索处理都留在你掌控的基础设施之内。Immich 也可以使用 远程机器学习主机，这时服务器会把图片预览发送到那台主机处理，所以你应当把它视作可信环境的一部分。在你永久删除 Google Photos 照片库，或 清空 Google Photos 的回收站, Google 官方说明 ：此后从活跃系统中彻底删除通常需要大约两个月，而加密备份副本最长可能保留六个月。
Immich 的短板在哪里
Immich 落后于 Google Photos 的地方主要在打磨程度上： 自动生成的精彩视频和电影感照片, 生成式编辑工具，以及更深度的生态整合，包括让其他应用通过 受支持的移动端照片选择器访问已备份的照片。此外，它对硬件的要求高得多，而且在家庭网络之外访问照片库还需要额外配置。
Immich 提供 实验性的、需手动开启的 Google Cast 投屏 功能，可以从其网页客户端投到 Chromecast 和 Nest Hub 这类设备上。不过，投屏要求实例可以通过公网 HTTPS 访问，且其 DNS 记录能被 Google 的 DNS 服务器查到。Android 和 iOS 端投屏仍在规划中，Immich 也没有专门的电视应用。
资源占用是最容易让人措手不及的地方。Immich 不是单个进程：典型部署包含 Immich 应用服务、Postgres、Redis，外加一个独立的机器学习服务。根据 官方配置要求 ，内存至少 6 GB，完全禁用机器学习的话是 4 GB（但那样你就失去了搜索和人脸功能，而这正是运行它的一半理由），推荐 8 GB。CPU 至少两核，推荐四核。数据库要求本地 SSD 存储，并明确不建议放在网络共享上。首次导入时，机器学习管线会把 CPU 拉满、大量吃内存来索引所有照片（我的机器高负载跑了差不多两天），之后就安静下来了。重点在这里：如果你想象的是抽屉里的一台 Raspberry Pi，请重新设定预期。这是小型服务器级别的工作负载。
注意： v3 略微抬高了 CPU 的门槛。amd64 机器学习容器现在需要 x86-64-v2 微架构级别，2012 年前后以来发布的大多数处理器都支持它。如果你的硬件非常老，投入之前先确认这一点。这事很容易被忽略，直到机器学习容器起不来才会发现。
最后一条，对家庭用户是实打实的考量：远程访问取决于你把 Immich 托管在哪。放在家用服务器上，本地访问很简单，但出门在外想访问照片库，就需要 VPN、反向代理或安全隧道。放在 VPS 上，主机本身连着互联网，但只有你主动暴露 Immich 时它才能被公网访问。真要暴露的话，HTTPS 和恰当的访问控制应当在初始部署时就到位。Immich 官方明确 警告不要把它的应用端口直接转发 到公网。而无论哪种情形，Google Photos 都替你把这套基础设施处理好了。
本节要点：在日常主力功能上，Immich 与 Google 打平；在打磨和生态上，它落于下风。对看重数据主权的用户，这笔交换划得来；对依赖 Google 自动精彩视频、移动端投屏和官方电视集成的人，这是实实在在的损失。
升级与维护的现实
一旦照片住进了你自己的服务器，不弄丢它们就成了你的工作，而 Immich 的升级偶尔确实让用户栽过跟头，尤其是在较老或深度定制的部署上。 正是这个维度，把我的结论从无条件的“能”变成了有条件的“能”，所以值得把风险是什么、不是什么讲精确。
先说维护的现实。运行 Immich 是一份强度不高、但绝非为零的长期工作。它有周期性更新，隔一阵子还会有大版本带来破坏性变更，逼着你去读发布说明。这不是每天都要盯着的活（大多数时候它就那么安静运行着），但确实是一份承诺，而且完全落在你头上。在 Hacker News上，一位评论者把反对意见说得很直白：
“你得是个 Web 开发者或者系统管理员，才能驯得住那玩意儿。升级是噩梦，还有一大堆跟同步相关的诡异 bug。”
这比我的实际体验要苛刻，但它指向的运维风险是真实存在的。 有用户报告称 自己的照片库在一次升级后消失了；后来查明是 PostgreSQL 数据卷开机时没有挂载，修好挂载后照片库就回来了。在另一个问题里， 一次迁移失败 发生在外部 PostgreSQL 部署上，原因是一个数据库角色标识符没有正确加引号。这些案例说明的是定制化的存储和数据库配置可能在升级前后出岔子；它们并不说明 Immich 会动不动删照片。
v3 的数据库警告主要针对特别老旧或深度定制的安装。Immich 把用户从 pgvecto.rs 迁往 VectorChord 的进程始于 v1.133.0，那还在 v2 之前；v3 则移除了残留的 pgvecto.rs 兼容支持。因此标准的 v2 部署应该早已在用 VectorChord， 常规的 v2 升 v3 更新 通常只是改一下版本标签，然后照例执行 Docker Compose 拉取和重启。仍在使用 pgvecto.rs 的部署，应当先完成 Immich 的 VectorChord 迁移 ，再升级到 v3。
这就引出那条没有商量余地的规则，而且它出自 Immich 官方，不是我说的：
注意： Immich 不是备份。团队自己就是这么直说的。在 v2.0.0 版本发布说明 里，他们写道：“3-2-1 备份策略依然至关重要。团队有责任确保应用本身不会造成你珍贵回忆的丢失；但我们无法保证硬盘不会损坏，也无法保证电力事故不会导致你的服务器/系统意外关机，进而造成数据丢失。”Immich 本身并不是一套完整的备份策略。如果那台服务器是这些文件唯一的持久副本，它就是你的主副本，而不是备份。你需要三份副本、存放在两种介质上、其中一份放在异地。如果这篇评测你只带走一件事，就带走这一条。
还有一个相关的信任问题，对持怀疑态度的读者来说值得一提。我只从部署者的视角谈，毕竟我没有审计代码库：这个项目健康吗？就现有证据看，健康。项目开发活跃，问题有人回应。2025 年末，Google Safe Browsing 标记了一个 Immich 域名。Immich 将该警告描述为误报，影响的是其预览基础设施，而非用户的照片库。据项目方说法，Google 在复核后撤销了警告，但在创建新的预览环境时警告又出现了。Immich 表示会把这些环境挪到专用域名上。这看起来像一个把问题摆在明面上处理的项目，而这正是你把照片库托付给它时想看到的。
本节要点：照片一旦住进你自己的服务器，不弄丢它们就成了你的职责。Immich 把难的部分都做得不错，但这一部分它替不了你。
谁该用 Immich，谁不该用
Immich 适合这样的人：想要 Google Photos 式的功能，又不想把照片库放在 Google 的服务器上，并且愿意为此运行一台小服务器。它不适合想要零维护、只求全家能共享照片的人。 整个决策就这一句话。
如果你属于下面这几类，就该用 Immich：
- 以隐私或数据主权为出发点的自托管用户。 你想要人脸识别、搜索和移动备份，同时希望默认的机器学习处理留在你掌控的基础设施之内。这是 Immich 的主场，它在这里表现出色。你要的是控制权，而控制权正是它交付的东西。
- 家庭或小型组织的系统管理员。 你能坦然扛下备份和升级纪律，而且是替只想“照片能用”的家人或小团队来做这件事。你承担运维的重量，好让他们不必承担。Immich 很合适，前提是你自己始终盯着升级动态。
- 看重项目发展势头的技术评估者。 你想要一个持续出货的项目：移动备份体验在我的测试中经受住了考验，而且仍在活跃开发。Immich 的发布节奏和社区活跃度都符合这一条。
如果你属于下面这几类，就不该用 Immich（至少现在还不该）：
- 那个“我只想让大家能共享照片”、对维护毫无兴趣的人。 调研过程中我看到的最一针见血的评论，是有人说 Immich 解决的不是他们的问题：他们只是想让全家共享照片，自托管和这个需求根本不匹配。他们说得对。如果这就是你，那答案是 Google Photos（或某个托管方案）更贴合你的实际问题，这没什么不好意思的。
- 身边没人能接手运维的非技术用户。 如果没有人负责备份和更新，这套部署反而会把你的照片库置于风险之中，这恰恰与你的初衷背道而驰。
如果你落在“暂时不用”的阵营、但仍想离开 Google，有两个替代品值得看看，理由各不相同。 PhotoPrism 是“存档优先”的选项：如果你真正想要的是给硬盘或 NAS 上的既有照片存档建索引，又不需要官方的移动备份应用，选它；它依靠 浏览器和 PWA 访问 ，而不是自家的原生应用。 Ente Photos 则是把端到端加密置于一切之上的人该看的：它在上传前加密照片，在设备端运行机器学习，并在同步前加密生成的索引，还通过了多次独立安全审计，其中包括一次 由 CERN 出资的 Cure53 评估。两者都是正经选择，只是它们优化的对象和 Immich 面向的读者不同。（想看三者的完整正面对比，那值得单独成篇，而不是硬塞进这里。）
最后说说成本，因为这个问题被问得太多。Immich 本身免费，但自托管并不自动等于更便宜。把服务器、电费、异地备份存储和你自己的时间都算进去，总成本可能超过一份 Google One 订阅。请拿这些成本和你所在国家/地区当前显示的 Google One 价格对比，因为套餐和促销因地区而异，也会随时间变化。换，是因为你想要控制权，而不是因为你默认自托管能省钱。
对于已经被说服、但还需要打基础的读者（一台服务器、Docker、运行自托管服务的基本功），那些铺垫内容是另外的话题。至于 Immich 如何与自有文件存储之类的组件一起，纳入一套更完整的隐私优先方案，可以读我们的这篇指南： 最佳自托管隐私栈.
常见问题
Immich 稳定到可以托付我唯一一份家庭照片吗？
不行，不能只有这一份。Immich v3 可以充当你的主照片库，但同样的文件还应该存在于一套独立的备份系统里。Immich 团队自己就推荐 3-2-1 策略：三份副本，分布在两种介质上，其中一份放在异地。Immich 可以整理和提供你的主照片库，但它永远不该是那些不可替代的照片存在的唯一地方。
Google Photos 有哪些 Immich 做不到的？
Google 仍然领先的地方在于 自动生成的精彩视频和电影感照片、生成式编辑，以及更广泛的消费级生态。Immich 有“回忆”信息流和无损照片编辑，还提供 实验性的、需手动开启的投屏 功能，可以从网页客户端投到 Chromecast 和 Nest Hub，但该功能要求部署可以通过公网 HTTPS 访问。移动端投屏和专门的电视应用仍然缺席。
Immich 的人脸识别有 Google Photos 那么好吗？
就“给认识的人分组”这件日常任务而言，已经很接近。Immich 会 自动创建人脸分组，命名之后这些分组就可以搜索了。薄弱环节是区分长相相似的人。不存在一个有意义的通用准确率百分比，因为结果取决于照片库、模型和聚类设置。在我的测试中，它的可靠程度足以支撑日常搜索，但仍偶尔需要手动修正，尤其是五官相似的人。把它理解为“在我的测试里日常搜索够用，偶尔需要修正”，而不是一个测出来的数字。
维护 Immich 有多难？
这是一份强度不高、但实实在在的长期工作。大多数时候它自己运转，但你需要定期应用更新，偶尔还会碰上带破坏性变更的大版本，所以升级前要读发布说明并核实备份可用。备份纪律永远压在你身上。如果你熟悉 Docker Compose、也习惯读发布说明，这事很好管理；如果不熟，就给学习曲线留出预算。
Immich 真的比 Google Photos 便宜吗？
常常并不便宜。把所有开销都算上（服务器、电费、备份存储、你的时间），总成本可能超过一份 Google One 订阅。Google One 的价格和促销因国家和时间而异，所以请对照你所在地区当前的价格来比较。切换的理由应该是掌控自己的数据，而不是省钱。如果成本是你唯一的动机，请先把总成本算完整，因为结果未必偏向自托管。
