用EdgeOne Pages搭建支持外链的免费相册

前言

GitHub + Cloudflare 的免费图床/相册项目其实不少，但国内访问 GitHub Pages 或 CF 的边缘节点总感觉很慢，加载图片经常转圈。刚好看到一个用 EdgeOne Pages 搭建的免费相册项目——EdgeOne 是腾讯云的国际 CDN/边缘平台，国内节点访问速度比 GitHub/CF 稳定得多，很适合用来托管图片相册。

原作者是把项目放在 Gitee 上的，我把它搬到 GitHub 上一份，两边都能用：

• Gitee 地址：https://gitee.com/software-ave/photo-album

• GitHub 地址：https://github.com/haihaipypy/photo-album

这套思路是：把图片放到 GitHub/Gitee 仓库，用 EdgeOne Pages 把它渲染成一个带相册界面的网站，每张图都有独立 URL，可以直接拿来当外链用（配博客、发文档都能引用），全程免费。

先搞清楚"快"是从哪来的

很多人第一次用会觉得"这不就是 GitHub Pages 吗，为什么更快"——差别其实在分发环节。

这套方案里有两个独立的环节：

关键在于第二环。图片最终是由 EdgeOne 的边缘节点分发的，而不是从 GitHub 服务器上取——所以访客打开图片快不快，取决于 EdgeOne 的节点分布和线路，和你把仓库放在 GitHub 还是 Gitee 关系不大。这也是它相比"GitHub Pages 直接托管"、"GitHub 仓库里的图片直链"最实质的优势。

顺带一个结论：仓库放 GitHub 还是 Gitee，影响的只是你自己的构建体验（Gitee 在国内 push 更快），不影响访客看图的速度。所以选哪个都行，怎么顺手怎么来。

部署

1. 打开项目地址并 Fork 这个项目到自己的账号下。

2. 打开 EdgeOne Pages 控制台（Makers 选项卡）：https://console.tencentcloud.com/edgeone/pages

3. 创建项目，选择"导入 Git 仓库"，选中你克隆的那个项目。

4. 预览会先生成一个临时链接，打开链接能看到页面就说明项目部署成功了。接下来就可以给它绑定一个自定义域名，替换掉难记的临时地址。

5. 回到你的域名服务商那里，添加一条 CNAME 记录指向 EdgeOne 分配的地址。这一步 EdgeOne 还不能像 Cloudflare 那样自动添加 DNS 记录，需要手动去域名服务商配置，略麻烦但也不难。

6. CNAME 生效后再回来配置 SSL 证书（EdgeOne 可申请免费证书），让相册走 HTTPS。

第 5、6 步的顺序千万别颠倒——这是整个部署流程里最容易卡住人的地方。

SSL 证书的签发方式是：证书平台去验证"你确实控制着这个域名"，最常用的验证手段就是去 DNS 里查那条 CNAME/A 记录、或者直接访问该域名。如果你还没配好 CNAME 就先去申请证书，验证必然失败（表现为"签发超时""域名验证不通过"），你会以为是自己哪里填错了，其实只是顺序反了。

正确顺序：先配 CNAME → 等 DNS 生效（可以用 nslookup 或在线 DNS 检测工具确认）→ 再申请证书。DNS 生效通常几分钟到几十分钟，取决于服务商和 TTL 设置。

使用

1. 打开绑定好的自定义域名，正常访问相册首页。

2. 添加相册的方式是放文件：在仓库的 public/albums/ 目录下，按日期格式创建相册文件夹，并把图片放进去，例如：

public/
└── albums/
    ├── 2024-05-20-vacation/
    │   ├── photo1.jpg
    │   └── photo2.jpg
    ├── 2024-06-15-family/
    │   └── family.jpg
    └── ...

放好后 push 到仓库，EdgeOne Pages 会自动重新构建部署，新的相册就会出现。

3. 点击某个相册、某张图，即可获取该图片的直链 URL，用来做外链分享或嵌入博客。

命名规范值得花点心思，因为文件夹名和文件名会直接影响你的外链 URL。项目用的是"日期-主题"的文件夹命名（2024-05-20-vacation），建议保持这套习惯并统一用英文/拼音——中文文件夹名虽然也能用，但生成出来的直链会被 URL 编码成一长串 %E4%B8%AD%E6%96%87，既难看又容易在某些编辑器里被截断。上传前把图片文件名也改成有意义的名字（photo1.jpg → jiuzhaigou-lake.jpg），将来找图和做 SEO 都省事。

用 Git 仓库当图床，必须知道的几个限制

这套方案本质是"用 Git 仓库当存储、用 CDN 做分发"。它很好用，但有几条硬限制是仓库这种形态本身带来的，跟项目无关——提前知道，可以省下把仓库塞爆之后再手忙脚乱迁移的麻烦：

