攻略制作者收集#

• appmedia - 推特 https://appmedia.jp/fategrandorder
• gamewith - 推特 https://gamewith.jp/fgo
• 推特上的攻略作者 @Siro_gaming1 @FGO0TM

开源#

项目最初是使用酷Q的易语言 SDK 开发，后使用 Node.js 重写并开源

开源版本不含咬人功能，因为懒得移植了……

用法及功能#

请见 GitHub README 以及 wiki

示例#

普通搜图#

利用 ascii2d 搜索局部图#

搜番#

搜本子#

静态博客框架有挺多的#

作为老登，提到静态博客我第一个想到的还是 Hexo，毕竟在我还经常玩博客的时候，就它最出名

但现在都 2026 年了，肯定有更现代的静态博客框架

让 AI 查找比较了一番，并且重点考察了下主题生态，最终还是选了 Astro 加上 Firefly 主题

迁移是个大工程#

我早在两年前就想过迁移到静态博客，但考虑到工作量、原本许多额外的魔改和功能、评论系统等方面，最终都搁置了

但现在不一样了，我有 Codex，还赶上最近 Tibo 天天发重置，再没有比这个周末更适合做这件事的了

我把原来博客的数据库、整个博客和主题源码都导了出来，花半小时初始化项目、写好要求，直接 GPT-6 Astra High Fast 开蹬

结果非常 amazing 啊，只用了 3 个小时就迁移完成了，赶在重置前搞定，并且检查了下没有什么大问题

之后断断续续花了两天进行了些修改和配置，做了一些小修改，最终也算成功迁移完成了

然后#

还是有些后遗症的，比如文章链接，由于现有框架不支持旧博客的 url 组织方式，只好按新的来了，接下来还得去配一下重定向规则，或许还得给 Google Search 提交一下网址变更

以及评论，这个确实是我最不想丢的，我把几千条旧评论都导出来了，到时候看看能不能魔改一下接进去复活一下，虽然只能看，不过也是这个博客为数不多的宝贵财富

目前博客还没有配评论系统，后面有时间再复活，现在就先凑合看吧（

背景#

最近研究完明日方舟的整个解包流程，于是把我方舟工具箱里数据自动更新的流程都换成了自己解包的流程，其中涉及到检查更新、下载数据等步骤

这些步骤都有单独的代码放在单独的仓库里，写在 Workflow 里非常繁琐，我需要检出、安装依赖、执行，至少三个步骤，而且 github 官方的 checkout action 只能检出到工作区内，对工作区有一定污染，于是我想能不能整成 action，直接一个步骤就解决了不是爽多了

制作 Action#

本文默认读者有一定的 GitHub Actions 基础，包括有 GitHub Actions 的使用经验，并多少了解 GitHub Workflow 的配置语法

1
name: Publish
2

3
on:
4
  workflow_dispatch:
5
  push:
6
    branches:
7
      - main
8

9
jobs:
10
  build:
11
    runs-on: ubuntu-latest
12
    steps:
13
      - name: Checkout
14
        uses: actions/checkout@v3
15
      - name: Install dependencies
16
        run: yarn install --frozen-lockfile
17
      - name: Build
18
        run: yarn build
19
      - name: Push dist
20
        uses: casperdcl/push-dir@v1
21
        with:
22
          message: ${{ github.sha }}
23
          branch: dist
24
          dir: build
25
          history: false

1
ncc build src/index.mjs -o build/dist --target es2022

1
build
2
├── action.yml
3
└── dist
4
    └── index.mjs

1
steps:
2
  # 使用某个分支
3
  - uses: user/repo@branch
4
  # 使用某个分支的某个文件夹
5
  - uses: user/repo/folder@branch

1
steps:
2
  - uses: actions/checkout@v3
3
    with:
4
      repository: user/repo
5
      ref: branch
6
      path: ./some/path
7
      token: ${{ secrets.YOUR_GITHUB_TOKEN }}
8
  - uses: ./some/path

组合操作 (Composite Action)#

组合操作，顾名思义，可以将多个步骤组合成一个可复用的 Action，可以在一定程度上简化 Workflow

一些注意点#

1. uses 必须是确定的，不可是动态的
2. uses 本地操作不能位于工作区之外

主体服务搭建#

Revolt 前后端分离，后端包含非常多的小服务，好在官方提供了 docker 部署方式，不然直接就给劝退了

下面说一下部署和配置细节

1
git clone https://github.com/revoltchat/self-hosted revolt --depth=1
2
cd revolt
3
cp .env.example .env

1
# URL to where the Revolt app is publicly accessible (前端)
2
REVOLT_APP_URL=https://example.com
3

4
# URL to where the API is publicly accessible (后端)
5
REVOLT_PUBLIC_URL=https://api.example.com
6
VITE_API_URL=https://api.example.com
7

8
# URL to where the WebSocket server is publicly accessible (后端 WS)
9
REVOLT_EXTERNAL_WS_URL=wss://ws.example.com
10

11
# URL to where Autumn is publicly available (静态资源服务)
12
AUTUMN_PUBLIC_URL=https://autumn.example.com
13

14
# URL to where January is publicly available (内嵌媒体预览服务)
15
JANUARY_PUBLIC_URL=https://january.example.com
16

17
# URL to where Vortex is publicly available (语音服务)
18
VOSO_PUBLIC_URL=https://vortex.example.com
19
VOSO_WS_HOST=wss://vortex.example.com

1
map $http_host $revolt_upstream {
2
  example.com http://127.0.0.1:5000;
3
  api.example.com http://127.0.0.1:8000;
4
  ws.example.com http://127.0.0.1:9000;
5
  autumn.example.com http://127.0.0.1:3000;
6
  january.example.com http://127.0.0.1:7000;
7
  vortex.example.com http://127.0.0.1:8080;
8
}
9

10
server {
11
  listen 80;
12
  listen 443 ssl http2;
13
  server_name example.com *.example.com;
14

15
  # SSL 自己配
16

17
  if ($http_upgrade) {
18
    # 这里的路径是用来反代 ws 的，脸滚键盘即可，防止和其他服务冲突
19
    rewrite ^(.*)$ /ws_78dd759593f041bc970fd7eef8b0c4af$1;
20
  }
21

22
  location / {
23
    proxy_pass $revolt_upstream;
24
    proxy_set_header Host $host;
25
  }
26

27
  location /ws_78dd759593f041bc970fd7eef8b0c4af/ {
28
    # 注意这里的是带尾斜杠的
29
    proxy_pass $revolt_upstream/;
30
    proxy_http_version 1.1;
31
    proxy_set_header Host $host;
32
    proxy_set_header Connection $http_connection;
33
    proxy_set_header Upgrade $http_upgrade;
34
    # 重要，防止 ws 长时间不发送数据导致超时断开
35
    proxy_read_timeout 24h;
36
  }
37
}

1
docker-compose up -d

1
docker-compose stop

1
docker-compose down

1
docker-compose exec database bash

1
mongosh

1
use revolt
2
db.invites.insertOne({ _id: "邀请码" })

