你有一台手机。手机里存着过去五年的照片——孩子的第一颗牙、最后一次见外婆的那个下午、出差时随手拍的酒店房号。每天睡前，你的手机自动把它们全部上传到一个遥远的服务器上。你不读服务条款。你不看隐私政策。你只知道一件事：这个服务叫 Google Photos，它很方便，它几乎是免费的。
直到有一天它不是了。Google Photos 在 2021 年终止了无限免费存储；之后是阶梯价格——200GB 每年 $35.88，2TB 每年 $99.99。然后你会想起那些服务器里还存着你的全部照片。你可以迁移走吗？可以。Google Takeout 会给你一个 ZIP 包——文件名混乱、EXIF 剥离、Live Photo 拆成图片和视频两个独立文件。一个人的数字记忆被还原成一个数据导出任务。
这就是 Immich 3.0 出现的背景。2026 年 7 月 1 日，这个被广泛视为 Google Photos 最强开源替代品的自部署照片管理方案，发布了第三个大版本。Hacker News 上，对应的讨论帖在 16 小时内积累了 309 分、155 条评论。社区的兴奋不难理解：当一个项目告诉你「你不用再相信 Google」，它需要先证明自己确实够格。
3.0 改了什么
这次更新的体量比版本号暗示的更大。笔者从官方发布说明中归纳了几个关键方向。
移动端无损编辑。 之前 Immich 的移动编辑器会创建新的编辑副本标记。3.0 把 web 端已有的无损编辑体验搬到了手机上——裁剪、旋转、调整参数，原始文件毫发无损。编辑结果可以在手机和 web 之间跨端同步修改。这听起来像是基础功能，但实现非破坏性编辑管线意味着底层需要维护一套渲染参数映射，而不是直接改像素——工程量并不小。
工作流自动化（预览阶段）。 Immich 引入了拖拽式的触发器-过滤器-动作链条。用户可以在 Web 端 Utilities → Workflows 中创建自动化规则。目前支持的步骤包括资产类型过滤、地理围栏判断和 Webhook 触发。这个功能尚处于 preview 状态，但它的架构方向值得注意——一旦工作流引擎成熟，标记、归档、分享的重复劳动可以被系统接管。
安卓后台备份大幅增强。 旧版本的后台备份只能处理新拍的照片；3.0 使用了新的周期性任务调度器，全库后台上传成为可能。Android 端还会主动检测电池优化和通知设置是否可能阻断备份——这个细节体现的是一种工程态度：自部署软件需要自己处理云服务早已替你抹平的 OS 级限制。
其他值得注意的更新： HLS 实时视频转码（实验性，目前仅 web 端）；移动端 OCR 支持，识别照片中的文字并可选中复制；完整性检查——对比磁盘文件和数据库记录，标记 untracked/missing/checksum mismatch 三类偏差；时间线性能优化，单月大量资产浏览不再导致浏览器标签页冻结。
为什么是 Immich
自部署照片管理不是一个新概念。开源社区里有 PhotoPrism、Nextcloud Memories、PiGallery2、Lychee 等一票选择。但 Immich 在过去两年里跑出了差异：它从一开始就以「Google Photos 替代品」为设计目标，而不是「给 NAS 做一个照片浏览器」。
这个定位差异体现在几个工程决策上。第一，Immich 提供了完整的移动端 app（iOS + Android），支持自动备份——这是替代云服务的门槛级功能。第二，它的机器学习管线内置了人脸识别、语义搜索、物体检测，直接对标 Google Photos 的智能搜索能力。第三，它的 UI 设计刻意参考了 Google Photos 的交互模式——时间线滚动、按天分组、双指缩放——降低迁移用户的学习摩擦。
社区数据也支撑了这种判断。截至 2026 年 7 月，Immich 在 GitHub 上积累了约 55K stars。它的开发节奏保持高频——v3.0.0 的 changelog 仅 breaking changes 就列出了 20 余项，enhancement 和 bug fix 超过 200 条，新贡献者 50 余人。这不是一个「个人兴趣项目」的量级。
两张牌桌上的博弈
到这里，一个合理的追问就浮出水面了：自部署真的能替代 Google Photos 吗？这个问题不能笼统回答，它取决于用户坐在哪张牌桌上。
便利性这张桌子。 Google 的优势是压倒性的。零部署、零维护、全球 CDN、AI 搜索、自动相册、共享建议——这些功能背后是一支专业团队在维护。你拍完照，剩下的全交给 Google。自部署意味着什么？你需要一台 24 小时开机的机器、配置 Docker Compose、设置反向代理、安排备份策略、手动处理版本升级。Immich 的 v3.0 迁移需要手动改 .env 文件中的版本号并重拉镜像——对经常跟 Docker 打交道的人不算什么，但对普通用户来说，这已经是第一道门槛。
数据主权这张桌子。 这是自部署的全部理由。当你的照片存储在 Google 的服务器上时，你对它们的控制权受限于一份可以随时修改的 Terms of Service。你能在合规框架内导出数据——但导出格式由 Google 决定。你不是 Google Photos 的客户，你是它的产品使用者。而 Immich 把照片目录结构的控制权交还给你：文件以原始格式存储在你可以直接访问的磁盘路径上，数据库是你的，元数据是你的，备份策略由你定义。
两张桌子之间没有标准答案。HN 讨论中一位用户的评论切中了这个张力：「我接触自托管的全部原因，就是 Google Photos 100GB 存储配额满了。」另一位用户则从相反方向反驳：「我不想再管理一个自托管服务了。」两种立场都是合理的——自部署和云服务之间没有道德高下之分，只有需求优先级的不同。
「反派」不是 Google，是丧失主权的惯性
如果说这篇文章有一个需要被指认的对手，那不是 Google。Google 在商业逻辑之内提供了诚实的产品：用存储空间和数据权限换取便利。问题在于默认接受「照片不入自己的硬盘」已经成为一种无意识的惯性——因为云太方便了，把它变成默认选项甚至唯一选项几乎是不可逆的。
Immich 3.0 的价值在于证明另一条路走得通。它的移动编辑已经能和云服务对标；它的 AI 搜索在本地 GPU 加速下可以匹敌云端体验；它的工作流引擎正在构建自动化维度。这些功能几年前还不可想象——开源项目的工程能力一直在逼近商用产品的基线。
HN 讨论中有一场围绕端到端加密的辩论也揭示了这条路上的真实成本。当前 Immich 不提供 E2EE，因为它的搜索、人脸识别、视频转码都依赖服务端对明文数据的访问。有用户认为这是不可接受的缺失——自托管服务再可信，也挡不住硬件被盗或网络入侵。另一些用户则认为在自部署场景中，文件系统级加密（LUKS）是更合理的分层防护策略，把加密推到应用层会牺牲搜索和 ML 能力。笔者不认为这场辩论会有结论——它本质上是「安全性」和「可用性」的取舍在自部署场景中的一个具体实例，取舍的位置取决于你的威胁模型。
代价清单
在 HN 评论中最有信息量的是实操反馈。一位用户指出 Immich 在从 Google Photos/iCloud 导入照片这一环节有明显的体验短板：「他们有 9000 张被导入破损的 Live Photo，谁关心 OCR 功能？如果没法信任导入过程的完整性，后面的一切都是空中楼阁。」这个批评是中肯的——迁移工具的可靠性对一款以「替代」为定位的软件来说，优先级理应在新功能开发之上。
另外一些用户提到 Immich 目前依赖 immich-go 项目做外部导入，而这个工具存在已知缺陷且维护节奏偏慢。这意味着从云服务向自部署的迁移路径仍然不够平滑。
部署本身的门槛也在那里。官方推荐 Docker Compose 部署，至少 4 个容器（server、machine-learning、PostgreSQL、Redis）。对一台 2 核 4G 的 VPS 来说，资源压力不大；但 machine-learning 容器如果启用 GPU 加速则需要额外配置 CUDA 运行时。备份策略需要你自行设计——这是云服务替你做的事情中成本最高的一项。数据可靠性不再由 Google 的分布式存储架构担保，而是由你的 NAS 磁盘阵列和异地备份方案担保。
数据主权从不免费
把照片从 Google 的服务器迁出来，不是一次性的技术操作。它是一个持续的责任转移——你可以保留数据，也必须保护数据。Immich 3.0 让这个转移在功能层面变得可行，但无法替你承担运维决策的后果。
这也许就是开源自部署的诚实之处：没有人向你承诺一键无忧。你的照片库可以运行在你自己的机器上，前提是你愿意为这份控制付出时间。控制从来不是免费的——Google 收钱，自部署收时间。选哪种支付方式，取决于你觉得照片值哪种代价。
本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。
参考链接：