1. 仓库体积有上限，而且删了也未必变小。 Git 会记录每一次提交的历史，图片一旦提交，即使后来删除，历史里仍然留着——仓库体积不会因为删图而缩小。所以这个方案适合"精挑细选后上传"，不适合"先传上去再慢慢删"。真到了要瘦身的时候，得用 Git 的历史重写工具，比较麻烦。

2. 每次改动都会触发全量重新构建。 push 一次就重建一次站点。相册图片不多时几秒就好；如果仓库里几百张图，每次改一张图都要等一次完整构建，体感会明显变差。

3. 图片不会自动优化。 你放进去多大，访客就下载多大。这两点直接决定加载速度，所以上传前压缩是必须的：

4. 直链的寿命 = 仓库 + 域名 + 项目的寿命。 这一点最需要留意：图片链接绑定在你的仓库、域名的服务状态上。仓库删了、域名到期了、或者 EdgeOne Pages 这个免费服务哪天做了调整，已经散落在各处的直链会同时失效。所以：原始照片永远在本地（或网盘）留一份，这个托管空间只当"对外分发出口"，别当唯一存储。

它适合什么、不适合什么

适合：低频更新、长期稳定访问的图库。比如"博客配图仓库"、"作品集展示"、"家人照片的分享相册"——这些场景的共同点是图片挑好之后基本不动，但希望别人打开得快。

不太适合：需要频繁上传删除、需要网页直接拖拽上传、需要按标签/时间精细检索的图床需求。每次加图都要本地准备文件 + commit + push，这套流程对高频使用来说太重了。

如果你的需求偏后者，更合适的选择是带网页上传的图床方案（比如 基于 Telegram 的图床，拖进网页就能传；或者 基于 R2 的云盘方案，存储更可控）。两者其实不冲突：把"精挑细选的展示图"放 EdgeOne 相册，"随手要用的截图"放网页图床，各取所长。

结尾

坦白说，这个项目是 AI 生成的，功能还比较基础，目前更像一个"能展示 + 能出直链"的轻量相册壳子，用起来不算特别顺手：

• 加相册得手动往 Git 仓库里塞文件夹、push，不像网盘那样拖进去就行；

• 原版没有可视化上传和"一键复制 Markdown 链接"这类功能，分享时稍麻烦。

不过思路是对的——EdgeOne Pages + Git 仓库托管图片，国内访问快、免费、可控。有兴趣的朋友可以在这个基础上自己给它加功能，比如做个网页上传接口、加个一键生成 Markdown 外链的按钮，日常用起来就方便多了。

我自己实际用下来，把它当博客配图的稳定外链图床是够用的：把图片按相册文件夹 push 进仓库，Pages 自动重建后就能拿到直链，往文章里一贴即可，国内读者打开速度比 GitHub 图床快不少。如果你正需要一套"国内能快速访问 + 免费 + 图片可外链"的相册/图床方案，这套基于 EdgeOne Pages 的搭法很值得参考——架构简单、不依赖任何国外服务的节点，长期用下来也更省心。当然，因为每加一个相册都要手动 commit，它更适合"低频更新、稳定访问"的场景；高频上传需求的话，还是优先考虑支持网页直传的图床工具。

常见问题

Q：绑定域名后一直提示证书错误 / HTTPS 打不开？

按这个顺序排查：① CNAME 记录是否已生效（用 nslookup 你的域名 看解析到的地址对不对）；② 证书是否已经签发成功（有的平台需要手动点"申请"）；③ 证书绑定的域名和实际访问的域名是否完全一致（www 和不带 www 是两个不同的域名，证书要覆盖到你用的那个）。绝大多数情况卡在第 ① 步——DNS 没生效就去申请证书。

Q：图片放进仓库了，访问页面看不到？

① 确认目录结构对：必须是 public/albums/<相册名>/ 这一层，放错层级页面不会识别；② 确认 push 成功、并且 EdgeOne Pages 那边的构建已完成（构建有延迟，不是 push 完立刻可见）；③ 图片格式是否在支持范围内（常规 JPG/PNG/WebP 都没问题，特殊格式可能不渲染）。

Q：能不能直接把图片外链拿去当图床用？

可以，这也是这个项目的核心用途之一。但注意前面提过的直链寿命问题：链接依赖你的仓库、域名和这个免费服务同时正常。用在正式内容里时，建议重要图片自己也留一份，别让文章里的图成为"唯一存在的那一份"。

Q：国内访问真的比 Cloudflare 快吗？

我的实测体感是稳定——不是每次都快得离谱，而是"很少出现转圈等半天"的情况。这种稳定性对图床来说比峰值速度更重要：访客打开文章时图片能顺畅出现，就是好体验。具体速度还是建议你自己部署后测一下，毕竟不同地区、不同运营商的线路状况有差异。