1
apt-get update
2
apt-get install wget -y
3
cd ~
4
wget https://downloads.mongodb.com/compass/mongodb-mongosh_1.1.9_amd64.deb
5
dpkg -i mongodb-mongosh_1.1.9_amd64.deb

语音服务搭建#

1
git clone https://github.com/revoltchat/vortex --depth=1

1
cargo build --release

后记#

坑挺多的，最坑的一点是 nginx 反代 WS

我一开始搭建好的时候，不知道为什么语音持续个一两分钟就会莫名断开，一开始我还以为是服务器问题，但换了好几台都有一样的问题，再后来我去试官方的 demo，却也是好的，我不禁开始怀疑是我的问题

事实证明确实是我的问题，在找朋友一起排查的时候无意中发现语音的 WS 会莫名断开

得知这一关键信息的我终于确定了方向，Google 得知原来还有 proxy_read_timeout 这一设定

nginx 的反代默认读超时是 60s，当 WS 空闲超过这个时间后 nginx 就把连接断开了

API 的 WS 有不停的发心跳包所以幸免于难，但语音的 WS 只有当有人进出或者开闭麦的时候才会传输信息，首当其寄

个人使用体感#

相当不错，难得一见的高性价比而且网络还不错的服务器，带免费的 DDOS 防护，工单客服态度很好。

带有免费的按需 DDoS 防护（还有付费的全天候 DDoS 防护），以及每两周一次的全服务器无差别快照备份，如果有恢复需求可以直接找客服。

另外，对于普通实例，CloudCone 对资源收费是很详细的，分为 CPU、内存、硬盘、IP 四个部分，前三者可以自由定制，额外的公网 IP 需要联系客服申请。

对于普通实例，如果你的服务器处于关机状态，将只收取硬盘以及 IP 的费用，也就是说如果服务器闲置了又不想删掉的话可以关机省钱。（官方说明）

优惠套餐#

注意，如果尚未注册并登录，打开购买链接会跳转至注册帐号页面，注册后即可看到套餐详情

普通可自定义配置价格#

最低配 3.71刀/月（0.00498刀/小时） 注册帐号 后即可创建这种自定义实例

另外还有独立服务器可以购买，XEON X3450、8 GB ECC RAM、2 TB HDD、240 GB SSD、RAID 1，59刀/月起步

DNS 服务#

CloudCone 提供免费的 DNS 服务，普通用户最多可以托管三个域名进来。

CDN 服务#

Cloudcone 也提供 CDN 服务，在 Beta 测试的时候我使用过一个多月，延迟挺低，速度只能说中规中矩，功能超级简单，虽然设置也十分简单就是了……

用来做普通的静态资源加速还是可以的

定价的话是$0.045/GB

网速/性能跑分#

单核、512MB 内存、10GB 硬盘

Speedtest#

bench.sh#

UnixBench#

虚拟#

创建服务器#

进去之后右上角直接注册，来到后台右上角绿色的“+”即可创建服务器。

可以选择创建普通实例或者专用服务器，而且提供免费的 DNS 服务，这里简单介绍一下普通实例。

系统选择#

提供了多种系统的多个版本可供选择，都是64位，有 CentOS、Debian、Ubuntu、Fedora、Scientific Linux，其中 CentOS 提供带最新内核及 BBR 的版本。

实例管理#

创建完之后，初始 root 密码会通过邮件发送给你。

Access 里可以直接重设 root 密码，以防忘记了密码。

Rebuild 里可以重装系统，没有限制次数什么的，想怎么折腾怎么折腾（。

关于升级配置#

Resize 里可以变更你的服务器配置，仅限普通自定义配置实例，只能向上升级，变更之后会立即按照新的配置按小时计费。 不过需要注意的是，如果改变了硬盘大小，那么就需要手动扩容硬盘。

硬盘扩容不会损失数据，老手如果有十足的把握，可以 fdisk 直接上，而萌新建议直接将你的 IP 和 root 密码发给客服，让他们帮你扩容硬盘，如果自己手动操作，稍有不慎就可能会丢失你的所有硬盘数据

付款#

信用卡支持 VISA、Master、美国运通卡。 你也可以使用 PayPal 付款。

Cloudflare Workers#

官网：https://workers.cloudflare.com/

我也不做过多介绍了，可以从官网上了解，简单来说它是个运行 javascript 的 serverless 平台，虽然还说支持 Rust 或者 C 等等，但实际上得将它们编译为 Wasm

有官方客户端 wrangler，但这客户端 bug 是真的多，请做好各种搜 issue 的准备（

以下描述针对免费版计划

为什么值得用：

1. 每天免费调用十万次，超出只会终止而不扣费
2. 最多创建 30 个 worker，管够
3. 赠送一个专门用于调用 worker 的 workers.dev 子域，子域名自定义
4. 可以自定义路由来使用你自己的域名
5. 没有流量限制
6. 可以使用 KV（cf 提供的键值数据库，2020年11月起对免费套餐开放使用了）

局限性：

1. Serverless 的特性所决定的局限性
2. 每个请求限制 10ms CPU 时间（网络 IO 时间不计），无法完成某些太耗算力的任务，例如较复杂的图片处理或者使用 cheerio 这类效率不高的 HTML 解析库
3. （目前）不允许使用 websocket

Telegram Bot#

实现 Telegram Bot 的处理消息有两种方式，长轮询和 webhook，想依靠 serverless 处理则选用 webhook 方式

注意，webhook 每一次被 tg 服务器调用都只能返回一次，因此没办法做到“等待某条消息发送后再xxxx”，只能一次性发送完所有操作

我一般用 Telegraf 框架开发，所以这里主要说下怎么将使用该框架开发的 bot 迁移至 cfworker

1
function isKoaResponse(response) {
2
  return (
3
    typeof response.set === "function" && typeof response.header === "object"
4
  );
5
}
6

7
function answerToWebhook(response, payload = {}, options) {
8
  if (!includesMedia(payload)) {
9
    if (isKoaResponse(response)) {
10
      response.body = payload;
11
      return Promise.resolve(WEBHOOK_REPLY_STUB);
12
    }
13
    if (!response.headersSent) {
14
      response.setHeader("content-type", "application/json");
15
    }
16
    return new Promise((resolve) => {
17
      if (response.end.length === 2) {
18
        response.end(JSON.stringify(payload), "utf-8");
19
        return resolve(WEBHOOK_REPLY_STUB);
20
      }
21
      response.end(JSON.stringify(payload), "utf-8", () =>
22
        resolve(WEBHOOK_REPLY_STUB),
23
      );
24
    });
25
  }
26

27
  return buildFormDataConfig(payload, options.agent).then(
28
    ({ headers, body }) => {
29
      if (isKoaResponse(response)) {
30
        Object.keys(headers).forEach((key) => response.set(key, headers[key]));
31
        response.body = body;
32
        return Promise.resolve(WEBHOOK_REPLY_STUB);
33
      }
34
      if (!response.headersSent) {
35
        Object.keys(headers).forEach((key) =>
36
          response.setHeader(key, headers[key]),
37
        );
38
      }
39
      return new Promise((resolve) => {
40
        response.on("finish", () => resolve(WEBHOOK_REPLY_STUB));
41
        body.pipe(response);
42
      });
43
    },
44
  );
45
}

