有时候，我们需要给网页引入网络字体来增强页面的阅读体验。

纯英文页面通常只需要一套包含大小写字母、数字以及符号的字体，在经过 WOFF2 压缩之后，这类字体的体积往往非常小。但是对于中文为主的网页来说，一套包含完整中文的字体即使经过压缩后文件体积也可能达到 MB 级别。如果直接引用未经过优化的字体文件会给页面加载带来产生非常明显的网络开销。

目前字体方面已经有一系列非常成熟的优化方案，例如对字体进行预加载、子集化、unicode-range 切片、font-display: swap 等等。在引入这些方案后会有非常明显的优化效果，通常情况下，能将一套包含中文字体文件体积控制在一两百 KB 甚至更小而且不会对页面体验产生明显影响，这样的优化已经能满足绝大部分的场景。

直接高效的本体 + DLC 方案

最近开发的过程中碰到了一个比较有意思的情况：页面有一组固定不变的字符以及另一组会不定时改变且经常复用的带生僻字的动态字符。原来的解决方法类似于游戏本体 + DLC，通过脚本 + 工作流的方式定时从后端获取所有动态字符进行子集化，生成不变字符字体和动态字符字体。这种方法非常直接高效，原本 5.7 MB 的字体文件压缩到了 110KB 的不变字符字体 + 8KB 的动态字符字体。

但是前段时间调整数据库架构之后，如果继续使用之前的解决方法去聚合所有动态字符，会把私有用户的某些信息暴露出去。所以需要一种不预先收集所有文本，也能按需加载字体中缺失字符的方案。

看起来很合理的 unicode-range 方案

当使用 @font-face 引入字体的时候，CSS 提供了一个 unicode-range 描述符，允许传入 Unicode 码位来实现根据页面实际使用的字符，加载对应的字体文件，从而避免直接传入庞大的字体文件。

