【记录】美化博客的“折腾”之旅

这几天一直在博客美化（其实有点不务正业的嫌疑，因为这段时间应该备考期末的），本来也挺简单的一件事，但是“折腾”真就是“永无止境”——虽然明明根据操作文档已经然自己的博客用上了，但是总是想着自己去修改一些内容——先是想改背景图片，结果发现为了要使得博客访问加载的快一点，就需要建一个床图（也是在这自己接触了这个概念），于是就开始折腾CloudFlare R2、PicGo等等东西。其中在PicGo上被折腾的最久，其中都放弃了，直接手动在CloudFlare网站上上传图片（确实优点不方便），就因为一个小小的问题...要不是运气好，看到了类似问题的博客文章，估计我就只能“铩羽而归”了。

在这里记录一下自己的这趟“折腾”之旅的一些收获吧。

1.CloudFlare R2存储对象服务

使用R2服务需要绑定银行账户或者PayPal，自己刚尝试直接绑定银联的卡的时候一直不行，后来好在L站有很多有经验的佬友给出了可行方案：

使用绑定PayPal的方式，而不是直接绑定银联卡。

所以也是在这里自己注册了PayPal账号

2.PicGo上传图片

PicGo自己也是刚在这里接触的，是用于上传文件到对象存储服务器（如阿里云OSS、腾讯云COS、github等）的开源软件。

在它的配置上折腾了挺久的，主要是遇到了两个问题：

①安装Amazon S3插件失败

②图片上传失败

问题①：

在v2.3.1插件搜索不到，然后就先下载到本地然后导入，结果还是失败，现在想来应该可以在命令行中使用npm命令下载安装。

在最新的版本v2.4.0-beta9中解决了这个问题，直接下载最新版本就好了。

问题②：

图片上传失败主要是报错： Failed to upload "image.png" to S3: connect ETIMEDOUT 162.159.141.50:443

这表明 PicGo 在尝试连接到 S3 服务器时发生了超时（ETIMEDOUT），可能的原因有：

  1. 网络连接问题
  • 网络不稳定或网速较慢
  • 可能被防火墙拦截
  • DNS 解析问题
  1. S3 配置问题
  • S3 服务器地址配置可能不正确
  • Access Key 或 Secret Key 可能过期或无效

其中也试了一些方法都没用，最后是在看到了CSDN上的一篇博客后，最终解决了，具体操作：

在PicGo中设置代理为自己的开启的代理地址http://127.0.0.1:7890（如下图中的②操作）

并对上传到存储桶中的文件路径进行了修改（如上图的①操作）

至此，问题就已经解决了，终于能成功上传图片了！！！

晚补：现在发现，不设置代理也可以正常上传...就是说白找了半天问题，其实没有问题...唯“时运不济”尔？

后来自己在看到了pseudoyu的教程博客后，又开始了折腾...

配置上传文件的链接格式

继续进行一些配置，如下图所示，再对上传文件的链接格式进行自定义，使得上传后就会根据文件名生成以文件名为 Alt 文本的 Markdown 图片链接。

3.WebP Cloud 图片优化

通常本地截图或是相机拍摄的图片体积较大，对于访客来说加载时间会较长，并不直接适合互联网发布，所以需要进行一些操作先对体积进行压缩。

介绍

通过大佬pseudoyu的博客中，了解到了webP Cloud服务：可以在几乎不改变画质的情况下大幅缩小图片体积，加快整体站点加载速度，除了图片体积减少外，还提供了缓存、添加水印、图片滤镜等更多实用的功能，并提供了自定义 Header 等配置选项。

使用

发现S3插件有两个版本，要选择s3-own 1.4.5的那一个，配置中才有“自定义域名”选项，这个选项之后配置WebP Cloud代理需要用到。

步骤：

  1. 使用github登录

  2. 创建代理

  3. 在PicGo中进行配置

    由于最终需要放在博客中的图片是经过 WebP Cloud 代理过的链接，所以需要回到 PicGo 的「图床设置」中，将「自定义域名」改为我们刚配置的 WebP Cloud 代理地址，即格式为 xxx.webp.li 的代理链接或其他自定义域名。

over！

