4c4375620828f713ce00ca7b0fd6119f3a71daa0
absolute 的弹层会计入祖先滚动容器的可滚动区域——在对话框里打开下拉, modal 会被撑出滚动条。弹层改 position: fixed 按视口摆放:逃出所有 overflow 裁剪,又因为还在 dialog 的 DOM 子树里,照样画在 top layer 之上。 代价是位置不跟随滚动,滚动和缩放时直接收起(弹层内部滚动不算)。 三个弹层组件(SelectBox、ComboBox、SourcePicker)同一套做法。 组件根元素不再写死 width: 100%:它和调用方的宽度规则同权重,谁赢 看样式表加载顺序——请求页的级别下拉被撑满整行就是这么来的。 弹层加 user-select: none 和最大宽度,选项超长省略号截断。 规则表单的类型、载荷、目标原来是 input + datalist,原生建议列表的样式 和开合状态都管不到,换成同族的 ComboBox:选项只是建议、手填合法, Enter 在弹层开着时选中高亮项、收起时照旧提交表单。
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/ 本地测试内核的配置