@font-face {
  font-family: 'Noto Sans SC';
  font-style: normal;
  font-weight: 400;
  src: url(https://fonts.gstatic.com/s/notosanssc/v41/k3kCo84MPvpLmixcA63oeAL7Iqp5IZJF9bmaG9_FnYlNbPzT7HEL7j12XCOHJKg4RgZw3nFTvwZ8atTsBvwlvRUk7mYP2g.4.woff2) format('woff2');
  unicode-range: U+1f1e9-1f1f5, U+1f1f7-1f1ff, U+1f21a, U+1f232, U+1f234-1f237, U+1f250-1f251, U+1f300, U+1f302-1f308, U+1f30a-1f311, U+1f315, U+1f319-1f320, U+1f324, U+1f327, U+1f32a, U+1f32c-1f32d, U+1f330-1f357, U+1f359-1f37e;
}

根据目前的需求可以将不变字符组单独切分一片，其余字符根据 Google Fonts 中文字体的 unicode-range 切片方式，剔除掉不变字符组后再进行切片。

实际上 Google Fonts 等中文字体切片方案并不是简单地将一套字体按照码位进行平均切片，其会在字频、切片后的字体文件体积、每个页面平均的请求数量以及字符覆盖率之间做平衡。

这种方案在普通网站中效果非常优秀，但是上文提到，这个页面的动态字符里带有生僻字（而且还不少😭。实际测试下来大量生僻字被分散到各种大块 Unicode 切片里，仅仅一个生僻字 “翳” 就得触发一整个几十 KB 切片的下载。即使限制了单个切片的最大体积，最夸张的一个页面也还是会触发 50 个切片总共超过 400 KB 的字体下载。为了减轻字体压力的 unicode-range 反而产生了大量不必要的开销。

未来可期的 IFT

WARNING

截止文章撰写时依然没有浏览器原生支持 IFT，下文的测试均使用官方 DEMO (https://garretrieger.github.io/ift-demo) 的 WASM 实现

目前正在 W3C 候选推荐草案阶段的 增量字体传输 IFT 提供了一个新的选择。

IFT 又是什么

与 Unicode 切片是一个个完整的字体文件不同，IFT 实际上是由一个初始字体文件 + 许多后续加载的二进制字体补丁组成。初始字体文件内自带一份补丁映射表，浏览器在加载完初始字体文件之后会先检查其中的字体子集是否已经包含页面所有的字形，再根据补丁映射表下载对应的字形补丁，最后合并到初始字体文件中。

一个 TTF 的字体文件里主要包含字形数据和字体表两类数据，字形数据用来说明一个字符的形状以及应该怎么绘制出这个字符，而字体表提供怎么去找对应的字符以及怎么去排版等的信息。由于 IFT （增量字体传输）允许字体文件通过打补丁的方式来拓展字体集，所以 IFT 也主要分为字形补丁（glyph keyed patch）和表补丁（table keyed patch）两种机制，字形补丁用来增量补上字符字的字形数据，表补丁用来增量补充或者更新字体表。

IFT 对于字形补丁和表补丁两种补丁机制有可能会出现两种不同的处理方式：

1. 字形补丁描述的是单个字符如何进行处理，一般不会因为其中某一个字形补丁而导致另一个字形补丁失效。
2. 而表补丁除了可以修改字体表以外，还可能更新补丁映射表。上文说过浏览器在加载完初始字体文件会根据补丁映射表下载对应的字形补丁，一旦触发了更新补丁映射表，其余的表补丁以及字形补丁就需要等待补丁映射表更新完成后重新去判断是否还需要该补丁，所以一般情况下处理表补丁会比处理字形补丁更复杂。

Not support render this content in RSS render

效果

要使用 IFT 的相关功能需要使用 w3c/ift-encoder 库对字体文件进行 IFT 编码，这里我们关注几个主要的参数：

由于页面是中文为主，可以使用 --auto_config_primary_script=Script_chinese-simplified 来指定主要文字系统为简体中文。但是与上文的 Google Fonts 切片方式类似，对于大量生僻字的页面来说这种编码方式效果依然不佳，好在 IFT 允许通过 FrequencyDataConfig 指向根据我们自己字频数据编码的 Riegeli 文件来贴合页面的实际效果，后面测试中会使用页面以前的动态字符数据构建自己的 Riegeli 文件。

上文提到表补丁可能相互产生影响，所以在对字体进行编码的时候，编码器需要使用补丁图去处理不同补丁之间的关系。我们可以使用max_depth 参数去限制表补丁图的最大深度，否则会导致补丁规模爆炸。

原始 TTF 字体可能包含几万个字符，在编码的时候需要对里面的字符组合打包成若干份补丁，编辑器想要找到最优的打包方案的话需要对每个候选组合进行非常精确同时也非常慢的压缩（主合并），如果直接进行主合并会导致编码过程慢到不可用的状态，所以在主合并前需要进行粗略的预处理合并。预处理合并的工作流程主要受 preprocess_merging_group_size 和 preprocess_merging_probability_threshold** 这两个参数控制。具体如下：

1. 将 Riegeli 文件按字频数据从高到低进行排序
2. 概率低于 preprocess_merging_probability_threshold 的字归类为低频字，从尾部开始每 preprocess_merging_group_size 个字符打包成一份补丁
3. 概率高于 preprocess_merging_probability_threshold 的字归类为高频字，交由主合并进行后续打包

这样就能在保证效果的情况下，极大减轻编码流程的时间以及工作量。

对字体进行 IFT 编码后，页面相关测试结果如下：

所以 IFT 方案目前推荐使用吗？

在「不预先收集所有文本，也要按需加载字体中缺失的字符」的限制下，算上后续尝试的现用现切的动态子集方案，IFT 方案依然是我目前试过最满意的方案。

极端页面下，对比 unicode-range 方案里最优的 8 码位切片，IFT 的请求数减少了三分之一以上，传输数据量也更低。而得益于 IFT 的增量传输机制，能够实现一直围绕同一份字体文件，相对于 unicode-range 切分成许多不同的分片字体，IFT 有不容易破坏字距、连字排版规则等原生优势。

但是，其目前仍有两个明显的障碍：一是目前需要捆绑上一个 WASM 来实现 IFT 功能，会白白增加两百多 KB 的开销，二是没法充分利用浏览器原生的字体预加载等优化机制，所以现阶段我并不推荐使用这套方案。

等到未来哪天浏览器原生支持 tech(incremental)，彻底甩掉 WASM 之后，IFT 大概就会从「未来可期」变成真正的最优选择之一吧。

最近发现服务器系统的 EOL 快到了，加上目前的 2C2G 配置跑几个项目的话内存占用就已经常驻 70%+，于是趁着续费服务器就直接换了台 2C4G 的服务器（才不是因为新买一台比续费便宜。

因为两台服务器的系统不同，无法通过自定义镜像去快速迁移数据。但是得益于目前 AI 的空前发达，服务器创建了个快照之后给 AI 配置了两条隧道，尝试让它帮忙做迁移。原本以为要花一下午才弄好，没想到半个小时不到就搞定了 AI真是太好用了你知道吗

还顺便在腾讯云领了国补（其实是退的钱😋

另外最近玩的二游又多又杂，每个二游都有自己的社区签到给蚊子腿奖励，每天起床一睁眼就跟上班一样去各个社区签到。参考 GitHub 上面不同社区的签到脚本缝了个带推送的整合版脚本，给身边玩二游的朋友们用了反响似乎还挺不错。

以前写过一篇文章，使用快捷指令实现将健身记录同步到博客的个人状态中。

https://www.vinking.top/posts/codes/sync-fitness-records-to-blog-status

但是实际上用下来感觉非常的难受，一方面由于快捷指令太长了，一旦需要对其中部分的信息进行调整，操作会非常非常的麻烦；另一方面，苹果的自动化并没有固定时间自动执行的选项，为了覆盖一整天的定时同步，需要创建五六个自动化任务。整体显得非常笨重且繁琐。所以在过年的这段时间写了一个应用，使用 HKObserverQuery + 小组件定时任务来实现数据的后台自动推送。

::: masonry :::

但由于我使用的是免费的苹果开发者账户，只能将应用手动打包为 ipa 文件，然后通过 SideStore 进行安装。导致即使声明了 HealthKit entitlements，安装后也不会弹出健康数据授权页面，也就无法访问任何健康数据。网上找了一圈也没什么好的解决方案，一度以为只能每周连接 Xcode 重新构建到手机来给应用续命了。

后面无意中翻到 Reddit 的这个 帖子 ，评论区里有人提到一个思路：通过修改应用的 Bundle ID，让它使用另一个已经存在 App ID 来通过替身的方式绕开 App ID 未过期导致无法安装新应用的问题。

经过尝试，这个方法也适用于解决通过 SideStore 安装的应用无法弹出健康数据授权的问题。具体做法是：通过将 Xcode 项目里的 Bundle ID 改成与最初通过 SideStore 安装该应用时相同的 App ID，然后在 Xcode 里连接真机运行一次，让 Xcode 给这个 App ID 注册 HealthKit capability ，这时候打开应用就可以正常弹出健康数据授权页面并且完成数据的授权。

最后将应用重新构建为 ipa，再用 SideStore 安装后，就能在已授权状态下访问到 HealthKit 数据。这种方法可以在一定程度上绕开苹果免费开发者账户侧载应用不弹授权页面的限制。

当然通过这种方式完成的授权能否长期保持还有待进一步观察。如果后续有新的结果，我会再更新。 该方法确认可以长期使用。

【 战斗速报！】 各位早上好 中午好 晚上好，从前天开始持续遭遇多个脚本的恶意攻击。今天早上到达了小高峰，几小时就受到了 20w+ 的恶意请求，已经刷掉近 10GB 的流量。目前已经将这些 IP 段拉入黑名单：

182.34.4.0/24
180.119.118.0/23
140.75.192.0/24
121.233.200.0/24
61.147.92.0/24
120.238.245.0/24
58.222.45.0/24
218.90.199.0/24

由于这些请求基本上是每 5 分钟消耗 100 MB 左右的流量，所以并没有触发 CDN 设置的 5 分钟 200MB 封顶限制，加上周末早上在睡大觉，导致本月的 CDN 免费额度已经被消耗了一半以上

如果后续继续被攻击到 CDN 免费额度耗尽，会将境内的流量全部解析到境外的线路躲一阵子，届时会出现不限于网站打开时间大幅拉长，部分地区无法访问等情况，请各位谅解。

最后请脚本大佬手下留情

后续

鉴于恶意攻击仍在零星持续，目前已经着手编写并且启用了自动检测并更新 CDN 黑名单的脚本，这次大概能睡一个好觉了。

前言

在 Shiro 主题中有一个 「个人状态展示」 功能，可以展示一些自定义的状态。

为了充分利用这个功能，想将手机的健身圆环的数据同步展示在个人状态里，效果如下：

最初计划通过编写 JavaScript 脚本并借助 Scriptable 应用来实现这个想法。然而经过尝试后发现，Scriptable 并不支持 HealthKit，从而无法获取到健康数据。在苹果设备上，应用需要通过 HealthKit 的 API 才能访问健康数据，而 Scriptable 曾尝试集成 HealthKit但是被苹果商店拒绝。所以只能退而求其次，使用苹果自带的快捷指令来实现这一功能。

2026.3.1 更新，由于快捷指令的限制太多，目前已经更换为自己编写的 App + SideStore自签来实现自动推送

状态展示的设置

通过手动设置个人状态展示，可以在控制台中看到页面通过 POST 的方式向 https://{后端服务器}/api/v2/serverless/shiro/status 发送了一个请求：

请求的请求体包含下面这样格式的 JSON：

{
    "emoji": "😴", // 头像右下角的 Emoji
    "desc": "消耗0千卡能量 锻炼0分钟 站立0小时", // 展开后的描述
    "ttl": 60 // 状态的持续时间，单位为秒
}

为了完成更新个人状态的操作，需要先获取访问令牌并且构建请求头 Authorization: bearer {token} 用于验证用户权限。

访问令牌有两种获得方法，第一种是每次设置状态前先发起一次登录请求，在登录请求返回的 JSON 里就能获得一个 xxxxx.xxxxxxxx 格式的访问令牌。

另一种是通过在后台 设定 -> 安全 -> API Token 里新建一个 xxxxxxxxxxxxxx 格式的访问令牌，这里推荐这种方式。

拿到访问令牌后，控制台里验证一下：

const token = "xxxxxxxxx";
fetch("https://server.vinking.top/api/v2/serverless/shiro/status", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    Authorization: token,
  },
  body: JSON.stringify({
    emoji: "✌️",
    desc: "测试",
    ttl: 60,
  }),
})
  .then((response) => {
    if (response.ok) {
      return response.text().then(() => {
        console.log(`用户状态设置成功，状态码: ${response.status}`);
      });
    }
  })
  .catch((error) => console.error("用户状态设置错误:", error));

