前言
上一篇《如何根据自己的需求选型对象存储？》聊了一下对象存储的选型，从存储类型、区域选择一路聊到防盗链和成本计算。今天来实现之前预告的内容，我们把对象存储从"选好了"推进到"用起来"，用最典型的场景——图床，走一遍完整流程。
折腾出一个图床对我们的博客、网站有很大的好处，把图片单独挪出去，可以有效地提升博客的加载速度、腾出大量的服务器磁盘空间、备份文件也能变小很多。
先有一个能放图的地方
图床的本质很简单：图片不再放在博客服务器上，而是存到对象存储里，博客里只留一条外链地址。浏览器打开文章时，再去对象存储把图拉回来。
动手之前先科普一个词：S3 协议。它是对象存储行业里最通用的接口标准，最早由 AWS 提出，现在几乎所有对象存储服务都兼容。兼容 S3 意味着什么？后面要用的 PicGo、rclone 这些工具都能直接连，不用为每家服务单独学一遍。
搭建过程，以我在用的 VMRack 对象存储为例（目前还在公测阶段，每月送 5GB 存储＋10GB 下行流量，个人博客绰绰有余）：
创建存储桶（Bucket）：存储桶就是对象存储里的"文件夹"，图片都往里面放。名字起个好认的，比如
blog-images；访问权限选"公共读"：这一步是图床的关键。图床的图片要被所有访客直接访问，必须开公共读；私有的那种（每次访问都要带签名）适合存备份文件，不适合做图床；
区域就近选：读者群在哪就选离哪近的节点；
拿到外链域名：建好桶之后，将你的域名添加到存储桶里，并且在域名服务商处给该域名添加一个存储桶指定的CNAME记录，以后存储桶里的每一张图，就是一条
https://外链域名/文件名这样的 URL。
特别注意：公共读的桶，任何人拿到 URL 都能访问你的图片，所以不要把私有文件（备份、截图里带账号密码的）放进图床桶，图床桶只放对外展示的图片。
让传图这件事变顺手
桶建好了，接下来的日常就是传图。裸传法是打开控制台网页手动点上传——能用，但每篇文章十几张图，点一次崩溃一次。顺手的关键是让工具融入写作流程，我按使用频率推荐三款：
PicGo（日常主力）：一款开源的桌面图床工具，配置好 S3 协议之后，拖图进去就自动上传，并直接把外链 URL 复制到剪贴板。我的写作流是：截图 → PicGo 自动上传 → 粘贴 URL 进草稿，全程不超过五秒。它还支持和 Typora 这类 Markdown 编辑器联动，编辑器里粘贴图片自动走 PicGo 上传，写文章时完全感知不到"上传"这个动作的存在。
配置 PicGo 连 S3 协议的存储，主要就四项：接口地址（endpoint）、桶名、访问密钥（AK/SK）、自定义域名。在对象存储控制台的密钥管理里都能找到，照着填就行。
rclone（批量搬家用）：如果博客已经跑了一两年，历史图片都堆在服务器上，就得用 rclone 做批量迁移。它是一个命令行同步工具，支持 S3 协议，一条命令可以把整个图片目录推到对象存储：
rclone copy /www/wwwroot/blog/upload s3:blog-images/upload 我当时迁移历史图片就是用它，几百张图一条命令跑完。跑完之后历史图片的 URL 需要在数据库里批量替换旧路径，替换的思路和 WordPress 换域名是一样的——谨慎操作，先备份再动手。
博客后台直传（临时救急）：有些博客系统的编辑器支持配置对象存储作为默认上传目标，传图直接进桶。适合不想装桌面工具的场景，但灵活度不如 PicGo，截图、录屏这类博客之外的素材管不到。
上传之前先瘦身
图片进了对象存储，存储费和流量费都是按大小算的，压缩这一步是直接省钱，顺带提速。一张 3MB 的原图压到 200KB，访客打开快 15 倍，流量费省 93%，而画质肉眼几乎看不出区别。
我的做法分三层：
格式选对：博客配图优先用 WebP 格式，同等画质下体积比 JPG 小 25%-35%。截图、示意图这类大面积纯色的图，PNG 转 WebP 收益更明显；照片类用 JPG（或 WebP）就够了。现在主流浏览器对 WebP 的支持已经很完善，不用担心兼容性。
上传前压一遍：在线工具推荐 Squoosh（谷歌出品的免费网页工具），拖进去手动对比压缩前后的画质，选一个平衡点导出。用 PicGo 的话可以装压缩插件，在上传链路里自动完成，无感。
尺寸别超规格：博客正文配图，宽度 1280px 完全够用（高分屏折算 2 倍也就 2560px），手机拍的照片先裁到这个宽度再传。直接传 4000px 原图纯属浪费——访客看到的还是 800px 的显示区域。
三步做完，单图基本能控制在 200KB 以内。特别注意：压缩要放在上传之前，图已经传上去了再想压缩，就得下载、压缩、重新上传、替换 URL，来回折腾四遍。
CDN 加速
到上一步为止，图床已经能用了，但直连对象存储的外链，速度取决于你选的区域节点——读者离得远，加载就慢。CDN 加速这一层，是让全国的访客都从离自己最近的节点拿图。
原理简单说：给图床配一个加速域名，访客请求的是 CDN 节点，节点上有缓存就直接返回；没有缓存才回对象存储源站取一次（这个动作叫回源）。图片这种内容天生适合 CDN——同一个文件会被成千上万次访问，缓存命中率极高。
配置上主要四步：
在 CDN 服务里添加加速域名，源站填对象存储的访问地址（我用的 99CDN 的 CDN 服务，可以利用他们的免费CDN）；
给加速域名做 CNAME 解析，把域名指到 CDN 分配的地址上，具体操作可以看蜜汁博客的这篇文章《如何配置99CDN解析管理》，写得很细；
设置缓存规则：图片目录设置长缓存（比如缓存 365 天）。这里有个配套技巧——图片文件名带上哈希值（很多工具上传时自动改名，比如
photo-a1b2c3.webp），文件内容一变文件名就变，长缓存就不会导致更新后访客看到旧图；开防盗链：CDN 设置里配置 Referer 白名单，只允许自己博客的域名引用图片，别的网站直接外链你的图，请求会被拒绝。
防盗链这一步强烈建议别省。没开防盗链的图床，图片会被各种网站、公众号直接盗链引用，流量都是你的钱在烧——之前算过自建 CDN 每月花多少钱，流量失控是最容易把成本算崩的变量。
成本监控：账单要心里有数
最后聊钱。对象存储的计费就三块：存储量（每 GB 每月多少钱）、下行流量（访客下载图片产生的流量）、请求次数（读写的次数，通常占比很小）。个人博客的账很好算，我直接摆一下自己的数据：
图片总量 1000 张，压缩后平均 200KB，存储占用约 200MB——存储费基本可以忽略不计；
每月下行流量 2-3GB，日均线 100MB 上下——博客日均访问量几百到一千次的样子；
请求次数每天几万次，费用最低的一档。
也就是说，图床的成本大头永远是下行流量，存储几乎白送。这个结论反过来指导两件事：一是压缩图片（第四节）和 CDN 缓存命中率（第五节）直接决定流量账单；二是监控要看的主要就是流量曲线。
监控习惯上，我每周看一次用量面板，重点盯流量有没有异常突起。正常曲线是平缓的，哪天突然冒出一根尖刺，多半是被盗链或者被恶意刷流量，第一时间要去查防盗链配置。有些服务支持设置用量告警，达到阈值自动提醒，比人肉盯更保险。另外留意一下各家公测和活动，比如 VMRack 对象存储现在每月送 5GB 存储＋10GB 下行，个人博客实际用量比我上面算的还小，白嫖期内成本可以直接归零。
预告
到这里，对象存储"选好了 → 用起来"这条线就走完了：搭建一个公共读的桶，PicGo 融入写作流，上传前压一遍，CDN 套上加速和防盗链，最后每周瞄一眼流量曲线。
下一篇准备聊对象存储的另一个刚需场景——备份：博客文件和数据库定时备份到对象存储，实现异地容灾。毕竟图床是让博客更快，备份是让博客死不了，一个都不能少 (・ω・)ノ
谢谢你看到这里！
