OctaFuse 2.1.2：路由拓扑更稳定，排障信息更完整

OctaFuse Gateway 2.1.2 正式发布。

随着路由配置逐渐复杂，管理后台（Admin）的关键不再只是“能不能保存”，还包括同一份配置能否始终以稳定、清晰的方式呈现，以及出现问题时，请求日志（Request Logs）能否快速说明请求来自哪个业务系统。

2.1.2 重点改进管理后台的路由与供应商（Provider）体验、请求日志的可观测性，以及全新开发环境中的启动可靠性。

同一份路由配置，始终保持稳定顺序

如果路由列表和拓扑中的上游目标（Upstream Target）每次刷新后顺序都不同，运维人员很容易误以为配置发生了变化。2.1.2 为同一优先级（priority）层建立了稳定的排序规则：

1. 先区分启用与停用状态。
2. 再按照权重（weight）排列。
3. 最后使用名称保证确定性顺序。

这种排序不会改变代理的实际调度语义，但能保证相同配置在管理后台中始终以一致的顺序呈现。比较不同模型、检查主备关系或通过截图沟通时，不会再受到随机顺序的干扰。

路由拓扑：状态、参数和说明更容易读

本次版本继续完善路由（Routes）页面：

• 各项状态使用更清晰的状态标签，并补充无障碍说明。
• 路由详情展示自定义参数，复杂字段通过悬浮提示提供解释。
• 响应式布局经过调整，在不同窗口宽度下保持信息层级。
• 同层上游目标的状态、权重和名称更便于横向比较。

这些调整看似细小，却直接影响日常配置复核：运维人员可以更快区分“配置存在但未启用”“参数来自自定义覆盖”和“当前路由确实参与调度”。

供应商卡片：减少无效入口，突出关键操作

供应商卡片重新整理了布局和按钮交互，并移除了未实际使用的端点复制入口。

页面将注意力集中在真正影响运行的操作上：查看供应商状态、进入配置、维护凭证和确认路由引用。移除用途不明确的按钮，也能避免用户误以为“复制端点就等于完成接入”。

请求日志增加 external_system

同一个 OctaFuse 实例往往同时服务多个门户、业务系统或内部平台。用户和 API Key 足以完成鉴权与归集，却不一定能让运维人员快速判断请求来自哪个外部系统。

2.1.2 在请求日志的读写路径中增加了 external_system，覆盖 D1、PostgreSQL 和 MySQL。管理后台的请求日志也同步展示这一字段，便于：

• 区分不同门户或业务系统的流量
• 按外部系统定位异常请求
• 将网关日志与业务侧观测数据关联
• 在共享用户体系下补充调用来源语义

该字段只是新增信息，不会改变原有的用户、密钥、模型或供应商归集方式。

全新仓库也能直接启动管理后台开发环境

管理后台使用 Turbopack 进行本地开发时，全新检出的仓库曾可能无法解析 @octafuse/core 源码。已经运行过构建、留有生成产物的工作目录不一定会复现，因此这个问题很难察觉。

2.1.2 修正了 Next.js / Turbopack 对核心包源码的解析配置。现在，新克隆的仓库安装依赖后即可运行管理后台开发命令，不再依赖预先生成的包产物。

这项修复不会影响生产运行时，却能显著减少新贡献者和 CI 临时环境的启动差异。

升级说明

2.1.2 是兼容性补丁版本：

• 数据库迁移：无
• 配置变更：无
• API 兼容性影响：无
• 新增信息：请求日志中的 external_system

建议更新代理、管理后台和迁移工具三个镜像后滚动重启，并重点检查路由拓扑、供应商卡片、请求日志和管理后台的本地开发启动。

• GitHub Release v2.1.2
• 完整变更日志

进一步了解 OctaFuse 或查看源码：

• OctaFuse 官网
• GitHub 仓库

如果 OctaFuse 对你的项目有帮助，欢迎在 GitHub 上点一个 Star。你的关注和反馈，会帮助我们继续改进管理后台与运维体验。