成功设置状态。

设计快捷指令

要实现自动同步健康数据到个人状态展示，需要设计一个能获取健康数据、构建请求并调用 API 的快捷指令。在将流程图转换为快捷指令的过程中有几个需要注意的坑：

1. 如果某类数据当天没有记录（如未锻炼），快捷指令会返回空值而不是 0。需要提前设置一个初始值 0 以避免后续拼接描述文本出现问题。
2. 如果想要数据与苹果健康的健身记录面板数据一致，需特别注意「站立 x 小时」（Stand Hours）的统计方式。它反映的是达标次数，而非实际站立时长。其计算逻辑为：每个小时内，只要累计站立时间达到或超过 1 分钟，即算作 1 小时达标。例如，08:00 - 08:01 站立，09:30 - 09:31 站立，会被记录为 2 小时达标。相比之下，快捷指令获取的「站立分钟数」（Stand Time）是每次站立的实际分钟数。因此，若要统计「站立 x 小时」，需通过计数的方式统计每小时是否达标，而非直接累加站立分钟数。使用指令表达如下：

3. 当接口成功设置状态时，仅返回 204 状态码且不返回任何内容，加上快捷指令本身不支持直接对 HTTP 状态码进行详细判断，因此只能通过判断返回文件的大小是否为 0 来确认设置是否成功。

