Cloudflare免费部署图片压缩转换网站，本地处理无需上传

前言

异地办公的人应该都遇到过这种尴尬：手头只有一台没装 PS 的电脑，客户或同事甩来一张图片，要么太大传不上去，要么格式不对打不开。临时去网上找一个在线压缩工具吧，又总担心图被传上别人的服务器——尤其现在"万物皆可喂给 AI 训练"，谁都不想把自己的合同扫描件、证件照丢给一个来路不明的网站。

我自己也纠结了很久，最后干脆花点时间部署一个属于自己的图片工具。它把日常最常用的两个功能——压缩和格式转换——集成在了一个页面上，而且关键的一点是：所有处理都在浏览器本地完成，图片根本不会上传到任何服务器。既解决了功能需求，又堵住了隐私这块的顾虑，一举两得。

本文就把整个部署过程拆开讲清楚，你照着做，10 分钟也能拥有一套自己的在线图片工具。

这工具能干什么

在动手之前，先花两分钟搞清楚它到底解决了什么问题，免得白部署：

图片压缩：调整压缩质量档位，把大图压小，适合用来处理"传不上去"的照片、截图。
格式转换：在常见图片格式之间互转，比如 PNG 转 JPG、把不兼容的 WebP 转成通用格式，方便在不同软件里打开。
本地处理：所有转换在浏览器内完成，图片不上传服务器，隐私有保障——这是它跟在线网站最大的区别。
拖放即用：操作门槛低，把图片拖进页面就能开始，不需要学复杂的工具。

下面是工具的主界面效果（示意图）：拖放区 + 压缩质量 + 格式转换面板一目了然。

你可以先访问我部署好的实例感受一下：https://img.1day.vip/，觉得合适再自己部署一套。

部署前需要准备什么

开始之前，先确认你已经具备以下条件，缺哪样补哪样，避免中途卡壳：

一个 GitHub 账号：用来 fork 项目仓库。
一个 Cloudflare 账号：免费版即可，用它的 Workers 服务来部署。如果你还没注册，用邮箱就能搞定。
一个已经托管在 Cloudflare 的域名（可选但推荐）：用来绑定自定义访问地址。没有域名也能部署，只是会拿到一个 *.workers.dev 的临时子域名，不够美观、也不方便记忆。

我的域名绑定在 Cloudflare 上，所以下面第 4 步能直接用它的域名管理。如果你的域名在其他服务商，也可以，绑定逻辑类似，只是要回原服务商解析。

详细部署步骤

整体流程是：Fork 项目 → 在 Cloudflare Workers 里导入 → 配置构建命令 → 部署 → 绑定自定义域名。下面一步步来。

第 1 步：Fork 项目到自己的仓库

项目作者的开源地址在 GitHub，你需要先把它复制一份到自己账号下，才能在 Cloudflare 里关联部署。

打开项目地址：https://github.com/haihaipypy/image-tools（这是我整理过的版本，去掉了原项目的广告）。
点页面右上角的 Fork 按钮。
保持默认设置，点 Create fork，等它复制完成。

Fork 之后，这个仓库就属于你了，后面 Cloudflare 部署时关联的是你自己的这份。

第 2 步：进入 Cloudflare Workers 并创建项目

登录 Cloudflare 控制台，左侧菜单进入 Workers & Pages。
点 Create application，然后选 Workers 这一项（注意不是 Pages）。
给它起个名字，比如 image-tools，点 Deploy 先创建一个空项目。

小提示：你 fork 的项目文件会在下一步通过 Git 关联导入到这个空 Worker 里。

第 3 步：从 GitHub 导入项目

进入刚建好的 Worker 项目详情页。
找到 Settings → Git 或者项目内的 Deployments 相关入口，选择从 GitHub 仓库导入（Workers 现已支持直接关联 GitHub 仓库自动部署）。
授权 Cloudflare 读取你的 GitHub，然后选中第 1 步 fork 出来的 image-tools 仓库。

提示：如果你在 Workers 界面里没找到"关联 Git"的入口，也可以退而求其次，用 Quick Edit 的方式把项目文件传上去，或者走 Pages 的 Git 集成。核心思路不变——把你 fork 的代码部署到 Cloudflare。

下面是我在 Cloudflare Workers 里导入项目时的界面示意：

第 4 步：填写构建配置

这个项目是前端静态站，需要一条构建命令把源码打包成可直接访问的静态文件。在构建配置里这样填：

构建命令（Build command）：npm run build
输出目录（Output directory）：dist

填完保存，Cloudflare 会自动开始拉取代码并构建。

第 5 步：部署并等待完成