1
function getKoaLikeResponse(res) {
2
  return new Proxy(
3
    Object.assign(res, {
4
      set: (...args) => res.headers.set(...args),
5
      header: res.headers,
6
    }),
7
    {
8
      set(obj, prop, value) {
9
        if (
10
          prop === "body" &&
11
          ["Object", "Array"].includes(
12
            Object.getPrototypeOf(value).constructor.name,
13
          )
14
        ) {
15
          obj.body = JSON.stringify(value);
16
          obj.headers.set("content-type", "application/json");
17
          return true;
18
        }
19
        return Reflect.set(...arguments);
20
      },
21
    },
22
  );
23
}

1
npm i @cfworker/web cfworker-middware-telegraf telegraf
2
npm i -D webpack webpack-cli

1
const { Telegraf } = require("telegraf");
2
const { Application, Router } = require("@cfworker/web");
3
const createTelegrafMiddware = require("cfworker-middware-telegraf");
4

5
const bot = new Telegraf("BOT_TOKEN");
6

7
// 写 bot 逻辑，但不要 bot.launch()
8

9
const router = new Router();
10

11
// `/SECRET_PATH` 指的是一个不容易猜到的路径，以防止他人访问你的 webhook
12
// 可以滚键盘或者用 UUID 之类的生成，例如 '/d4507ff0-08d1-4160-bad8-1addf587374a'
13
router.post("/SECRET_PATH", createTelegrafMiddware(bot));
14

15
new Application().use(router.middleware).listen();

1
module.exports = {
2
  target: "webworker",
3
  entry: "./index.js",
4
  mode: "production",
5
  node: {
6
    fs: "empty",
7
  },
8
  module: {
9
    rules: [
10
      {
11
        test: /\.mjs$/,
12
        include: /node_modules/,
13
        type: "javascript/auto",
14
      },
15
    ],
16
  },
17
};

1
const Telegraf = require("telegraf");
2
const bot = new Telegraf(TG_BOT_TOKEN);
3

4
// 设置 webhook，请改成你自己的回调地址
5
bot.telegram.setWebhook("https://name.subdomain.workers.dev/SECRET_PATH");
6

7
// 删除 webhook
8
// bot.telegram.deleteWebhook();
9

10
// 查看当前 webhook
11
// bot.telegram.getWebhookInfo().then(console.log);

VUE_CLI_SERVICE_CONFIG_PATH环境变量#

还好，经过搜索，我发现vue-cli-service是支持使用VUE_CLI_SERVICE_CONFIG_PATH环境变量来自定义配置文件的，我们可以添加一个 npm script 像下面这样（Unix 下）

1
VUE_CLI_SERVICE_CONFIG_PATH=my.vue.config.js vue-cli-service build

然而我实际执行确报错“找不到模块my.vue.config.js”

看了下vue-cli-service的源码，获取配置文件的部分是这样的

1
// In loadUserOptions()
2
const configPath =
3
  process.env.VUE_CLI_SERVICE_CONFIG_PATH ||
4
  path.resolve(this.context, "vue.config.js");
5
if (fs.existsSync(configPath)) {
6
  try {
7
    fileConfig = require(configPath);
8

9
    if (typeof fileConfig === "function") {
10
      fileConfig = fileConfig();
11
    }
12

13
    if (!fileConfig || typeof fileConfig !== "object") {
14
      error(
15
        `Error loading ${chalk.bold(
16
          "vue.config.js",
17
        )}: should export an object or a function that returns object.`,
18
      );
19
      fileConfig = null;
20
    }
21
  } catch (e) {
22
    error(`Error loading ${chalk.bold("vue.config.js")}:`);
23
    throw e;
24
  }
25
}

可以看到，configPath会直接取环境变量作为 id 来require，而不会像默认的vue.config.js一样根据上下文来计算绝对路径

虽然看似非常反人类，但仔细想想也能理解这是出于安全考虑

那么解决方法就显而易见了，传个绝对路径进去，例如在 Unix 下可以利用$PWD环境变量

1
VUE_CLI_SERVICE_CONFIG_PATH=$PWD/my.vue.config.js vue-cli-service build

但这衍生出另一个问题，最直接的说，Windows 下没有$PWD，而是%cd%，虽然我们能利用cross-env解决不同操作系统下环境变量设置方式不同的问题，却无法解决 Windows 与 Unix 系统环境变量获取方式不同的问题

既然是 node，就用 node 解决#

一拍大腿之后，曲线救国的方案就出来了，我们可以直接用 node 获取配置的绝对路径，然后作为环境变量来执行npm run build

在 node 中执行命令就要请child_process出场了，梳理一下我们的需求：

1. 执行npm run build
2. 传入VUE_CLI_SERVICE_CONFIG_PATH环境变量
3. 维持原本的输出形式

阅读其文档，最终我选用 spawnSync 方法，相关参数如下

child_process.spawnSync(command[, args][, options])

• command <string> The command to run.
• args <string[]> List of string arguments.
• options <Object>
  • shell <boolean> | <string> If true, runs command inside of a shell. Uses '/bin/sh' on Unix, and process.env.ComSpec on Windows. A different shell can be specified as a string. See Shell Requirements and Default Windows Shell. Default: false (no shell).
  • stdio <string> | <Array> Child’s stdio configuration.
  • env <Object> Environment key-value pairs. Default: process.env.

值得说明的是 options.stdio 这一参数，其中有一条说明

'inherit': Pass through the corresponding stdio stream to/from the parent process. In the first three positions, this is equivalent to process.stdin, process.stdout, and process.stderr, respectively. In any other position, equivalent to 'ignore'.

这正是我们想要的，将子进程的输入输出原封不动的传回给父进程，这样一来体验就与直接执行命令无异（指各种命令行动画和文字颜色这种）

所以最终我们可以像下面这样写个，比如说myBuild.js

1
const { spawnSync } = require("child_process");
2
const { resolve } = require("path");
3

4
spawnSync("npm", ["run", "build"], {
5
  shell: true,
6
  env: {
7
    ...process.env, // 要记得导入原本的环境变量
8
    VUE_CLI_SERVICE_CONFIG_PATH: resolve(__dirname, "my.vue.config.js"),
9
  },
10
  stdio: "inherit",
11
});

然后我们就可以添加一个 npm script 了，"build:my": "node myBuild.js"

拓展#

我们可以做的更通用化一点，接受一个参数来指定配置文件，做到可以写成"build:my": "node build.js my.vue.config.js"这样的效果，这里就不详细说了

关于 redis#

思路及实现#

以下例子均为 PHP 下的实现，用到 phpredis 扩展

1
$time = time();      // 当前时间戳（秒）
2
$ttl = 24 * 60 * 60;  // 一天内
3
$key = 'IP or User ID';  // 这个访问者
4
$limit = 1000;      // 最多允许访问 1000 次
5