由于快捷指令太长了，所以放快捷指令。

快捷指令完整流程如下（超级长图警告）：

前两个月由于腾讯云 CDN 不支持欠费立刻暂停服务换到了多吉云 CDN。

目前 宝塔/1Panel 的免费 SSL 证书都只有 90 天的有效期，虽然可以自动续签，但是续签后还是需要频繁手动更新 CDN 的证书，非常麻烦。

好在多吉云提供了对应的 API，使得我们可以通过脚本的方式自动实现同步 SSL 证书到多吉云 CDN。

功能

• 🔑 动态生成多吉云 API 访问令牌
• 📤 一键式证书上传与管理
• 🌐 多域名智能证书绑定
• 🗑️ 旧证书清理功能（可选）
• ⏰ 无缝衔接 Let's Encrypt 自动续期
• ✅ 双平台支持（宝塔/1Panel）

https://github.com/DearVinking/Cert2DogeCloud

快速开始

1. 获取多吉云 API 密钥：
   • 登录多吉云控制台
   • 进入「用户中心」→「密钥管理」
   • 创建新密钥对
2. 确认证书路径：
   • 宝塔面板：/www/server/panel/vhost/ssl/域名目录/
   • 1Panel 可跳过

配置指南

编辑脚本中的以下参数：

# 多吉云 AccessKey 和 SecretK
ACCESS_KEY="your_access_key_here"   # 替换为你的AccessKey
SECRET_KEY="your_secret_key_here"  # 替换为你的SecretKey