配置好之后，触发部署。Cloudflare 会去拉你的仓库、安装依赖、执行 npm run build，然后把 dist 目录里的静态文件发布出去。整个过程通常几分钟内完成，可以在部署日志里看到进度。

部署成功后，会生成一个默认的访问地址（形如 https://image-tools.你的子域.workers.dev），点开先验证一下能不能正常加载页面。

第 6 步：绑定自定义域名（推荐）

workers.dev 的临时地址不太方便，建议绑定你自己的域名，比如我就绑成了 img.1day.vip。

在 Worker 详情页找到 Settings → Domains & Routes。
点 Add，输入你想用的子域名，比如 img.你的域名.com。
如果域名就在 Cloudflare 托管，Cloudflare 会提示自动创建一条 DNS 记录并自动配置 HTTPS 证书，你只需要点确认。
等证书生效（通常几分钟到几十分钟），就可以通过自定义域名访问了。

怎么使用

部署完就能上手了，操作非常轻量：

打开工具页面，把要处理的图片拖进拖放区（或点击选择本地文件）。
在右侧面板里选压缩质量（低 / 中 / 高）和目标格式（如 JPG / PNG / WebP）。
点开始处理，页面会直接在浏览器本地完成压缩/转换，然后下载结果。

整个过程不经过任何服务器，图片不会上传，这也是这套工具最让人放心的一点。下面是我实际使用时的界面效果：

怎么验证部署成功了

部署完别急着走，花一分钟确认它真的能用：

用自定义域名（或默认域名）打开页面，能正常显示工具界面，说明部署基本成功。
随便拖一张图片进页面，确认能正常识别、能调整压缩质量和格式。
试一次格式转换（比如 PNG 转 JPG），看输出文件能否正常下载。

如果以上都正常，那你这套图片工具就正式上线了。

实测效果

工具到底有没有用，压缩效率是关键。我拿自己常用的几张图实际跑了一遍，压缩效果非常直观——下图的对比逻辑可以给你一个参考：

实际使用中，压缩率会受图片内容影响，这里给一个我自己的参考区间：

文字 / 纯色为主的截图：压缩效果最理想，往往能压掉 80% 以上的体积，画质几乎无损。这类图很适合压完再传到微信、上传到对体积敏感的平台。
照片 / 细节丰富的图片：压缩率相对低一些，需要把质量档位调高一点，避免在暗部或渐变处出现噪点。

具体能压多少，和原图分辨率、色彩复杂程度强相关。建议你拿自己常用的图实测一次，找到最顺手的质量档位。

常见问题与排错

部署和使用过程中，最容易遇到这几个问题，提前给你排掉：

1. 页面能打开但拖图片没反应

多半是浏览器的问题，换 Chrome / Edge 最新版试试。
也检查一下是否用了过旧的浏览器，这个工具依赖较新的前端特性。

2. 部署日志报构建失败

常见原因是构建命令或输出目录填错。回到第 4 步核对，build 命令输出目录确实是 dist。
如果报依赖安装失败，通常是网络问题，重试一次部署即可。

3. 自定义域名打不开

先确认 DNS 记录是否指向了正确目标、记录类型是否选对。
再确认 HTTPS 证书是否已生效——刚绑定域名时证书可能还在签发中，等一会儿再访问。
实在不行，先用默认的 workers.dev 地址访问，排除域名问题。

4. 担心原项目有广告/后门

这个版本的仓库我已经剔除广告并整理过，代码是开源可查的。你也可以自己 review 一遍源码再部署，更放心。

这个版本改了什么

这里交代一下背景。这个项目改自开源的 image-kixtools，原作者做了汉化，但在页面里加了广告。我使用起来不太舒服，就自己把广告剔除、重新整理后上传了一版，部署起来更干净。你在 Fork 时用到的就是我整理过的这份仓库。

如果你想要最原始的版本，也可以去搜 image-kixtools 自己对比。

我的结论

整体用下来，我觉得这套方案是异地办公 / 经常处理图片但不想装重软件的人一个很省心的选择。优点很明确：

隐私安全：图片本地处理不上传，比任何在线工具都让人放心。
免费：Cloudflare Workers 免费额度足够个人使用，域名也能用免费方案。
即开即用：不用装 PS、不用学专业软件，拖一张图进去就能干活。

要说不足，主要是功能相对聚焦——它擅长的是压缩和格式转换这种高频轻量需求，复杂的修图、调色还是得靠专业软件。但正因为"小而专"，日常用起来反而没负担。

如果你也经常被"图片传不上去 / 格式打不开"困扰，又不放心把图交给第三方网站，不妨照上面的步骤部署一套，10 分钟换一个永远属于自己的图片工具。