总结一下：

  1. 使用上了CloudFlare R2对象存储服务；
  2. 会使用PicGo上传图片到存储服务器；
  3. 学会了使用WebP Cloud服务对上传的图片进行优化。

到此，折腾也算告一段落了，然而——”折腾“——没用终点...

好饿，吃饭去喽~

晚上，我又来折腾了，因为我发现使用PicGo上传图片后得到的Webp Cloud代理URL是无效的，于是又找了半天原因...

最后，我找到了原因。

问题分析

跟debug一段程序一样，要找到bug就得对整个过程进行检查。

CloudFlare R2、PicGo和Webp Cloud Services三者配合工作的原理是这样的：在PicGo中配置好CloudFlare R2（Amazon S3）和Webp Cloud Services之后，用户使用PicGo上传文件到Cloudflare R2存储服务器上，然后因为配置了Webp Cloud服务，PicGo会生成一个使用Webp Cloud代理之后的URL，问题就出在这个PicGo生成代理URL的机制里——

注： 如图所示，Webp Cloud只是一个中间代理，最后找资源需要用到正确有效的原对象存储URL。

Webp Cloud的代理URL的生成：直接将上传的存储对象的原URL前部分的公共URL（源站地址，https://pub-e1d2d6027afacef73ab3a7176c0.r2.dev）替换成Webp Cloud 的代理地址（https://cbc2f.webp.li），然后和文件名（longmao.jpg）拼接形成经过Webp Cloud代理的URL：https://cbc2f.webp.li/longmao.jpg。

Webp Cloud Services解析代理URL：是Webp Cloud的代理URL的生成的逆过程——直接将代理后的URL（https://cbc2f.webp.li/longmao.jpg）的webp cloud代理地址替换成源站地址，于是解析结果就得到：

https://pub-e1d2d6027afacef73ab3a7176c0.r2.dev/longmao.jpg。

注意到，在使用PicGo上传图片到CloudFlare R2时，不是直接上传到存储桶的根目录下，而是会上传到原本存储桶下自动新开的一个与存储桶同名的目录（/hua-cdn）里面，这就会导致原本的URL（https://pub-e1d2d60230974acef73ab3a7176c0.r2.dev/longmao.jpg）变成了[https: //pub-e1d2d60230974a5fcefb3a7176c0.r2.dev/ hua-cdn/longmao.jpg]，即两者之间相差了一个/hua-cdn。

而上面讲了，Webp Cloud Services解析得到的URL会是（https://pub-e1d2d6027afacef73ab3a7176c0.r2.dev/longmao.jpg），所以Webp Cloud Services依旧会去自己解析得到的这个错误、无效的存储对象URL去寻找资源，结果当然是找不到资源，最终才会导致PicGo生成的Webp Cloud代理链接无效。

解决方案
  1. 修改 [裁剪后的文件路径] 字段
将[裁剪后的文件路径] 字段修改为 hua-cdn/[文件路径]，即
hua-cdn/{fileName}.{extName}

  1. 在 WebP Cloud Services 配置中修改
修改 WebP Cloud Services 的源站配置，在源站地址后添加 /hua-cdn
例如：https://pub-e1d2d6027afacef73ab3a7176c0.r2.dev/hua-cdn
  1. 修改PicGo 的自定义域名选项
在 S3 配置中的自定义域名字段，填入完整的包含 /hua-cdn 的路径
这样生成的原始 URL 就会包含正确的目录结构
  1. 调整上传的文件路径配置
在 PicGo 的 S3 配置中，将上传文件路径设置为 hua-cdn/{filename}
这样可以确保文件上传到正确的目录，同时 URL 也能正确生成

这里使用第 1 种方案，因为：

  1. 它最符合原有的目录结构
  2. 不需要修改 WebP Cloud Services 的配置
  3. 保持了良好的文件组织结构
  4. 更容易管理和维护

步骤操作：

  1. 打开 PicGo 设置
  2. 进入 S3 图床配置
  3. 在 [裁剪后的文件路径] 字段中填入 hua-cdn/
  4. 保存配置并测试上传

这样设置后，上传的文件会自动放在正确的目录中，生成的 URL 也会包含正确的路径结构。

OK啊，终于也是又告一段落了！

posted @ 2024-12-27 13:36  _Huazzi  阅读(31)  评论(0)  编辑  收藏  举报