im0o a40bd6a01b 历史记录:每条可展开 diff,连续保存合并进 5 秒窗
备份存的是「改动前」,所以一条记录的 diff 两端是它自己和更新一份的
状态(最新一条对比当前文件)。行级 diff 先掐公共前后缀再做 LCS,一次
改动通常只碰几行,表撑得住;大面积不同时退化成整段删增。

合并窗做在服务端而不是前端防抖:普通保存(opts.merge)发现最新备份
还在窗内就不新建,连点删除共享一条历史、一步撤回。窗锚定在这一串的
第一下,不滚雪球;还原、导入、撤回重做不合并,各占一条。合并时没有
备份文件,重载失败的还原改用刚读出的原文写回。顺带消除了备份名只精
确到秒、同秒保存互相覆盖的隐患。
2026-08-12 13:17:11 +08:00
2026-08-11 21:14:31 +08:00
2026-08-10 04:10:17 +08:00

Patchbay

一个跑在服务器上的网页,用来编辑那台机器上 mihomo 的 config.yaml 并让改动生效。

核心动作是把某一路入站接到某一个出站上——名字取自录音棚的插线板。典型用途是给每个容器开一个端口,各自指定走哪条线路。

聚合订阅不在范围内(那是 Sub-Store 的活),安装升级内核也不在(那是 mihomo-up.sh 的活)。

术语以 CONTEXT.md 为准。为什么这么设计记在仓库外面的 docs/adr/。

跑起来

需要 Bun 1.3 以上。

bun install
cp .env.example .env   # 按里面的注释填
bun run start          # 打包前端并启动,默认 http://127.0.0.1:7580

首次启动会生成一个访问令牌,打印在控制台上,同时存到配置文件旁边的 .patchbay-token。

内核不在线也能用,只是看不到订阅里有哪些线路、也没法让改动立刻生效。这是有意的——配置写坏导致内核起不来的时候,正是最需要这个界面的时候。

开发

改代码的时候用这个,前后端都不用重启:

bun run dev:kernel   # 终端 1:本地测试内核,开着不用管
bun run dev:all      # 终端 2:后端 + 前端,改了自动生效

然后访问 http://localhost:5173(不是 7580)。后端代码改动由 Bun 的 --hot 重载, 界面改动由 Vite 直接更新浏览器。

bun run start 不具备这个能力——它把前端打成静态文件再由后端提供,代码一改就得重新 打包重启。那种方式适合最终验证和部署。

本地测试内核的配置由模板生成(dev/config.yaml 进 git,订阅地址从 .env 取, 生成的 dev/home/config.yaml 不进 git):

bun run dev:reset    # 第一次,或想把测试配置恢复成模板时

检查

bun test        # 单元测试,不需要内核
bun run smoke   # 接口冒烟测试,需要内核和后端都在跑
bun run typecheck

另有两个一次性脚本:scripts/roundtrip.ts 验证改一处配置之后 diff 里只出现那一处,scripts/safety-net.ts 验证配置写坏时能不能把用户救回来。

目录

server/    后端。config-store.ts 是核心,那条保护链路在里面
web/       前端。styles/tokens.css 顶部写着设计基调的三条规则
shared/    两边共用的领域逻辑,纯函数,带测试
vendor/    从别的项目复制来的代码,来源和本地改动记在各自的 ORIGIN.md
scripts/   验证用的脚本,不参与打包
dev/       本地测试内核的配置
S
Description
No description provided
Readme
1.1 MiB
v0.1.3
Latest
2026-08-31 03:59:08 +08:00
Languages
TypeScript 49.2%
Vue 47.5%
Shell 2.2%
CSS 0.9%
HTML 0.2%