同样是上传一个5GB大小的文件，Nextcloud用了3分钟，Immich只花了1.5分钟。当我在同一台Ubuntu服务器上分别部署这两个自托管工具后，这种速度上的差距立刻让我意识到，它们背后是完全不同的技术路径——一个用成熟生态覆盖文件协作，一个用流式架构专攻照片视频。

我最初的需求是在ERP生产环境里，给几个协作单元搭建一个共享文件的中心仓库。Nextcloud 27的安装很直接，一条apt install nextcloud命令就在Ubuntu 22.04上自动配好了PHP-FPM和Apache2，所有东西落在/var/www/nextcloud目录里。进管理面板开启“外部存储”插件后，我把NFS和S3都挂载进来，数据实际存放的位置直接指向了一个独立的RAID-10阵列。这个过程让我感受到Nextcloud作为自托管文件同步与共享平台的综合能力：它不仅提供永久的分享链接，还能通过插件把存储层扩展到几乎任何地方。

打开网易新闻 查看精彩图片

另一个场景则完全围绕手机照片流展开。为了给一个以图片为主的内部分享频道做后端，我试着用Docker-Compose拉起Immich。docker-compose.yml里只需定义server、redis、postgres三个服务，几行环境变量指定好数据库用户名密码，端口3001一开，服务就跑起来了。手机端App按下“上传”按钮，照片直接推到server容器里，Redis立刻接管缩略图生成队列，PostgreSQL则稳稳地记录下每条媒体元数据。这种API优先的架构，把“上传-处理-索引”这条流水线拆得很干净，明显是为了让批量媒体操作更顺畅。

那3分钟与1.5分钟的差异就源自这里。我分别用curl -T上传同一个5GB的ISO文件到Nextcloud，和相同大小的视频文件到Immich，前者受限于Apache的mod_proxy_fcgi与php-fpm的链路处理，后者则通过一个HTTP POST端点直接接收流，不做多余的协议转换。Immich背后的服务用Go编写，比Node.js更轻，配合“流导向”的设计，在传输大块二进制数据时几乎没有额外的吞吐损耗。换句话说，Immich把服务器资源优先分配给持续的媒体流，Nextcloud则要在文件版本、权限校验、插件钩子之间做完一整套动作。

存储层的选择逻辑也因此分叉。Nextcloud坚持文件系统方式，我可以直接利用RAID-10或ZFS的优势来保护大量文件，备份和扩展都按文件系统习惯来。Immich则把媒体元数据放进PostgreSQL，照片视频这类大二进制对象仍直接写入磁盘，但元数据与数据库深度绑定，随着库体积增长，备份和复制的成本会明显上升。如果照片库只有几千张，这完全不是问题；但当你面对的是数十万张原图时，数据库膨胀就成了必须提前考虑的因素。

综合来看，Nextcloud是一个覆盖面极广的自托管文件协作中心，外部存储插件和成熟的链接分享让它适合作为团队共享盘的大脑；Immich则把力气全部花在移动端照片视频的快速吞吐和自动标签上，适合那些“拿来就用、只想管好媒体流”的场景。两者并不是直接替代关系，而是看你最频繁的动作，是给同事分发一批设计稿和合同，还是让手机上几百张连拍在几秒内安静地同步到自己的服务器里。