手机相册是很多人最私密也最沉重的数据：几年累积的几万张照片和视频，散落在手机里，怕手机丢了、怕云盘把数据捏在自己手里、怕哪天备份不完整就再也找不回某一段。Immich 就是为"把照片视频收拢回自己手里"而生的自托管方案：一个开源的私有照片与视频管理平台，提供手机端自动备份、相册整理、按时间轴浏览、智能搜索（人脸/对象识别）、分享协作等接近商业云相册的能力，但数据和隐私都在你自己的服务器上。这篇讲清它解决什么、怎么用 Docker 起来并接好存储、手机端怎么长保自动备份、AI 识别与搜索是怎么回事，以及它对硬件、数据库和"备份它本身"这件事的现实要求。
一、Immich 解决的两件事：手机自动备份 + 像"本地版云相册"那样管理
先分清两个层面的需求就懂了它的定位。第一层是"备份"：手机里的照片不该只存在于一台设备上，要么定期拷出来、要么自动云端/自托管备份，真正怕的是"手机坏了，几年照片全没"。第二层是"管理"：照片多了以后，靠"翻相册"远远不够，你要能按时间、地点、人物检索，要能建相册、做分享。商业云相册两者都给，但代价是数据放在别人的云端、隐私取决于别人条款。
Immich 把这两层都放到自托管：手机/相机装客户端后，只要愿意就能把照片自动上传到你的服务器（不依赖厂商云），然后你在自己的机器上获得接近商业云相册的体验——自带的机器学习（机器学习 face/object/场景识别）帮你做人脸聚类、对象检索和按年-月-日的时间轴浏览。它天然属于我们反复讲的"把数据与识别能力握在自己手里"的主线：不止是存，连"检索照片"这批能力也跑你自己的硬件。
二、最小落地：Docker 起服务、挂好照片存储、确定数据库
Immich 官方推荐用 Docker Compose 部署，因为它是一整套服务（Web/API、机器学习、Redis、PostgreSQL 数据库等）。部署本身不难，难点在"想清楚照片该放哪、数据库该放哪、要不要装机器学习"。给一个标准的 compose 简版（正式部署建议用官方提供的完整 compose 文件）：
# docker-compose.yml（简版示意，正式请引用官方文件）
services:
immich-server:
image: ghcr.io/immich-app/immich-server:release
ports: ["2283:2283"]
volumes:
- ${UPLOAD_LOCATION}:/usr/src/app/upload # 照片/视频实际存储目录
- ./immich-config:/config
env_file: .env
depends_on:
- redis
- database
redis:
image: redis:7-alpine
database:
image: tensorchord/pgvecto.rs:pg14
environment: { POSTGRES_PASSWORD: "换一个强密码" }
volumes:
- ./pgdata:/var/lib/postgresql/data
部署后的关键分派要想好三件事。一是"照片存储目录"用环境变量指向你的数据盘（最好挂到有快照/备份的存储上，而不是系统盘）；二是"数据库"是长期承载索引与新媒体验证的持久层，务必独立卷并纳入备份；三是"机器学习识别"是可选的大头——如果你不想要人脸/对象智能搜索，可以把 ML 服务关掉省资源，想要智能搜索再开。先把这三件事分派清楚，后面扩展才不会返工。
三、手机端：让备份"持续、静默、不打断"地发生
Immich 的杀手锏之一就是手机 App 的自动备份：装好、登录你的服务器地址、打开自动备份后，新拍/新增的照片会按策略自动上传，你不用再手动导相册。几件提升体验的设置值得做对：在手机端选"只在 Wi-Fi 下备份"和"允许后台备份"，避免流量和打断；给备份设置一个"足够的并发与保留策略"，并让"上传后清理"与你自己的容错习惯匹配（有异地/双份的情况下才考虑删本地，否则宁可在服务器端多存一份）。
# 手机端登录地址就是你的 Immich 服务对外域名，例如：
# https://photos.example.com （前面加 Caddy/Traefik 反代 + 自动 HTTPS）
# Web 端登录后可以按相册/时间轴直接管理、分享、下载
做对的另一个重点是"入口加密"。Immich 里存的是你全家最私密的照片，绝不能把 2283 裸开公网。标准做法和前面几篇一致：前面加反代 + 自动 HTTPS + 强口令/2FA，或者走 Tailscale/WireGuard 私密网络，让手机端通过专网访问。记住一个判断：越私密的数据，越不该为"图省事"去裸端口。
四、智能识别与搜索：熟人脸聚类的"花与留"
Immich 的智能搜索令人心动，但要先认识它的成本：人脸识别、物体/场景识别靠的是自带的机器学习模型，会在服务器上吃不少 CPU/内存（识别是批次任务，通常是"上传后后台慢慢算"，不是每张照片都实时高负载）。正因为这样，很多自托管版会用"要不要装 ML"和"识别放在哪台机器"来做取舍——小型服务器可以不开人脸识别，只保留按时间/相册的手动整理，也完全够用。
# 想用人脸/对象识别，通常需在 compose 里启用 ml 服务并在 Web 后台开启识别
# 感知上：首次扫描极大库会很耗资源，可关闭或安排在低峰再开启
务实建议有三条：一是按你的硬件决定开不开识别——硬件够就开智能搜索让体验接近商业版，不够就宁愿关掉保稳定；二是把"识别建议/人脸命名"当成一种渐进整理，而不是一次性的完美聚类；三是明白识别数据其实只是"索引"（真正照片仍在你的存储目录），出问题重算即可。先接受"识别是可选加分项、不是必需项"，再决定投入多少资源。
五、必须正视的边界：它不是"塞完就不管"的东西
把 Immich 养稳，要认清几层现实。第一层是"存储重量"：照片视频是超大且只增不减的数据，设计它的第一原则是"别把照片放系统盘、要放可扩展且防坏的数据盘"，并做好磁盘监控与扩容计划；同时要防坏盘，靠的是"再存一份/RAID/异地"，而不是每次都全量备份。第二层是"数据库"：Immich 的索引和元数据都在 PostgreSQL 里，它自己也要备份——同步命令让你备份照片，数据库备份才能让你还原相册时间轴和能搜索的元数据，所以"备份 Immich"=照片目录 + 数据库 + 配置三件一起。
第三层是"新旧更替的现实"：Immich 迭代很快、偶尔会有需要跟随升级的版本与数据库迁移，别把它当"装完就冻结"的系统，升级前要看变更、对数据库做可回滚的快照。把这些"它也是你服务器上的重量常驻服务、要纳入监控与备份"的常识做到，Immich 才能长期安定地当一个私密、可控、属于你自己的照片管理中枢。
结语
Immich 的价值，是把"手机照片自动备份 + 私有云相册式管理"的能力整条搬回你自己的服务器：手机持续静默备份、服务器端获得时间轴/相册/分享与可选的智能搜索，数据与识别都握在自己手里。落地要点：用 compose 起整套服务并把照片目录、数据库、ML 三件事分派好；手机端开"Wi-Fi 后台自动备份"并让入口走反代 + HTTPS 或私密网络，绝不裸开端口；智能识别是按硬件取舍的可选加分项；把它纳入"照片 + 数据库 + 配置"的完整备份与磁盘监控。当你把这几层边界正视好，Immich 就从"一个能传照片的工具"变成一套长期、私密、可控、可搜索的私人照片与视频档案馆。