6
$line = $time - $ttl;  // TTL 时间线

1
// 时间线后的记录数
2
$count = $redis->zCount($key, $line, '+inf');
3
// 拿到最接近时间线的 score 对应的 value，返回值是数组，没有就是空数组
4
$top_value = $redis->zRangeByScore($key, $line, '+inf', ['limit' => [0, 1]]);
5

6
// 最终要得到的：剩余额度
7
$quota = $limit - $count;
8
// 最终要得到的：额度恢复 1 所需等待的时间，如果没用过就 0
9
$quota_ttl = count($top_value) > 0 ? $redis->zScore($key, $top_value[0]) + $ttl - $time : 0;

1
// 清除旧记录
2
$redis->zRemRangeByScore($key, '-inf', $line);
3
// 记录
4
$redis->zAdd($key, $time, uniqid('', true));
5
// 更新集合的 TTL
6
$redis->expire($key, $ttl);

后记#

拿什么做key是一个需要三思的问题，对于一个固定的访问者用固定的方式访问，它必须也是固定的

比如，如果你设计了自己的 APIKEY 体系，切忌将 APIKEY 作为key，因为 APIKEY 可能是可变的（取决于你自己的设计），而比较妥善的方法是将 APIKEY 所属的用户的 ID 之类的作为key

DOMException: Quota exceeded.#

我的方舟工具箱一直没有给图片使用 CDN，原因是我在着迷 wiki 中看到的 360 图片 CDN 的域名p<x>.qhimg.com(0<=x<=25)都是不支持 SSL 的，无法被 SW 缓存，所以一直使用项目中独立保存的图片，缓存和加载图片都十分缓慢，这一直是一个令我头疼的地方

后记：其实可以白嫖 jsDelivr 的……

而昨天下午我突发奇想搜索了下发现其实是有支持 SSL 的，域名为p<x>.ssl.qhimg.com(0<=x<=6)，这一下我就开心炸了，赶忙写了个 CDN 支持，并使用 Workbox 做运行时缓存

发布，测试，然后 BOOM，一气呵成

很怪，所有静态资源加起来也就 5MB 左右，怎么告诉我直接超额了？

全是不透明响应惹的祸#

先打开缓存列表看看情况，但Content-Length是正常的完全没有问题

经过一番思考（其实是走投无路没得选），我将目光放在了可疑的Response-Type: opaque上

稍微搜索了下，在一则 Stack Overflow 问题 What limitations apply to opaque responses? 中找到了这段话

Opaque Responses & the navigator.storage API

In order to avoid leakage of cross-domain information, there’s significant padding added to the size of an opaque response used for calculating storage quota limits (i.e. whether a QuotaExceeded exception is thrown) and reported by the navigator.storage API.

The details of this padding vary from browser to browser, but for Google Chrome, this means that the minimum size that any single cached opaque response contributes to the overall storage usage is approximately 7 megabytes. You should keep this in mind when determining how many opaque responses you want to cache, since you could easily exceeded storage quota limitations much sooner than you’d otherwise expect based on the actual size of the opaque resources.

意思是，为了避免跨域信息泄漏，在计算储存空间时，不透明响应的大小会被添加大量填充，填充的大小因浏览器而异，对于 Chrome 来说，缓存单个不透明响应将至少占用约 7MB 空间

破案了，那这 100MB 空间确实不够存的

跟跨域请求讲道理#

那么解决问题的关键就是如何让“不透明”响应变为“透明”响应了

再次观察之前的缓存列表，发现由 CSS 请求的字体文件为Response-Type: cors，也就是说字体文件是正确发出了跨域请求的

对比字体文件的请求和其它请求，发现一个很关键的点，字体文件请求头带了origin，而其它有问题的请求没有！

cors	opaque

如果没有携带origin头，CORS 就不会运作，所以我们得到了不透明响应

基于这一设想，我在 MDN 的一个文档 CORS settings attributes 中找到了这些描述

在HTML5中，一些 HTML 元素提供了对 CORS 的支持， 例如 <audio>、<img>、<link>、<script> 和 <video> 均有一个跨域属性 (crossOrigin property)，它允许你配置元素获取数据的 CORS 请求。

…

**默认情况下（即未指定 crossOrigin 属性时），CORS 根本不会使用。**如 Terminology section of the CORS specification 中的描述，在非同源情况下，设置 “anonymous” 关键字将不会通过 cookies，客户端 SSL 证书或 HTTP 认证交换用户凭据。

也就是说，请求没有携带origin头的原因是没有给标签配置crossorigin属性，由于我需要跨域加载的都是静态资源，不需要携带凭据，所以只要给各种标签都配置crossorigin="anonymous"就可以了

于是我开始疯狂的搜索项目中的各种<img>、<link>、<script>标签然后加跨域属性，发布，测试，很好，请求都带上origin头了，并且成功成为了Response-Type: cors的“透明”响应被 Workbox 缓存，储存空间的占用也恢复了正常水平

别高兴的太早#

对于多媒体标签的跨域问题是解决了，其它情况下的请求又如何呢

经过测试与排查，我发现以下几种情况依然会得到不透明响应

1. 在 CSS 中引用的背景图片(background-image)等
2. 通过 JS 控制的但没有设置跨域属性的多媒体加载：常见于各类第三方组件，拿图片懒加载组件举例，一般的懒加载都是先通过 JS 请求图片，加载完成后再给<img>的src赋值，如果这次由 JS 发出的请求没有携带origin头，那么即使你给懒加载的<img>设置跨域属性，你依然会得到不透明响应

解决办法：

1. 改用<img>做背景图，你可以通过position: absolute之类的 CSS 手段让<img>不占据空间，达到和background-image一样的效果
2. 这个解决方法因实际情况而异了，例如我使用的是 Vue-Lazyload 组件，好在它提供懒加载组件的功能，因此我将原本的懒加载图片改为懒加载一个包含<img crossorigin="anonymous">的组件，这样就不存在用 JS 预加载图片的过程，曲线救国

另外，为了确保不会缓存到不透明响应，强烈建议配置 Workbox 时不要允许缓存返回码为0的请求

例如我使用 Vue 的 PWA 插件，原本的配置（局部）是这样的：

1
module.exports = {
2
  pwa: {
3
    workboxOptions: {
4
      runtimeCaching: [
5
        {
6
          urlPattern: /.../,
7
          handler: "CacheFirst",
8
          options: {
9
            cacheableResponse: {
10
              statuses: [0, 200],
11
            },
12
          },
13
        },
14
      ],
15
    },
16
  },
17
};

因为最初写的时候照抄了官方示例因此带上了0，发生这次事件以后，我将statuses: [0, 200]改为了statuses: [200] :)

清除旧缓存#

做完了以上步骤仍没有结束，因为用户如果在之前使用过旧版本的 PWA 应用，遗留的不透明请求缓存可能会产生副作用

