自建相册选 Immich、Nextcloud 还是 PhotoPrism？我拿 8 万张照片跑了 90 天，附 Docker 参数和踩坑

先说结论，省得你翻到最后：如果你是 iPhone/Android 手机相册接管，选 Immich；如果你已经有 Nextcloud 在跑文件同步，照片少于 2 万张，装 Memories 就够；如果你有 10 万张老照片、RAW、想按内容搜图，PhotoPrism 可以当桌面整理工具。别信“一个开源软件全包”的鬼话，我 2024 年 2 月退掉 iCloud 2TB，把 8 万张照片、220GB 视频迁到家里，最后发现崩溃点根本不是人脸识别。 我机器不是高配：Intel N100 迷你主机，16GB DDR5，512GB NVMe 系统盘，2 块 4TB 西数紫盘组 ZFS mirror，可用 3.6TB。系统 Debian 12，Docker 24.0.7，Compose v2.24.5。照片原始库放 /mnt/photos，按 2024/2024-05-01_IMG_1234.HEIC 这种结构，应用只读挂载。 为什么强调只读？因为我第一次把 Immich 上传目录当唯一副本，结果升级 v1.106.4 到后面版本时数据库迁移卡住，我差点以为照片没了。后来改成“存储层独立、索引层可重建”，心里才踏实。

硬件和目录这块，我建议先定三个数：照片总量、视频总量、家人手机数量。我的数是 8 万张照片、约 220GB 视频、4 台手机。N100 跑 Immich 的 PostgreSQL + Redis + 机器学习容器，16GB 内存是底线，平时占用 9-11GB。如果你要同时跑 Nextcloud、Jellyfin、qBittorrent，32GB 更稳。ZFS mirror 我设 recordsize=1M，照片小文件多，压缩用 lz4，实际照片目录压缩比只有 1.02，别指望省空间。 系统盘我只放 Docker 和数据库，/srv/docker/immich/pgdata 大概 12GB，缩略图 38GB，视频转码另算。这里有个坑：Immich 用 PostgreSQL + pgvecto.rs，不是 MariaDB。你拿 MySQL 硬套，容器能起来，向量搜索会报错。Nextcloud 28.0.5 用 MariaDB 10.11 没问题，PhotoPrism 240531 我一开始用 SQLite，8 万张索引到 4 万就卡死，换 MariaDB 才过。 目录权限别用 root 一把梭。我建了 photos 用户，uid 1000，应用容器里 PUID=1000、PGID=1000。外接库路径 /mnt/photos，Immich 里填 /mnt/photos，只读。这样应用删不掉原图，最多删索引。

Immich 部署我用的 Compose，关键参数就这些：IMMICH_VERSION=v1.106.4，UPLOAD_LOCATION=/srv/immich/upload，DB_DATA_LOCATION=/srv/docker/immich/pgdata，DB_USERNAME=immich，DB_PASSWORD=自己换，DB_DATABASE_NAME=immich，TZ=Asia/Shanghai，端口 2283。机器学习容器我限制 MACHINE_LEARNING_WORKERS=1，内存给 6GB，因为 N100 核显跑人脸够用，但别开 4 个 worker。 首次外部库扫描 8 万张：扫描元数据 1 小时 40 分，生成缩略图约 19 小时，人脸识别 6 小时 20 分，智能搜索索引 3 小时。不是秒级，但也别用 J4125 硬扛，我试过 J4125 8GB，缩略图跑了两天还没完。手机端 Immich App 我设置：仅 Wi-Fi、充电时备份、排除 Screenshots、保留原图 HEIC。iOS 实况照片会拆成 .HEIC + .MOV，Immich 能显示动态，但导出时注意选“未修改原片”。 升级前一定备份数据库：pg_dumpall -U immich > /backup/immich-$(date +%F).sql。我有一次跳过备份，从 v1.106.4 升到新版本，Postgres 扩展报错，回滚花了 3 小时。这个命令不高级，但能救命。

