玩NAS这几年一个现实问题躲不掉——空间总是不够用。手机相册照片动辄5-10MB群晖里照片加文档加视频几T的空间说满就满。我一开始想用在线压缩工具把大图压一遍结果发现要么得上传原图到别人服务器要么压缩质量不可控。后来看到Google开源的Squoosh研究了一阵子干脆把它部署到群晖上当作一个随时可用的图片压缩Web工具。这篇就把完整的部署思路、操作细节和踩坑经历写出来给同样在NAS里堆了很多图片的朋友做个参考。1. 为什么是Squoosh本地隐私与压缩效率的平衡点1.1 图片体积问题与NAS玩家的共同痛点NAS玩家的图片痛点通常不是“存不下”而是“存了之后再也没有打开的欲望”。手机原图、相机RAW、从微信群导出的截图、网页保存的长图这些文件散落在不同目录体积还在逐年膨胀。群晖自带的Synology Photos会生成缩略图用于浏览但原始文件一点没变小。备份层面如果还做了异地同步或者外接硬盘冷备意味着同一张原图要占两到三份空间容量压力直接翻倍。压缩图片是性价比很高的整理方式。不需要删照片不需要重新拍照图库体积能砍掉一大半。问题在于用什么工具做这件事。之前我试过几类工具。TinyPNG这类在线工具操作简单但我手上的图有一些是客户资料、有一些是个人证件扫描件我其实不太愿意把原始文件传到第三方服务器上。免费版还有单张5MB限制对相机原图完全不适用。本地看图软件自带的导出压缩功能要么参数不可调要么只支持JPEG换到WebP、AVIF这种现代格式就得另外找工具。1.2 Squoosh与传统在线压缩工具的本质区别Squoosh是Google Chrome实验室开源的一个图片压缩Web应用最初以在线网页的形式出现。它最大的特点是压缩过程完全在浏览器本地完成利用WebAssembly运行MozJPEG、OxiPNG、WebP、AVIF等编码器原图不会上传到任何服务器。这一特性放在NAS场景里价值非常高。我把Squoosh部署在群晖上之后它就是一个内网工具所有图片数据只在我自己的设备和NAS之间流转不会出局域网。对隐私敏感的图用这个方案省心很多。另外一个容易忽略的点是Squoosh作为纯前端应用它的计算引擎跑在客户端浏览器里NAS本身只负责托管网页和把文件发给浏览器。这意味着压缩大图的压力主要在你的电脑CPU上并不会把群晖拖成高负载。这和“在NAS上用ffmpeg转码”是两种截然不同的工作模式。1.3 为什么我最终选了Squoosh而不是TinyPNG或ImageOptim我用过的工具不算少最终留下Squoosh核心原因是它兼顾了参数自由度和隐私安全。从群晖玩家的角度我梳理过四个候选方案的差异方案是否上传感服务器参数可调性批量处理内网可用部署成本TinyPNG在线版是低需要分开多次操作否无ImageOptim本地软件否低强否需安装客户端Squoosh在线版否高支持批量否无Squoosh自托管否高支持批量是低ImageOptim在Mac上很好用但它只解决单机问题我要处理图片时还得跑去找那台装了软件的设备。Squoosh自托管之后家里任何一台电脑、平板甚至手机打开浏览器就能用入口统一。而且Squoosh对AVIF的支持很成熟ImageOptim对AVIF的覆盖并不完整。如果你纠结“部署它会不会很麻烦”可以打消顾虑。Squoosh本质是一个静态网站Docker里跑一个Web容器而已资源占用极低配置也几乎没有。2. 部署Squoosh之前群晖Docker环境有几句要提前说清2.1 DSM版本与Container Manager的对应关系群晖的Docker环境这几年的变化很容易让人踩坑。DSM 7.2及以上版本套件中心里的套件叫“Container Manager”它把镜像管理、容器运行、Compose项目整合到了一起。DSM 7.0到7.1时期套件名字还是“Docker”功能界面相对简陋。更早的DSM 6.x虽然有第三方Docker套件但不建议再用了安全和兼容性都跟不上。我建议部署前先看一眼你的DSM版本。如果你还在DSM 7.1或更早要么升级DSM到7.2要么直接用SSH加docker-compose命令行操作起来反而比图形界面顺手。考虑到Squoosh这种应用生命周期比较长一次性配置好之后很少动它用哪个版本的系统都不影响最终效果但Container Manager图形界面查日志、看容器状态明显省事。2.2 镜像拉取失败先确认这个问题再动手群晖部署Docker应用最常见的失败场景不是容器配置错了而是镜像根本没拉下来。Container Manager里搜索Squoosh的社区镜像时很多人会遇到进度条卡住或直接提示下载失败。这个时候不要慌有两个可用思路第一个是给Container Manager配置镜像加速地址。打开Container Manager的“设置-注册表-编辑”可以添加registry mirror。具体填哪个地址不同网络环境效果差异很大我试下来的经验是填一个近一点的公开镜像站多试几个总有一个快的。这个操作不改变你的使用习惯只是让拉取过程更顺。第二个思路是在网络条件好的电脑上把镜像打包成tar文件之后再到群晖的Container Manager里“容器-导入”加载。这个方案适合一次部署完毕后续更新再重复一遍也不算麻烦。两种办法我都用过图省心的话优先试第一种。2.3 端口规划与目录结构预安排Squoosh容器默认会暴露一个HTTP端口但不同社区镜像用的端口不一致有的是80有的是8080。部署之前我先在局域网里选了一个不常用的端口比如8089专门映射给Squoosh用。这样做有两个好处一是避免和群晖Web、Synology Photos等常用端口撞车二是以后和其他Docker应用区分清晰。这里有一个很容易被误解的点很多人部署Squoosh时想着把NAS里的某个共享文件夹挂载到容器里让压缩结果直接写进NAS目录。实际上Squoosh是个纯前端应用它不会去扫描容器内的文件也不会自动读取挂载目录里的图。你通过浏览器拖进去的图片处理完是在浏览器里下载的和容器文件系统没有直接关系。所以目录结构安排的重点不是给容器挂卷而是给压缩产物规划一个存储位置。我是在群晖里建了一个/photo_compressed共享文件夹浏览器下载完压缩图之后统一归档到这里后续再做整理。如果你想直接在NAS上批处理现有目录里的图片需要用到Squoosh的CLI工具这是第5章的内容。3. 正式部署用Container Manager跑起Squoosh容器3.1 获取镜像的两种途径社区镜像与源码自构建Squoosh官方仓库没有维护官方Docker镜像所以需要借助社区方案。我在Docker Hub上搜索squoosh找到过不止一个镜像维护频繁程度和端口定义不太一样。用社区镜像之前建议看一眼镜像描述确认基于哪个版本的Squoosh端口是80还是8080。如果不想用第三方镜像也可以自己构建。Squoosh本体是一个静态前端项目把编译产物放到任意Web服务器里就能跑。在群晖上自构建稍麻烦一些需要先用开发者环境把前端代码打包再把静态文件扔进nginx容器。除非你有定制需求否则社区镜像完全够用。我最终用的是社区镜像zzadm/squoosh拉取顺利容器端口80映射到本地8089。这里不展开了直接用的默认配置。3.2 用Container Manager图形界面创建容器如果你习惯用图形界面整个流程可以控制在几分钟内。在Container Manager里依次操作打开“注册表”选项卡搜索“squoosh”选择一个镜像点击下载。等待镜像拉取完成进入“映像”选项卡选中镜像点击“启动”。设置容器名称一般叫squoosh即可。端口设置本地端口填8089容器端口根据镜像说明填我的镜像填的就是80。存储空间和环境变量都不需要额外配置除非你想限制内存。资源设置建议打开“限制内存”给个512MB或1GB就够防止以后批量处理时内存占用失控。点击“应用”并启动容器。启动之后用同一局域网里的任意设备访问http://群晖IP:8089看到Squoosh的界面就说明部署成功了。这里提醒一句如果打不开先别急着改配置先确认群晖IP是否填对、端口映射是否真的生效、容器状态是不是running。3.3 用docker-compose.yml实现一遍更推荐的方式图形界面配置虽然直观但没有版本管理以后想复制到别的设备又要重新点一遍。我更推荐用Compose文件来定义整个服务。在群晖的Container Manager里打开“项目-新建项目”名称填squoosh路径选一个专门存放Compose文件的文件夹然后把下面内容粘贴进去services: squoosh: image: zzadm/squoosh:latest container_name: squoosh ports: - 8089:80 restart: unless-stopped mem_limit: 1g创建之后Container Manager会自动拉取镜像并启动容器。这种方式的优势是后面想升级镜像只需要编辑YAML文件或者在项目里选择“操作-重建”一条链路清晰可复现。restart: unless-stopped确保群晖重启后容器自动恢复NAS场景下非常需要这句。3.4 验证容器状态和页面可访问性部署完不要只看图形界面的绿色对勾建议动手验证两层。第一层是容器视角进入Container Manager的“容器”页面确认容器运行状态是“运行中”点开“日志”没有报错。第二层是应用视角用无痕窗口访问地址防止浏览器缓存影响判断。如果访问后出现白屏大概率是浏览器兼容性问题换Chrome或Edge的较新版本再试。Squoosh依赖现代WebAssembly能力老内核浏览器跑不起来。4. 上手用Squoosh从单张压缩到批量转换性能实测4.1 界面布局、核心参数和它们背后的含义Squoosh界面走的是极简路线左侧是原图右侧是压缩后的预览中间有一个可拖动的分割条可以直观对比压缩前后的视觉差异。图片拖进页面后右侧面板会显示编码器选择列表和质量参数。编码器选型是使用Squoosh最关键的环节MozJPEG适合输出高质量JPEG兼容性最好适合做老设备的通用图。OxiPNG主要针对PNG优化适合带透明通道的截图和UI素材。WebP兼顾体积和画质绝大多数现代用途都能胜任。AVIF压缩率最高但编码速度慢且部分旧浏览器不识别。质量参数也不是越高越好。我日常处理网页配图和博客插图WebP质量75到80已经足够肉眼几乎看不出和原图的差距。再往上提质量体积降幅就不明显了激进压到60以下画质损失在暗部和纹理区域会变得明显。4.2 批量处理的实际操作路径群晖上跑Squoosh处理多张图时不需要一张一张设置。一次性把多张图片拖进窗口界面右上角会出现批量处理入口。先在任意一张图的设置里调好编码器、质量和缩放参数再应用到全部图片最后统一下载。批量下载默认打包成ZIP这个压缩包会保存到你电脑的下载目录。我的习惯是下载完成后把ZIP解压到群晖共享文件夹里顺便按日期建子目录比如/photo_compressed/2025-06/。这一步虽然手动但在容器方案里无法绕开。如果你的批量需求很大更省力的路线是直接用CLI工具这部分在第5章展开。4.3 性能实测浏览器端编码与NAS负载的真实关系我之前提到过Squoosh的计算发生在浏览器里所以压图速度取决于访问网页那台设备的CPU。我在家里台式机上把一张12MB的JPG压成WebP质量80大概用了3秒左右换成AVIF质量60耗时明显变长在15秒上下。压缩期间群晖CPU基本没有明显波动内存占用也很平稳NAS本身只是做了一回静态页面托管。那是不是说群晖性能无关紧要也不完全是。虽然编码不占NAS的CPU但群晖的网络吞吐、浏览器端从NAS读取大图的速度会影响整体体验。如果你的NAS是几年前的入门机型网卡只有千兆加载几十MB的原图到浏览器时会感受到明显的等待。所以我把Squoosh容器放在机内SSD缓存路径上图片从SSD读到浏览器比从机械硬盘快不少。4.4 压缩效果对照以我手头一张12MB样张为例为了让参数选择更有参考性我用一张4800万像素的手机原图做过一个简单对照实验原图是12.8MB的JPEG细节较多的那种输出格式与参数输出体积与原图相比主观画质原图 JPEG12.8MB--MozJPEG质量804.6MB节省约64%几乎无差别WebP质量802.3MB节省约82%几乎无差别WebP质量701.7MB节省约87%仔细看略有损失AVIF质量601.1MB节省约91%正常浏览不可感知这个结果说明什么如果你的图片要发给别人JPEG兼容性最稳如果只是自己归档或放网页用WebP性价比最高追求极致体积而且不急着用AVIF值得等。屏幕截图类素材由于颜色平滑压缩率往往比照片还高我压过一份8MB的截图转成WebP后只剩900KB。5. 把Squoosh嵌入NAS工作流反向代理、接口调用与自动化5.1 用群晖反向代理把Squoosh接入域名和HTTPS内网访问Squoosh已经够用但节假日在外网时偶尔也会想处理一张临时图片。如果只是单张图、敏感度低可以直接用DSM自带的QuickConnect或DDNS配合反向代理把这个网页工具暴露到公网。群晖提供的反向代理入口在“控制面板-登录门户-高级-反向代理”。新建一条规则来源协议选HTTPS来源主机名填你的DDNS域名来源端口填443目的地协议选HTTP目的地主机名填localhost目的地端口填8089。这样访问https://你的域名就会自动转发到本机Squoosh容器。证书方面可以在“控制面板-安全性-证书”里新增Lets Encrypt证书为这个域名签发并自动续期。做完这一步就能用HTTPS加密通道访问Squoosh了。不过我必须提醒一句Squoosh本身没有任何身份认证机制任何拿到你访问地址的人都能打开它上传图片并下载结果。所以我个人只在完全信任的私密网络里才开这个端口公网访问要么加前置鉴权要么干脆不开。5.2 开发者视角用squoosh/cli跑NAS目录里的批处理网页版Squoosh不读NAS目录这算是我绕了一圈之后察觉到的边界。如果你需要直接压缩NAS里某个文件夹的图片正确方式是脱离浏览器用Squoosh命令行工具。在群晖上安装Node.js套件中心里有Node.js的高级套件装18或20版本然后执行npm install -g squoosh/cli安装完成后在图片所在目录运行压缩命令。比如把当前目录所有JPG统一缩放到最长边1920并以WebP质量75输出到out目录squoosh-cli --webp {quality:75} --resize {width:1920} --output-dir ./out ./*.jpg这个命令会遍历当前目录的JPG文件输出WebP压缩图。之后再配合群晖的“任务计划”设定每天凌晨自动跑一次把指定目录里的新图片批量压缩到另一个目录。这算是一个比较完整的自动化闭环适合图库持续快速增长的重度用户。不想在NAS上装Node.js的话也可以在自己的电脑上装好CLI再通过SMB或者WebDAV把群晖文件夹挂载成网络盘直接在电脑上批量跑。效果一致只是执行环境不同。5.3 与Synology Photos、Drive的联动思路家庭用户经常想的是“群晖里的照片能不能自动压缩”。这里有个容易踩的坑Synology Photos的缩略图机制和Squoosh压缩完全是两回事。Photos会在后台生成缩略图用于浏览原始文件仍然原封不动存放在Photo目录里不会凭空变小。所以我的联动思路是明确区分“原图库”和“压缩图库”。原图保留在Synology Photos默认的Photo目录里用于长期归档和随时取用原图压缩图统一输出到photo_compressed共享文件夹用于外部网盘同步、微信分享、博客配图等不需要高分辨率的场景。两个目录不做自动合并避免误删原图。如果开启了Synology Drive同步还可以只把photo_compressed目录设为Drive的同步根目录这样手机端始终只看到压缩后的版本省流量也省手机空间。6. 踩坑记录与防火墙细节一次典型排查就够了6.1 打不开页面时的完整排查链路第一次在群晖里部署Squoosh时我遇到过一个很典型的情况容器显示运行中但浏览器访问一直转圈。当时我从上到下排查发现了一个容易忽略的层级问题。最优先排查的是容器状态。进入Container Manager看日志如果有端口绑定错误日志里会直接报bind: address already in use。这通常意味着本地8089端口被占用了可能是另一个容器占的也可能是群晖系统服务占的。解决办法是换一个高位端口比如8091重新映射。容器没问题再看群晖防火墙。控制面板-安全性-防火墙里如果启用了防火墙规则新端口默认不会放行需要手动添加入站规则。我当时没开群晖自带的防火墙直接跳过了这一层绕着绕去反而不顺利。最后才是路由器转发。如果你试图从外网访问需要在路由器管理页面做端口转发把公网某端口转发到群晖的8089端口。这一步和群晖本身关系不大但很多文章不会提醒你。6.2 大图处理时的内存和浏览器压力Squoosh的计算在浏览器端十几张二十几MB的原图同时拖进页面浏览器标签页很容易内存飙高甚至白屏。我在批处理大量图片时遇到过两次浏览器标签页崩溃没有造成NAS数据损失但处理到一半的进度全没了。这个问题的解决办法不是换NAS而是分批操作。每批拖入的图片控制在8到10张处理完下载、清空页面再拖下一批。如果你用手机浏览器操作建议更保守一些手机内存远不如桌面机宽裕。如果跑的是CLI批处理压力会转移到NAS的CPU和内存上。群晖入门机型如果只有2GB内存跑大批量AVIF编码时可能触发OOM容器会被杀掉。这时候在Compose文件里调低并发度或者给CLI命令加更小的批处理范围等任务跑完再继续下一批。6.3 容器更新与压缩产物的长期归档习惯Squoosh这个项目虽然不算高频更新但偶尔会有编码器层面的改进。更新容器的方法很简单在Container Manager里拉取最新的镜像停止旧容器重建即可。因为Squoosh无状态、不写数据更新几乎不会影响已有的任何配置。真正需要注意的反而是压缩产物的归档习惯。我踩过的一个坑是有一次压缩图片时直接用原文件名覆盖了原图几个月后想找一张高清原图做印刷才发现已经找不回来了。所以我的规则是任何压缩操作都保留原图压缩文件命名加_web或_compressed后缀和原图严格区分。群晖的回收站功能可以临时兜底但绝不能依赖它。归档目录我会定期用Synology Hyper Backup把photo_compressed备份到异地这样即使主存储出问题压缩图也不会全部丢失。原图本身还是按3-2-1原则备份一份离线副本做到这一步图库整理才算真正闭环。回到开头那个问题随着家庭NAS里的图片越堆越多“存储焦虑”几乎所有人都会遇到。我的体会是与其无脑加硬盘不如把用了很久的高清图按用途分级处理原图备份最稳妥日常查看和分享的版本压缩后使用。Squoosh在群晖上跑起来之后整个压缩流程快则几分钟、慢则一个晚上批量跑完成本很低收益却能持续很多年。如果你想把这套工具也纳入自己的NAS工作流建议先从一张图开始试跑明白之后再进入批量阶段耐心一点收获会比想象的大。