如果你的缓存机制为CacheFirst，仍会得到由 Service Worker 返回的不透明请求，由于crossorigin="anonymous"的应用，这些请求将会被浏览器拒绝，导致资源无法加载

我个人的解决方法是在更新后判断是否是从之前的旧版本升级的，如果是的话调用 CacheStorage 的 API 清除运行时缓存并重载页面

例如在页面比较前的位置加入下方的 script

1
(function () {
2
  var versionFlag = localStorage.getItem("versionFlag");
3
  var currentFlag = "20191211"; // 随便使用一个字符串
4
  // caches 是 CacheStorage 的一个实例
5
  if (!(versionFlag && versionFlag === currentFlag) && caches) {
6
    caches.keys().then(function (names) {
7
      Promise.all(
8
        names
9
          .filter(function (name) {
10
            return /runtime/.test(name);
11
          })
12
          .map(function (name) {
13
            return caches.delete(name);
14
          }),
15
      ).then(function () {
16
        localStorage.setItem("versionFlag", currentFlag);
17
        window.location.reload();
18
      });
19
    });
20
  }
21
})();

寻找合适的等宽字体#

经过一番搜索，我找到了四款我觉得不错的包含中文的等宽字体，但实际上只有前两款可以在 VSCode 中正常等宽，非常奇怪（终端中只允许使用等宽字体，能用就说明等宽）

Name	Used Font Family	In VSCode	In Terminal
更纱黑体	'Sarasa Mono SC'
M+ FONTS	'M+ 1m'
雅黑等宽	'Microsoft YaHei Mono'
Yasolas	Yasolas

后来我在 issue Monospacing broken by Chinese character #14589 中找到了答复，由于 VSCode 是基于 Electron 的，前端由 Chromium 渲染，这种字体渲染问题很可能是 Chromium 导致的，VSCode 侧无能为力

This is an upstream issue (possibly within Chromium), and there are no known workarounds that we could implement on our side. This means there is no possible code change for us to do in VS Code sources to improve things.

但我不想用中英等宽字体写代码#

你可以从截图中看出，这些等宽字体会使一个全角字符的宽度严格等于两个半角字符的宽度

他们的宽高比最大只有0.5，这导致半角字符看起来特别“瘦”，拿来写代码……反正我是会瞎的

由于只是在 Markdown 之类的格式下需要使用这类字体，因此我们完全可以独立配置

1
{
2
  "[markdown]": {
3
    "editor.fontFamily": "'Sarasa Mono SC'"
4
  }
5
}

这样就不会影响全局的设置了

用例与简单说明#

与 Travis CI 相似，GitHub Actions 也使用 YAML 作为配置文件的格式，放在.github/workflows文件夹下

这是一个简单的示例，作用是当我更新 vue 项目文件时自动构建 dist 并发布到 GitHub Pages，然后推送到我的 Coding Pages 所在的远程仓库

下面我简单描述一下 GitHub Actions 中常用的语法，使你可以大概了解它能做什么

• on规定什么时候触发 workflow
  • 可以由push,pull_request,release等事件触发
    • 例如release这种事件可以定义具体类型
    • push,pull_request可以规定涉及具体分支branches、标签tags、路径path时触发
      • 路径可以用包含（path）或忽略（paths-ignore）两种模式，支持通配符，包含模式下可以用!声明例外目录
  • 可以由schedule定时触发，使用 cron 表达式
• jobs是 workflow 的组成部分，每个 job 是在不同的容器内并行运行的，之间无法直接相互干涉
  • needs可以声明一个工作依赖另一个或多个 job，当这些 job 被完成后才会开始执行
  • runs-on系统环境，目前支持以下几个（以后估计会慢慢加）
    1. Windows Server 2019: windows-latest
    2. Ubuntu 18.04: ubuntu-latest or ubuntu-18.04
    3. Ubuntu 16.04: ubuntu-16.04
    4. macOS X Catalina 10.15: macos-latest
  • env定义环境变量，作用域为整个 job
  • if规定当满足某些条件时才执行这个 job
  • steps是 job 的组成部分，step 是顺序执行的
    1. env定义环境变量，作用域为当前 step，且你对环境变量的任何更改都不会带到其它 step 或者 job 中
    2. if规定当满足某些条件时才执行这个 step，并且可以使用状态检查函数，根据上一个 step 的状态决定是否运行
    3. uses声明使用其它 action 作为你的 step，也就是使用其他人写好的 action
    4. with为 uses 的 action 传入参数，具体看你使用的 action 的说明
    5. run运行命令，支持多行，具体看文档
    6. shell定义 run 所使用的 shell，具体看文档
    7. continue-on-error即使有错误也继续往下运行 step
    8. timeout-minutes规定该 step 的超时时间
  • timeout-minutes规定该 job 的超时时间
  • strategy定义一些矩阵供 job 使用，详细看文档
  • container容器具体信息，不规定时所有 step 将直接在runs-on规定的环境上运行，详细看文档
  • services声明使用哪些服务，例如nginx或redis等

Tips#

1. 涉密内容应使用 secrets（如何使用请阅读 Contexts and expression syntax），在项目 settings 中可以设置，此时 workflow 的日志中所有与 secrets 一致的内容都会用***替换；基于这一特性，若你想隐藏日志中会出现的某些词句，即使它们不需要被当做涉密变量在 workflow 中使用，你也可以将它们设置成 secrets
2. 可以使用 actions/cache 来缓存一些可以重复利用的文件，例如 node_modules，可以节省时间减少网络开销等
3. 当你觉得他人开发的 action 与你的需求相当贴合但就是差了那么一丢丢时，你可以 fork 并自行修改，然后直接用自己改过的 action

坑#

1. 只有push,pull_request事件触发的 workflow 可以使用 actions/cache，详见 issue#64
2. 在if内无法访问 secrets 上下文
3. 在if内无法访问同级env
   • 例如job.<job_id>.step.if只能访问job.<job_id>.env中定义的环境变量，而不能访问job.<job_id>.step.env中定义的环境变量
4. 综合 2 和 3，2 的变通解决方式是在上级env中声明一个环境变量来使用 secrets 的值，并且由于 3 的限制，你只能在 step 上这么操作
5. 由于env的本质是字符串，因此在if中使用env时请注意数据类型
   • 例如在 job 中声明环境变量test: ${{ true }}，在 step 的 if 中使用时，条件应当用env.test == 'true'，而不是env.test == true
6. workflow 中产生的事件无法直接触发另一个 workflow 的运行，详见 About workflow events
   • 例如 A 是定时运行，会往项目 push 代码，B 会在 push 事件发生时触发，则 A 的运行无法触发 B

基础#

这部分主要是开始写油猴脚本前应当有所了解的知识

1
const xhr = (option) =>
2
  new Promise((resolve, reject) => {
3
    GM.xmlHttpRequest({
4
      ...option,
5
      onerror: reject,
6
      onload: resolve,
7
    });
8
  });

进阶#

这部分主要是写脚本的过程中有可能遇到的一些难点的较优解决方法

1
<ul class="list">
2
  <li class="item">