Nextcloud 28.0.5 + Memories 我也跑了 60 天。它强在文件同步、共享链接、日历、联系人、Office，照片只是其中一块。Memories 索引 8 万张用了 4 小时 10 分，内存峰值 1.8GB，时间线、地图、人脸要装 Recognize，识别 8 万张又跑了 9 小时。问题在手机后台备份：Nextcloud iOS 客户端我备份 2000 张，断了 7 次，Immich 同样网络断了 2 次。 还有路径问题。Nextcloud 照片默认进 data/用户名/files/Photos，路径深，迁移到别的软件要重新整理。共享给家人也麻烦，你要么给账号，要么给公开链接，权限模型比 Immich 的“共享相册”复杂。我的观点：Nextcloud 是“文件宇宙”，照片是文件的一种；Immich 是“相册数据库”，文件只是原料。拿 Nextcloud 硬刚 Google Photos，能用，但别指望省心。

PhotoPrism 240531 我用来整理 2008-2015 年的老照片。它搜索确实强：按地点、颜色、内容、标签，甚至能搜“狗”“海滩”。MariaDB 10.11 下索引 8 万张 3 小时 20 分，数据库 4.2GB。RAW 支持一般，我的佳能 CR2 能看，但富士 RAF 有些缩略图出不来。移动端基本是 PWA，后台自动备份要 Tasker 或快捷指令，iOS 更折腾。 人脸识别它要 TensorFlow，N100 上跑 8 万张约 7 小时，精度我觉得不如 Immich。许可证方面，Immich、Nextcloud、PhotoPrism 都是 AGPL-3.0，Jellyfin 是 GPL-2.0。PhotoPrism 适合桌面大屏浏览和老照片关键词搜索，不适合当全家手机相册的唯一入口。

如果你只想要一张表，我按自己的实测给：

这张表不是让你背，是让你看“写入端”谁负责。手机相册的命门是上传，不是浏览。

踩坑一：EXIF 时区。iPhone 照片 DateTimeOriginal 不带时区，Immich 按 UTC 读，时间线会差 8 小时。我解决：导入前用 exiftool -r -overwrite_original -OffsetTimeOriginal=+08:00 /mnt/photos。跑之前先拿 100 张试，别直接全库。踩坑二：重复。iCloud 导出、微信保存、截图混在一起，我用 jdupes -r -S /mnt/photos > dupes.txt，8 万张查出 3271 个重复，删之前先看硬链接还是副本。踩坑三：HEIC。Immich 保留原图，生成 JPEG 预览；Nextcloud 要装 HEIC 插件，不然浏览器不显示。 踩坑四：实况照片。iOS 导出要选“导出未修改原片”，否则 .MOV 丢，Immich 里动态就没了。踩坑五：视频。N100 转码 4K H.265 很吃力，我在 Immich 里关了视频转码，手机端直接串流，省 CPU。踩坑六：备份。我每天 3:15 跑 pg_dumpall，rsync 到第二台旧 NAS，再用 rclone sync /mnt/photos b2:my-photos --transfers 4 --checkers 8。3-2-1 不是口号，是我真丢过 200 张截图后的教训。

最后说选型。我的全新观点：自托管相册别追求“一个软件全包”，要分成存储层、索引层、接入层。存储层用 ZFS/SMB，索引层用 Immich 或 PhotoPrism，接入层给家人用 Immich App 或 Nextcloud。这样 Immich 崩了，照片还在；Nextcloud 升级炸了，Immich 还能读原库。 如果只选一个：iPhone 用户 + 家人共享 + 想省心，Immich；已有 Nextcloud 且照片少于 2 万，Memories；老照片 10 万+、桌面整理、关键词搜索，PhotoPrism。别用 N100 8GB 跑 8 万张 4K 视频 + 人脸 + OCR，16GB 是底线，32GB 更稳。 我最后留在 Immich，但原始库永远独立，应用只做索引。它是不是完美？不是。共享相册权限、重复检测、中文搜索还有毛病。但至少我退订 iCloud 后，照片没再被“锁”在别人手里。