# 证书路径配置
FULLCHAIN_PATH="/path/to/fullchain.pem"  # 全链证书路径
PRIVKEY_PATH="/path/to/privkey.pem"      # 私钥路径

# 域名配置
DOMAINS=("example.com" "cdn.example.com" "www.example.com")  # 需要绑定的域名列表

# 旧证书处理策略
DELETE_OLD_CERT=false  # true=自动删除旧证书 | false=保留历史证书

部署指南

1Panel

1. 进入证书管理界面

2. 创建/编辑证书：

   • 启用「自动续签」
   • 启用「推送证书到本地目录」
   • 选择目录
   • 启用「申请后执行脚本」
   • 粘贴本脚本内容
   • 修改证书路径为：

   # 证书路径
   FULLCHAIN_PATH="./fullchain.pem"
   PRIVKEY_PATH="./privkey.pem"
   

宝塔

1. 创建定时任务：
   • 任务类型：Shell 脚本
   • 任务名称：随意
   • 执行周期：每月 1 号 01:30 执行一次
   • 执行用户：root
   • 脚本内容：粘贴本脚本内容

2. 配合自动续签 Let’s Encrypt 证书定时任务 /www/server/panel/pyenv/bin/python /www/server/panel/class/acme_v2.py –renew=1 理论上可以实现放养多吉云 CDN 的证书。

保存后执行一次任务，如果显示下面信息即已经完成证书的同步：

证书上传成功！
证书ID：12345
证书已成功绑定到 www.vinking.top
证书已成功绑定到 vinking.top
证书ID 12344 删除成功。
----------------------------------------------------------------------------
★[2024-12-26 16:01:29] Successful
----------------------------------------------------------------------------

代码思路

获取密钥 & 生成 AccessToken

多吉云的 API 具有验证机制，使用前需要在控制台的 密钥管理 获取 AccessKey 以及 SecretKey，然后根据 AccessKey 和 SecretKey生成 AccessToken 。

AccessToken 的生成过程是将请求地址和请求内容拼接后，使用 SecretKey 进行 HMAC-SHA1 加密，然后将得到的加密值与 AccessKey 用冒号连接起来。具体的生成算法可以参考文档 验证机制 。

# 多吉云 AccessKey 和 SecretKey
ACCESS_KEY="xxxx"
SECRET_KEY="xxxxxx"