3
    <img class="image" />
4
    ...
5
  </li>
6

7
  <li>...</li>
8
</ul>

1
<!-- Init: showA = true; showB = false; -->
2
<ul class="list">
3
  <li class="item">
4
    <div
5
      v-if="showA"
6
      class="item-a"
7
      @click="showA = false; doSth().then(() => { showB = true });"
8
    >
9
      ...
10
    </div>
11
    <div v-if="showB" class="item-b">...</div>
12
    ...
13
  </li>
14

15
  <li>...</li>
16
</ul>

1
const findItemB = ($item) =>
2
  new Promise((resolve, reject) => {
3
    if ($item.length === 0) reject();
4
    // 有可能此时 .item-b 已经出现，所以先检查下
5
    const $itemB = $item.find(".item-b");
6
    if ($itemB.length > 0) {
7
      resolve($itemB);
8
      return;
9
    }
10
    // 监视 .item 的 DOM 树 childList 变化
11
    new MutationObserver((mutations, self) => {
12
      mutations.forEach(({ addedNodes }) => {
13
        addedNodes.forEach((node) => {
14
          if (node.className !== ".item-b") return;
15
          self.disconnect();
16
          resolve($(node));
17
        });
18
      });
19
    }).observe($item[0], { childList: true });
20
  });
21

22
$(".list").click(async ({ target }) => {
23
  if (target.className !== "item-a") return;
24
  const $itemB = await findItemB($(".item:hover"));
25
  // do something with $itemB
26
});

补充#

0. 前置准备#

想要完成上述操作，我们需要

1. 一台 openwrt 路由器或自建的软路由
2. 一个位于内网的 linux，可以是 WSL 或者虚拟机，如果你是软路由的话也可以尝试直接利用 我个人最推荐 WSL，它最为方便，WSL 大法好
3. nginx + nginx-rtmp-module

后续示例均为使用 WSL 与 openwrt 路由器

1. 编译带 nginx-rtmp-module 的 nginx#

此处假设我们将 nginx 装到/opt下，我编译的是写这篇文章的时候最新的 stable version nginx-1.16.1

1
# 安装依赖
2
apt-get install -y build-essential libpcre3 libpcre3-dev libssl-dev zlib1g-dev git
3

4
# 获取 nginx 源码
5
cd /opt
6
wget https://nginx.org/download/nginx-1.16.1.tar.gz
7
tar zxvf nginx-1.16.1.tar.gz
8
cd nginx-1.16.1
9

10
# 获取 nginx-rtmp-module
11
git clone https://github.com/arut/nginx-rtmp-module.git --depth=1
12

13
# configure
14
./configure --prefix=/opt/nginx  --add-module=./nginx-rtmp-module/ --with-http_ssl_module

然后稍等一下，不急着make

使用gcc -dumpversion命令查看一下自己的 gcc 版本，特别是如果你用的是 WSL，预装的 gcc 应该是 8，版本是 7 及以上的必须改 makefile 来忽略 nginx 源码中 switch-case 没加 break 造成的 implicit fallthrough error

编辑objs/Makefile，在下面所示的这行上加个-Wno-implicit-fallthrough

1
# 把
2
CFLAGS =  -pipe  -O -W -Wall -Wpointer-arith -Wno-unused-parameter -Werror -g
3
# 改为
4
CFLAGS =  -pipe  -O -W -Wall -Wpointer-arith -Wno-unused-parameter -Werror -g -Wno-implicit-fallthrough

好，接下来就可以继续了

1
make && make install

2. 配置 nginx#

1
# 当前目录 /opt/nginx-1.16.1
2
cp nginx-rtmp-module/stat.xsl /opt/nginx/html
3
chown -R www:www /opt/nginx/html

接着修改/opt/nginx/conf/nginx.conf，首先将最前面#user nobody;修改为user www;

在 http 配置块前加上 rtmp 配置

1
rtmp {
2
    server {
3
        listen 1935;
4
        application app {
5
            live on;
6
        }
7
    }
8
}

在 http 的 server 配置块中加入 rtmp 状态页面配置，location /直接修改原有即可

1
location / {
2
    rtmp_stat all;
3
    rtmp_stat_stylesheet stat.xsl;
4
}
5

6
location /stat.xsl {
7
    root /opt/nginx/html;
8
}

最好将 http 的 server 中的 listen 也改一下，因为我们编译的这个 nginx 只是拿来做推流劫持的，不会用来做别的事，所以不需要占用 80 端口，改成其他的可以避免以后做什么事需要用 80 端口导致冲突

在此处我改为10080，见下方完整配置

于是最终你的配置文件应该像这样（我删掉了自带注释）

1
user  www;
2
worker_processes  1;
3

4
events {
5
    worker_connections  1024;
6
}
7

8
rtmp {
9
    server {
10
        listen 1935;
11
        application app {
12
            live on;
13
        }
14
    }
15
}
16

17
http {
18
    include       mime.types;
19
    default_type  application/octet-stream;
20

21
    sendfile           on;
22
    keepalive_timeout  65;
23

24
    server {
25
        # 改一下监听端口
26
        listen       10080;
27
        server_name  localhost;
28

29
        location / {
30
            rtmp_stat all;
31
            rtmp_stat_stylesheet stat.xsl;
32
        }
33

34
        location /stat.xsl {
35
            root /opt/nginx/html;
36
        }
37
    }
38
}

接着测试一下配置文件，没错误就可以启动 nginx 了

1
# 测试配置
2
/opt/nginx/sbin/nginx -t
3
# 启动
4
/opt/nginx/sbin/nginx

3. 劫持 twitch 推流#

接下来只要劫持 live.twitch.tv 到 nginx 就行

需要注意的是，不能使用 hosts 方式，这对新版本的 PS4 系统无效，我试了下确实如此，所以我们使用 iptables 做 DNAT

首先用dig或者nslookup查看一下我们当前网络的 live.twitch.tv 被解析到哪里

1
# 以 dig 为例，没有的话需要安装
2
apt-get install -y dnsutils
3

4
dig live.twitch.tv
5

6
# ; <<>> DiG 9.11.5-P4-5.1-Debian <<>> live.twitch.tv
7
# ;; global options: +cmd
8
# ;; Got answer:
9
# ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36451
10
# ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
11
#
12
# ;; QUESTION SECTION:
13
# ;live.twitch.tv.                        IN      A
14
#
15
# ;; ANSWER SECTION:
16
# live.twitch.tv.         600     IN      CNAME   live.video.twitch.tv.
17
# live.video.twitch.tv.   600     IN      CNAME   live-beta.video.twitch.tv.
18
# live-beta.video.twitch.tv. 600  IN      CNAME   live-hkg.twitch.tv.
19
# live-hkg.twitch.tv.     600     IN      A       45.113.128.181
20
# live-hkg.twitch.tv.     600     IN      A       45.113.128.147
21
# live-hkg.twitch.tv.     600     IN      A       45.113.128.110
22
#
23
# ;; Query time: 312 msec
24
# ;; SERVER: 192.168.123.1#53(192.168.123.1)
25
# ;; WHEN: Fri Sep 13 15:14:30 CST 2019
26
# ;; MSG SIZE  rcvd: 321

