Base64 是什么

Base64 是种用 64 个可打印字符来表示二进制数据的编码方法。这 64 个字符含大小写字母各 26 个，还有 10 个数字以及两个符号。

例如，当我们看到一串像 SGVsbG8gV29ybGQh 这样的字符，这就是 Base64 编码后的结果，其实代表了 Hello World！

易于文本传输

在很多网络传输场景中，尤其是早期的网络应用，传输通道主要被设计为传输文本数据。

因为文本数据格式相对简单、统一，而且不容易出现乱码等问题。

而图片是二进制的数据，直接传输二进制数据可能会因为不同系统、不同软件对二进制数据的处理方式不同而出现问题。

Base64 把图片的二进制数据转换成了文本形式。这样一来，通过电子邮件、网页表单等主要以文本传输为主的渠道时，图片就可以顺利跟着文本一起传输了。

比如，在发送带有图片附件的电子邮件，邮件系统会把图片转换成 Base64 格式，然后和邮件的正文一起发送。

接收方收到邮件后，邮件客户端再把 Base64 格式的数据转换回图片，这样我们就能看到图片。

兼容性好

不同的操作系统和不同的软件应用对数据处理方式可能存在差异。Base64 编码后的文本数据在各种平台都能被正确识别和处理。

例如，一个在 Windows 系统上生成的 Base64 编码的图片数据，在 Linux 服务器上也能轻松解码并还原成图片，不用担心因为平台不同而出现数据损坏或者无法读取的情况。

几乎所有的编程语言都有内置的库或者函数来处理 Base64 编码和解码。这使得开发人员在开发涉及图片传输的应用程序时，能够很方便使用 Base64 格式。

比如，在一个基于 Python 的 Web 应用，开发人员可以使用库轻松地将图片文件读取并编码为 Base64 格式，然后通过网络发送给服务器或客户端。

方便在网页中嵌入图片

在网页设计中，如果一个网页中有大量的小图标或小图片，每次加载这些图片都需要发送一个 HTTP 请求。

这不仅会增加服务器的负担，还会影响网页加载速度。

而将这些小图片转换为 Base64 格式后，可以直接将 Base64 编码的数据嵌入到 HTML 或 CSS 文件中。

这样浏览器在加载 HTML 或 CSS 文件的时候，就可以直接读取到图片数据，而不需要单独发送 HTTP 请求去获取图片，从而提高了网页的加载效率。

嵌入 Base64 格式的图片还可以简化网页的结构。不需要在网页文件目录中单独存放这些小图片文件，减少了文件管理复杂性。

对于一些简单的网页应用或前端框架，这种方式非常实用。

安全性的考虑

虽然 Base64 编码不能算是真正的加密方法，但它在一定程度上可起到隐藏信息的作用。

因为对于不了解 Base64 编码的人来说，看到一串 Base64 编码的数据可能不知道它代表的是图片内容。

在一些对安全性要求不是特别高的场景下，可作为一种简单的保护措施。

比如，在一些内部文档分享系统中，把图片转换 Base64 格式传输，可防止非授权用户轻易地获取到原始图片文件。

在某些情况下，直接传输二进制图片文件可能会带来安全风险，如图片文件可能被恶意篡改，包含恶意代码。

将图片转换为 Base64 格式后，这些恶意代码在 Base64 编码文本环境中很难被执行，从而降低安全风险。

缺点

不过，Base64 传输图片也有其缺点。比如，Base64 编码后数据量比原始的二进制图片数据要大，大概会增加百分之三十三左右的大小。

所以在传输大图片或者对带宽要求很高的场景，可能需要权衡下是否使用 Base64 格式。

数据流向

通过下图可以看出，图片文件保存在主机上，通过转换处理为 WebP 格式文件，经由 CDN 回源并实现访问加速：

问题分析

登录 CDN 管理后台查看其日志，发现出现超时记录。

超时原因一般两种，一种是因线路问题导致回源超时，一种是因主机没有及时返回数据造成。

本地图片经由 WebP 中间件处理，再回源给 CDN 做反代，经查是 WebP 服务突然宕机导致 CDN 未收到响应数据导致超时。

除超时问题外，因无返回数据导致 CDN 响应 404，而服务器设置 404 默认跳转至主站首页，这就导致好多小伙伴频繁刷新页面依然不显示图片。

解决方案

目前已关闭 CDN，流量直接回源至源主机，缺点就是会影响访问的速度。带调试维护后会重新挂上 CDN。

WebP 图片转换是为了减少图片体积，进而减轻带宽压力「轻量级服务器有流量的限制」因此不能暂停使用，已修改其参数，尽量保障响应的成功率。

如之前有访问记录，会留下 404 跳转缓存，需要清理相关数据。

有小伙伴分享了两种清理缓存的方法，需要的小伙伴可以参考操作。

清理缓存

首先进入到浏览器的开发者工具，一般浏览器点击F12即可，进入更多设置，勾选 Disable cache while DevTools is open 项：

或者切换到网络标签页，勾选禁用缓存，刷新页面即可「注意保持开发者工具一直处于开启的状态」

报错信息

1
2
3

ERROR render of "page" failed: "/home/runner/work/photo/photo/themes/gallery/layouts/_default/single.html:3:5": execute of template failed: template: _default/single.html:3:5: executing "main" at <partial "gallery.html" .>: error calling partial: partial "gallery.html" timed out after 30s. This is most likely due to infinite recursion. If this is just a slow template, you can try to increase the 'timeout' config setting.
Total in 60412 ms
Error: error building site: render: failed to render pages: render of "page" failed: "/home/runner/work/photo/photo/themes/gallery/layouts/_default/single.html:3:5": execute of template failed: template: _default/single.html:3:5: executing "main" at <partial "gallery.html" .>: error calling partial: partial "gallery.html" timed out after 30s. This is most likely due to infinite recursion. If this is just a slow template, you can try to increase the 'timeout' config setting.

注意：杜老师是通过 GitHub Actions 来部署，逻辑是先准备 Hugo 的运行环境，再根据站点的数据渲染站点文件。在生成站点文件时出现如上错误信息。

解决思路

从错误信息看，Hugo 网站在渲染页面时出现了问题，具体是 gallery.html 这个 partial 文件在执行时超时了，并且怀疑是由于无限递归导致的。

首先检查 gallery.html 中代码。无限递归问题可能是 gallery.html 中调用了自身，或者在调用其它 partial 时形成了循环。仔细检查文件，确保没有递归调用自己或其它可能导致循环的部分。

其次检查数据结构。如果 gallery.html 中依赖某些数据结构，可能是数据结构中存在循环引用。例如，某个对象或者列表在渲染时不断递归调用。

再次增加超时时间。如果确认不是无限递归问题，而是模板渲染确实很慢，可以尝试增加超时时间。在 Hugo 的配置文件中，增加 timeout 配置项，如 timeout = '60000'。

然后优化模板性能。如果模板渲染确实很慢，可能是模板的代码过于复杂。可以尝试优化模板代码，减少不必要循环和复杂逻辑。

接着调试模板。使用 Hugo 的调试工具来逐步检查模板的执行过程。可通过在模板中添加日志输出来帮助调试。

再者检查依赖插件。如果网站使用第三方插件或依赖，可能是插件导致了问题。尝试禁用插件，看看能否解决问题。

最后检查 Hugo 的版本。确保使用的 Hugo 版本是最新的。旧版本可能存在已知的 bug，而新版本可能已修复了这些问题。