function generateAccessToken() {
    local apiPath="$1"
    local body="$2"
    local signStr=$(echo -e "${apiPath}\n${body}")
    local sign=$(echo -n "$signStr" | openssl dgst -sha1 -hmac "$SECRET_KEY" | awk '{print $NF}')
    local accessToken="$ACCESS_KEY:$sign"

    echo "$accessToken"
}
 

生成了 AccessToken 后，只需要在请求头中加上 Authorization: TOKEN <AccessToken> 即可通过验证。

找到宝塔的域名证书 & 上传证书

在 /www/server/panel/vhost/ssl/ 目录下，可以找到宝塔所有以域名命名的文件夹，文件夹内包含这个域名对应的完整证书链 fullchain.pem 以及私钥 privkey.pem。

这里推荐给域名及其所有子域名使用同一个泛域名证书，可以实现一次性将域名及其所有子域名完成证书同步。

以域名 vinking.top 为例，完整证书链文件和私钥文件的目录如下：

FULLCHAIN_PATH="/www/server/panel/vhost/ssl/vinking.top/fullchain.pem"
PRIVKEY_PATH="/www/server/panel/vhost/ssl/vinking.top/privkey.pem"

获取到域名证书后，需要通过 POST 的方式向 https://api.dogecloud.com/cdn/cert/upload.json 提交证书内容。上传成功后需要获取证书 ID，以便将刚才上传的证书绑定到域名。

参考文档 上传证书 、 绑定证书 。

# 宝塔面板 Let's Encrypt 证书路径
FULLCHAIN_PATH="/www/server/panel/vhost/ssl/vinking.top/fullchain.pem"
PRIVKEY_PATH="/www/server/panel/vhost/ssl/vinking.top/privkey.pem"

# 证书备注名
CURRENT_DATE=$(date +"%y/%m/%d")
NOTE="Certificate $CURRENT_DATE"

# 需要绑定的域名列表
DOMAINS=("xxxxx.com" "cdn.xxxxx.com" "www.xxxxx.com")

# 上传证书到多吉云
function uploadCert() {
    local note="$1"
    local certFile="$2"
    local privateKeyFile="$3"
    local certContent=$(<"$certFile")
    local privateKeyContent=$(<"$privateKeyFile")
    local encodedCert=$(echo "$certContent" | jq -sRr @uri)
    local encodedPrivateKey=$(echo "$privateKeyContent" | jq -sRr @uri)
    local body="note=$note&cert=$encodedCert&private=$encodedPrivateKey"
    local accessToken=$(generateAccessToken "/cdn/cert/upload.json" "$body")
    local response=$(curl -s -X POST "https://api.dogecloud.com/cdn/cert/upload.json"  \
         -H "Authorization: TOKEN $accessToken" \
         -H "Content-Type: application/x-www-form-urlencoded" \
         --data "$body")

    local code=$(echo "$response" | jq -r '.code')

    if [ "$code" -eq 200 ]; then
        echo "证书上传成功！"
        local certId=$(echo "$response" | jq -r '.data.id')
        echo "证书 ID：$certId"
        bindCert "$certId"
    else
        local errMsg=$(echo "$response" | jq -r '.msg')
        echo "证书上传失败，错误代码：$code，错误信息：$errMsg"
    fi
}

# 绑定证书
function bindCert() {
    local certId="$1"
    local responses=()

    for domain in "${DOMAINS[@]}"; do
        (
            local body="id=$certId&domain=$domain"
            local accessToken=$(generateAccessToken "/cdn/cert/bind.json" "$body")
            local response=$(curl -s -X POST "https://api.dogecloud.com/cdn/cert/bind.json"  \
                 -H "Authorization: TOKEN $accessToken" \
                 -H "Content-Type: application/x-www-form-urlencoded" \
                 --data "$body")
            local code=$(echo "$response" | jq -r '.code')

            if [ "$code" -eq 200 ]; then
                echo "证书已成功绑定到 $domain"
            else
                local errMsg=$(echo "$response" | jq -r '.msg')
                echo "绑定证书到 $domain 失败，错误代码：$code，错误信息：$errMsg"
            fi
        ) &
    done

    wait
}