我们可以看到记录有 3 个 IP，都在45.113.128.0/24中，所以我们就 DNAT 这个网段的 1935 端口到 nginx 所在设备的 1935 端口就行

在 openwrt 路由器或软路由上执行

1
iptables -t nat -I PREROUTING -d 45.113.128.0/24 -p tcp --dport 1935 -j DNAT --to-destination 192.168.123.2:1935

我在 WSL 上运行 nginx，所以需要转发到我 PC 上，192.168.123.2是我 PC 的内网 IP，建议在路由器上配置给相应设备分配静态 IP

注意：如果你使用 WSL 或虚拟机，请关闭 Winddows 防火墙，或创建规则放行 1935 端口；若使用内网中的 linux 机器也应当检查防火墙确保端口开放

4. 开启 PS4 直播推流#

按下 share 键打开菜单，有个“播放游玩过程”，选 twitch 然后按说明绑定账号，设置推流分辨率之类的

开始推流之后访问 rtmp stat 页面，例如我自己这种部署方式就是 http://127.0.0.1:10080 ，然后应该就能看到 live streams 下方出现了一条记录

如果 app 写的是[EMPTY]的话那么 rtmp 地址就是rtmp://127.0.0.1:1935/app/ 否则应该是rtmp://127.0.0.1:1935/app/xxx

然后我们拿一个支持 rtmp 的播放器测试一下，顺利的话就应该能看到 PS4 的画面了（好耶

5. 推流到直播平台#

有两种方式，看自己需求选择

1
push rtmp://js.live-send.acg.tv/live-js/?streamname=[name]&key=[key];

6. 自启动#

1
Set ws = CreateObject("Wscript.Shell")
2
ws.run "wsl /opt/nginx/sbin/nginx", vbhide

后记#

这个方法最大的缺点是，无法与加速器同时使用

目前市面上的加速器基本都是在 PC 上起一个 TAP Adapter 然后让 PS4 连，这样所有的流量都会走加速器出去，iptables 无法劫持

不过有些加速器也有提供路由器插件，我没有实际用过因为没有“支持”插件的路由器，说不定这种情况下有方法可以实现同时使用

另外，如果路由器上用的是 DNSMasq，配合 ipset 应该可以实现自动将 live.twitch.tv 的 IP 加到 ipset 中，然后 iptables 规则就可以直接使用 ipset，而不用自己手写网段了

参考#

• 搭建 PS4 本地直播服务器
• 如何用最低的成本转播PlayStation 4到国内的直播平台
• linux下编译nginx1.0.15报错：Implicit fallthrough error

为已有项目添加 PWA 支持#

引导用户添加 PWA 应用#

在应用中可以自行通过提示等方式引导用户手动添加 PWA 应用，以下列举目前我所知道的添加方式

1
new Vue({
2
  data: {
3
    deferredPrompt: false,
4
  },
5
  created() {
6
    window.addEventListener("beforeinstallprompt", (e) => {
7
      e.preventDefault();
8
      this.deferredPrompt = e;
9
    });
10
  },
11
  methods: {
12
    installPWA() {
13
      if (this.deferredPrompt) {
14
        this.deferredPrompt.prompt();
15
        this.deferredPrompt = false;
16
      }
17
    },
18
  },
19
});

1
<button @click="$root.installPWA" :disabled="$root.deferredPrompt===false">
2
  添加到主屏幕
3
</button>

手动添加方式#

iOS ≥ 11.3 可以在 Safari 中打开，点击浏览器底部的分享按钮，选择“添加到主屏幕”

PC 与 Android 的 Chrome 可通过右上角菜单添加（此处以 m.weibo.cn 为例）

PC	Android

Service Worker 的更新#

这是开发 PWA 应用时需要考虑的一个重要问题

由于 Service Worker 的更新机制（扩展阅读：【Service Worker】生命周期那些事儿），直接单纯的刷新页面并没有结束当前 session，因此依然是旧的 SW 在接管页面，新的 SW 仍旧是 waiting 状态

想要实现在不结束 session 的情况下更新 SW，必须使用 skipWaiting，目前有两种常见的处理方法

注：以下方法中提到的registerServiceWorker.js是由 PWA 插件在src目录中自动生成的，其作用是注册 SW 以及提供其生命周期钩子，具体可以看该 npm 包 register-service-worker

1
self.addEventListener("message", (event) => {
2
  if (event.data && event.data.type === "SKIP_WAITING") {
3
    self.skipWaiting();
4
  }
5
});

1
updated(reg) {
2
  // 当控制页面的 SW 改变时刷新
3
  navigator.serviceWorker.addEventListener('controllerchange', () => {
4
    window.location.reload();
5
  });
6
  // 接下来询问用户是否更新并重载应用
7
  // 用户同意则执行以下语句
8
  reg.waiting.postMessage({ type: 'SKIP_WAITING' });
9
}

1. 数据预处理#

还是要感谢 graueneko 等人的工作，已经将干员数据整理成了 json 格式，可以方便的直接拿来使用

那么首先需要明确，要做的是一个公开招募计算器，得到最终结果的算法大致如下

1. 计算指定词条的所有排列组合方案
2. 对每种方案，找到满足这些词条的干员，并对方案进行评分
3. 按评分对所有有效方案进行排序

实现的重点是第2步，而干员数据的结构是干员->词条，每当我们想寻找满足某些词条的干员，我们都必须把列表遍历一遍，这是非常麻烦的

因此我们可以换一种储存方式，使结构变为词条->干员，这样比如我们想寻找同时拥有词条A和词条B的干员，只需要求A和B的交集就行了

以下是示例：

1
import { get } from "axios";
2
import _ from "lodash";
3

4
const akhr = "https://graueneko.github.io/akhr.json";
5

6
async function pullData() {
7
  let json = await get(akhr).then((r) => r.data);
8

9
  //将干员按照稀有度从高到低排序，后续输出的时候就不用再排序了
10
  json.sort((a, b) => b.level - a.level);
11

12
  let characters = []; //角色列表
13
  let data = {}; //词条数据
14
  let charTagSum = 0;
15

16
  for (let character of json) {
17
    if (character.hidden) continue;
18
    let { level, name, sex, tags, type } = character;
19
    //将性别和干员种类也加入词条中
20
    tags.push(`${sex}性干员`);
21
    tags.push(`${type}干员`);
22
    //将干员放入 characters 数组，后续直接用其在数组中的 index 指代
23
    let p =
24
      characters.push({
25
        n: name, //名字
26
        r: level, //稀有度
27
      }) - 1;
28
    //储存：词条->干员
29
    for (let tag of tags) {
30
      if (!data[tag]) data[tag] = [];
31
      data[tag].push(p);
32
    }
33
    charTagSum += tags.length;
34
  }
35

36
  let tagCount = _.size(data);
37
  return {
38
    characters,
39
    data,
40
    //这是后续计算评分用的数据（来自 graueneko）
41
    avgCharTag: charTagSum / tagCount,
42
  };
43
}

