他那边是怎么做的#

顺手把他的仓库扒了一遍。他的站也是 fork 的 Firefly，仓库公开，qwc-ch/Firefly。

实现全在 .github/ 下面，一共三个文件：

流程是这样的：申请人在 Issue 表单里填站点名、主站链接、友链页地址；workflow 监听到 issues: [opened] 就启动，跑脚本去访问那个友链页，确认页面上确实有他的站，然后改 friendsConfig.ts 并提交。

还有个细节我觉得挺聪明：触发条件里还带了 issue_comment: [created]，而且只有 Issue 作者本人的回复才会重新跑一遍。申请人第一次没挂链接被拒了，改完自己回一句，机器人重新验一次，不用关掉重开。

入口也不是什么站内表单，就是一条链接：

1
https://github.com/qwc-ch/Firefly/issues/new?template=friend-request.yml

一个反直觉的点：这事不需要服务端#

搜「自动友链」的时候翻到一篇写得很细的文章，讲的是把友链数据抽成 links.json、把站切成 SSR、再加一个 API 接口负责校验和写文件。看完我一度以为得动构建模式。

扒完他的仓库才发现，他压根没上 SSR。站还是纯静态的，部署在 GitHub Pages（deploy.yml 里就是 on: push: branches: [master]）。

关键在于：校验和写入不发生在访客访问的时候，而是发生在 GitHub Actions 的容器里。

• 机器人跑在 GitHub 的机器上，改文件、提交、推送，都是它干的
• 推送触发平台重新构建，新友链就出现在页面上了

所以静态站完全够用。那篇文章里的 SSR 是作者自己站的部署方式，不是这件事的必要条件。

但他的脚本不能直接抄#

有三处我这边过不去。

1
const friendBlocks = [...listMatch[1].matchAll(/\{([\s\S]*?)\n\t\},?/g)].map((item) => item[1]);
2
return friendBlocks.map((block) => ({
3
  title: extractString(block, 'title'),
4
  imgurl: extractString(block, 'imgurl'),
5
  desc: extractString(block, 'desc'),
6
  siteurl: extractString(block, 'siteurl'),
7
  tags: extractTags(block),
8
  weight: extractNumber(block, 'weight', 10),
9
  enabled: extractBoolean(block, 'enabled', true),
10
  issue_id: extractNumber(block, 'issue_id', 0),
11
}));

1
const anchor = 'export const friendsConfig: FriendLink[] = [';
2
const at = raw.indexOf(anchor);
3
const updated =
4
  raw.slice(0, at + anchor.length) + eol + entry + raw.slice(at + anchor.length);

1
- run: pnpm install --frozen-lockfile
2
- run: pnpm exec playwright install --with-deps chromium

1
- name: Setup Node.js
2
  uses: actions/setup-node@v4
3
  with:
4
    node-version: "22"
5

6
- name: Process friend request
7
  uses: actions/github-script@v7
8
  with:
9
    github-token: ${{ secrets.GITHUB_TOKEN }}
10
    script: |
11
      const path = require('node:path');
12
      const handler = require(path.join(process.env.GITHUB_WORKSPACE, '.github/scripts/auto-friend-link.cjs'));
13
      await handler({ github, context, core });

我的三件套#

同样是三个新增文件，职责划得很清楚：

友链页那边的入口做成这样：

原来的「发评论区 / 发邮件」那条路我没删，压缩成一行小字留在按钮下面。用 GitHub 的门槛确实有，得给人留个后路。

校验的三项#

另外做了两个防呆。

字段里的换行和引号会压平转义。有人手打 Issue 的时候如果在「网站名称」里塞一段 "]; 加换行，不处理就会把 friendsConfig.ts 撕成语法错误。

还有 label 不存在时不能让整个 job 挂掉。GitHub API 对不存在的 label 直接返回 422，流程会当场炸掉，所以 addLabels 外面包了 try/catch，workflow 里也顺手 gh label create ... || true 先建一遍。

### 网站名称 读不出来#

Issue 表单提交之后，正文长这样：

1
### 网站名称
2

3
测试小站
4

5
### 网站链接
6

7
https://example.com

我一开始按 \n### 切分，每块的第一行当字段名。写完跑单元测试，发现第一个字段永远解析不出来。

原因挺蠢的：正文开头就是 ### 网站名称，它前面没有换行，所以没被切走，留在了第一块里，字段名变成带 ### 前缀的字符串，怎么都匹配不上。

修法是在清洗字段名时补一句：

1
String(label).replace(/^#+\s*/, '')   // split 后第一块的 label 会带 "### " 前缀

还有个更值得记的教训：测试得走生产路径。

我第一版测试是自己在测试里手动拼了个对象塞进去测的，跑得干干净净——因为它压根没碰真正解析 Issue 正文的那段代码。后来把字段整理抽成 buildForm()，测试和主流程共用同一个函数，上面那个 bug 才浮出来。

极简流程#

要复刻的话，需要动的就四处：

1. .github/ISSUE_TEMPLATE/friend-request.yml —— 申请表，字段按自己的站点信息改
2. .github/scripts/auto-friend-link.cjs —— 校验和写入，改开头 SITE_INFO 里的域名
3. .github/workflows/auto-friend-link.yml —— 触发
4. 友链页加一个入口按钮

然后两个仓库设置：

1
Settings → General → Features → 勾上 Issues
2
Settings → Actions → General → Workflow permissions → Read and write

第一条必须开——fork 出来的仓库 GitHub 默认把 Issues 关着，不开的话申请链接直接 404，模板文件在不在都一样。

第二条是给机器人 push 配置用的，默认就是 Read and write，但如果之前手动收紧过，这里不放开提交会失败。

前置条件就这些。零依赖、零服务器，整套东西三个文件。