然后就能得到这样子的数据结构

1
{
2
  "characters": [
3
    { "n": "推进之王", "r": 6 },
4
    { "n": "闪灵", "r": 6 },
5
    { "n": "夜莺", "r": 6 },
6
    { "n": "伊芙利特", "r": 6 },
7
    { "n": "能天使", "r": 6 },
8
    { "n": "银灰", "r": 6 },
9
    { "n": "星熊", "r": 6 },
10
    { "n": "塞雷娅", "r": 6 },
11
    { "n": "德克萨斯", "r": 5 },
12
    { "n": "凛冬", "r": 5 },
13
    { "n": "白面鸮", "r": 5 },
14
    { "n": "赫默", "r": 5 },
15
    { "n": "华法琳", "r": 5 },
16
    { "n": "红", "r": 5 },
17
    { "n": "狮蝎", "r": 5 },
18
    { "n": "崖心", "r": 5 },
19
    { "n": "食铁兽", "r": 5 },
20
    { "n": "普罗旺斯", "r": 5 },
21
    { "n": "蓝毒", "r": 5 },
22
    { "n": "守林人", "r": 5 },
23
    { "n": "陨星", "r": 5 },
24
    { "n": "白金", "r": 5 },
25
    { "n": "初雪", "r": 5 },
26
    { "n": "真理", "r": 5 },
27
    { "n": "梅尔", "r": 5 },
28
    { "n": "幽灵鲨", "r": 5 },
29
    { "n": "因陀罗", "r": 5 },
30
    { "n": "临光", "r": 5 },
31
    { "n": "雷蛇", "r": 5 },
32
    { "n": "火神", "r": 5 },
33
    { "n": "可颂", "r": 5 },
34
    { "n": "清道夫", "r": 4 },
35
    { "n": "红豆", "r": 4 },
36
    { "n": "末药", "r": 4 },
37
    { "n": "调香师", "r": 4 },
38
    { "n": "夜烟", "r": 4 },
39
    { "n": "远山", "r": 4 },
40
    { "n": "砾", "r": 4 },
41
    { "n": "暗索", "r": 4 },
42
    { "n": "阿消", "r": 4 },
43
    { "n": "白雪", "r": 4 },
44
    { "n": "流星", "r": 4 },
45
    { "n": "杰西卡", "r": 4 },
46
    { "n": "地灵", "r": 4 },
47
    { "n": "杜宾", "r": 4 },
48
    { "n": "艾丝黛尔", "r": 4 },
49
    { "n": "慕斯", "r": 4 },
50
    { "n": "霜叶", "r": 4 },
51
    { "n": "缠丸", "r": 4 },
52
    { "n": "蛇屠箱", "r": 4 },
53
    { "n": "古米", "r": 4 },
54
    { "n": "角峰", "r": 4 },
55
    { "n": "芬", "r": 3 },
56
    { "n": "香草", "r": 3 },
57
    { "n": "翎羽", "r": 3 },
58
    { "n": "芙蓉", "r": 3 },
59
    { "n": "安赛尔", "r": 3 },
60
    { "n": "炎熔", "r": 3 },
61
    { "n": "史都华德", "r": 3 },
62
    { "n": "克洛丝", "r": 3 },
63
    { "n": "安德切尔", "r": 3 },
64
    { "n": "梓兰", "r": 3 },
65
    { "n": "玫兰莎", "r": 3 },
66
    { "n": "米格鲁", "r": 3 },
67
    { "n": "夜刀", "r": 2 },
68
    { "n": "杜林", "r": 2 },
69
    { "n": "12F", "r": 2 },
70
    { "n": "巡林者", "r": 2 },
71
    { "n": "黑角", "r": 2 },
72
    { "n": "Lancet-2", "r": 1 },
73
    { "n": "Castle-3", "r": 1 }
74
  ],
75
  "data": {
76
    "近战位": [
77
      0, 5, 6, 7, 8, 9, 13, 14, 15, 16, 25, 26, 27, 28, 29, 30, 31, 32, 37, 38,
78
      39, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 62, 63, 64, 68, 70
79
    ],
80
    "费用回复": [0, 8, 9, 31, 32, 52, 53, 54],
81
    "输出": [
82
      0, 4, 5, 6, 14, 15, 17, 18, 19, 21, 23, 26, 28, 29, 31, 32, 35, 41, 42,
83
      44, 46, 47, 48, 54, 58, 59, 60, 62
84
    ],
85
    "高级资深干员": [0, 1, 2, 3, 4, 5, 6, 7],
86
    "女性干员": [
87
      0, 1, 2, 3, 4, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21,
88
      22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39,
89
      40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 52, 53, 54, 55, 57, 59, 61,
90
      62, 63, 64, 65, 69
91
    ],
92
    "先锋干员": [0, 8, 9, 31, 32, 52, 53, 54, 64],
93
    "远程位": [
94
      1, 2, 3, 4, 10, 11, 12, 17, 18, 19, 20, 21, 22, 23, 24, 33, 34, 35, 36,
95
      40, 41, 42, 43, 55, 56, 57, 58, 59, 60, 61, 65, 66, 67, 69
96
    ],
97
    "支援": [1, 2, 5, 7, 9, 10, 12, 44, 70],
98
    "治疗": [1, 2, 7, 10, 11, 12, 27, 33, 34, 50, 55, 56, 69],
99
    "医疗干员": [1, 2, 10, 11, 12, 33, 34, 55, 56, 69],
100
    "群攻": [3, 20, 25, 36, 40, 45, 57],
101
    "削弱": [3, 20, 22, 35, 41],
102
    "术师干员": [3, 35, 36, 57, 58, 65, 66],
103
    "狙击干员": [4, 17, 18, 19, 20, 21, 40, 41, 42, 59, 60, 67],
104
    "男性干员": [5, 51, 56, 58, 60, 66, 67, 68, 70],
105
    "近卫干员": [5, 25, 26, 44, 45, 46, 47, 48, 62, 70],
106
    "防护": [6, 7, 27, 28, 29, 30, 37, 49, 50, 51, 63],
107
    "重装干员": [6, 7, 27, 28, 29, 30, 49, 50, 51, 63, 68],
108
    "控场": [8, 13, 24],
109
    "资深干员": [
110
      8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26,
111
      27, 28, 29, 30
112
    ],
113
    "快速复活": [13, 37],
114
    "特种干员": [13, 14, 15, 16, 37, 38, 39],
115
    "生存": [14, 25, 26, 29, 42, 45, 48, 62],
116
    "位移": [15, 16, 30, 38, 39],
117
    "减速": [16, 23, 40, 43, 47, 61],
118
    "爆发": [19],
119
    "辅助干员": [22, 23, 24, 43, 61],
120
    "召唤": [24],
121
    "新手": [64, 65, 66, 67, 68]
122
  },
123
  "avgCharTag": 12.275862068965518
124
}