前端AI 应用本地部署【免费下载链接】FluentReadAn open-source browser extension for bilingual translation. 一款开源的浏览器双语翻译插件。项目地址https://gitcode.com/gh_mirrors/fl/FluentRead点击查看免费下载FluentRead流畅阅读是一款开源的浏览器双语翻译插件。本文聚焦其多 API Key 管理机制同一翻译服务可逐行添加多个 Key日常翻译由后台自动轮询分担请求并避开失效 Key而连接检查则逐行明确执行。本文以 多 Key 自动轮换与逐项检查报告 为主体结合仓库源码、单元测试与浏览器专项测试完整还原该机制的配置方式、轮换规则、实现原理与验证证据。读者读完可掌握多 Key 的配置入口与逐项检查操作、平滑加权轮询的权重奖惩规则、恢复窗口的调节方法以及该机制在真实生产扩展中的验证手段与边界。该机制对应 FluentRead 的 Issue #161 与 #171同一翻译服务可以逐行添加多个 Key翻译时自动分担请求并避开失败的 Key检查连接时则明确检查每一行。实现基于提交6499537e5138e640ecd263a778bff9574e595447并整合了主分支64cc5e1c10b331bd0adc371e1aaae7308d148db9此后仅补充浏览器测试场景与本报告未再修改运行时代码。本文引用的是当前仓库中可检索到的实现与测试可作为该报告的源码级延伸。用户流程如何配置多 Key 并逐项检查多 Key 管理在「服务配置 → 密钥与认证」区域完成界面组件位于 ServiceConfiguration.vue。整体流程如下逐行添加在服务配置中填写第一行 Key点击「添加一个 Key」继续添加。现有空行会直接获得焦点不堆积空白输入框不要求使用分隔符逗号不会被拆分见下文配置模型。每个服务可添加的 Key 数量没有硬性上限报告中验证过十行 Key 的场景。逐行独立管理Key 默认隐藏。每行可以独立删除、显示或隐藏、检查或重新检查。空行不参与请求重复项会明确提示并跳过。检查所有 Key点击「检查所有 Key」后依次检测逐行显示「等待 → 检查中 → 成功勾及耗时」状态失败则显示具体原因。某一行失败不会借用另一行来显示成功避免误判。可中断、结果可失效可停止后续检查已完成结果保留当前已发送的请求可能继续完成。修改 Key、服务地址、模型等配置后旧结果失效迟到的响应不会重新点亮旧的成功勾实现上由配置指纹保证见下文。翻译自动选择 Key日常翻译自动轮询选择 Key无需用户维护优先级。成对使用 Access Key ID / Secret 的服务继续保留一组完整凭据只需一个密钥的云服务支持多行 Key。多 Key 开关apiKeyRotationEnabled是每个服务的独立开关由设置页中的el-switch控制ServiceConfiguration.vue。从源码看开启后才显示完整 Key 列表displayedApiKeys关闭时仅展示首个 Key便于用户随时停用轮询而保留其余 Key。共用配置与隔离边界每行 Key 共用当前服务的地址、模型、区域及自定义请求头等设置不同服务或不同自定义服务之间不共享 Key。原有单 Key 配置自动保留为第一项完整备份保留凭据公开配置和历史记录不包含 Key 列表。轮换规则平滑加权轮询与失败惩罚多 Key 轮询的核心状态机位于 apiKeyPool.ts。其完整规则如下表这是报告原文的权威定义情况后续行为新增 Key / 初始状态权重均为 4使用平滑加权轮询分担请求网络、超时、服务端临时故障失败 Key 权重减半并向下取整本次请求尝试其他 Key鉴权失败、额度不足、限流失败 Key 权重归零暂时跳过本次请求尝试其他 Key成功请求权重增加 1最高恢复到初始值恢复窗口到期默认距最近失败 1 分钟后恢复初始权重用户可在高级请求限制中调整为 1–60 分钟服务端提供重试时间时遵循该时间单独检查成功将该 Key 恢复为初始权重取消或一般模型、参数配置错误不扣减 Key 权重不会靠轮换反复尝试相同的配置问题全部 Key 暂时不可用返回失败及重试信息不无限循环源码中的权重状态机从源码看规则表由三组常量驱动全部定义在 apiKeyPool.ts初始权重API_KEY_POOL_DEFAULT_WEIGHT 4所有 Key 以相同权重进入轮询池测试starts equal and uses smooth weighted rotation验证了三个 Key 在连续六次请求中按[a,b,c,a,b,c]均匀分配tests/apiKeyPool.test.ts。临时故障降权transient / network / server归入penalty类reportFailure中执行weight Math.floor(weight / 2)即减半向下取整。致命故障清零auth / quota / rate-limit归入ZERO_WEIGHT_FAILURES权重直接置 0进入冷却跳过。不惩罚config / cancelled归入NON_PENALIZING_FAILURES权重不变——因为模型或参数配置错误属于配置问题靠轮换重试其他 Key 无意义。平滑加权轮询算法lease方法是「平滑」的来源每个候选 Key 先累加自己的权重current weight选出current最大的 Key再从中减去总权重。这样既按权重比例分配请求又避免同一 Key 被连续打中从结构上保证了请求的平滑分散。失败分类与冷却classifyApiKeyFailure综合错误类型、状态码、错误 code 与 message 文本判断失败类别apiKeyPool.ts401 / 403 / 429 状态码、invalid_api_key、quota_exceeded等 code以及「api key invalid / expired」类消息 →cooldown清零冷却408 / 425 / 5xx、网络与超时 →penalty减半其余如 400 参数错误、AbortError 取消→ 不惩罚。该分类在 tests/apiKeyPool.test.ts 中有大量边界用例覆盖例如invalid max_tokens参数配置问题不会被误判为 Key 故障。单次翻译中的尝试预算调度封装在 apiKeyRotation.ts 的runWithApiKeyRotation中一次翻译中每个 Key 最多尝试一次excluded列表记录已尝试的 Key循环直至排除完毕所有尝试共用总超时预算deadlineAt且按剩余 Key 数把单次预算最多切三份避免大量 Key 把单次请求切得过短继续遵守现有并发与速率限制默认并发上限、每秒/每分钟请求上限定义于 scheduling.ts全部不可用时抛出携带retryAfterMs与「其他 Key 暂时不可用请稍后重试或逐项检查」提示的错误不会无限循环流式能力写作等流建立前可以切换 Key已经开始输出后不会重放请求避免产生重复内容。健康状态的存储边界健康权重只保存在后台进程内存中rotationsMap仅存 Key 的 SHA-256 摘要而非明文后台进程重启后所有 Key 重新从等权开始。因此成功勾仅代表当前配置的一次检查成功且检查会产生小额测试请求不代表该 Key 持续可用或免费。恢复窗口与请求限制配置Key 冷却后的恢复时间在 scheduling.ts 中定义并规范化DEFAULT_API_KEY_RECOVERY_MS 60_000默认 1 分钟可调范围MIN_API_KEY_RECOVERY_MS到MAX_API_KEY_RECOVERY_MS即1–60 分钟normalizeApiKeyRecoveryMs按整分钟保存四舍五入到分钟并夹取到合法范围避免产生难以理解的半分钟值若服务端响应携带重试时间Retry-After冷却窗口遵循该时间且最小不低于 1 秒normalizeCooldownMs。设置项「API Key 冷却恢复时间」位于请求限制设置区由 SettingsSections.vue 渲染模型值经normalizeApiKeyRecoveryMs换算为分钟数后写入配置同文件 L1444-L1450。由于配置范围被限制为 1–60 分钟apiKeyRotation.ts 中的策略缓存最多只保留 60 个实例避免动态配置导致内存无界增长。关键实现细节scope 隔离、密钥脱敏与陈旧结果失效服务身份隔离scope不同服务、不同自定义服务的 Key 互不共享由scopeFor实现它对服务名、请求模型、代理、请求体模板、自定义请求头、计费路由如deeplx、newapi、azureOpenai、minimax、mimo、deepseek等以及自定义 provider 端点生成SHA-256 摘要作为 scope 身份apiKeyRotation.ts。createApiKeyRotation按 scope 维护有界轮询池默认最多 64 个 scopeLRU 淘汰同一服务的 Key 列表变化时通过sync增删 Key 状态。编辑其他服务的配置不会重置本服务的权重这正是「不同服务不共享 Key」的底层保证。密钥脱敏redactApiKeyError会在错误序列化后把message / code / requestId中出现的任何 Key 明文及其 URL 编码形式替换为[已隐藏的密钥]确保 provider 回显的任意 Key 都不会进入运行时错误或日志apiKeyRotation.ts。单项检查绕过冷却、精确到行「检查或重新检查」单行 Key 时runWithApiKeyRotation接收keyIndex参数它只初始化/同步轮询池但不领取普通轮询租约直接把该行的原始 Key 绑定到请求上withServiceApiKey冻结配置快照并替换该服务 token从而绕过冷却阻挡成功则调用rotation.success(scope, id)将该 Key 恢复初始权重失败则按类别记入该 Key。若该行已为空或被修改会明确报错「这个 API Key 已更改或为空请重新检查」。陈旧结果失效配置指纹逐项检查的「旧结果失效」由 apiKeyCheckIdentity.ts 保证它按服务提取 endpoint、代理、模型、请求参数、计费路由、自定义 provider 与原始 Key 行计算稳定的64 位 SHA-256 配置指纹createApiKeyCheckRevision。任何配置或 Key 行变化都会改变指纹迟到的响应因指纹不匹配而不会重新点亮旧的成功勾指纹格式通过/^[a-f0-9]{64}$/校验。配置模型与旧版单 Key 兼容多 Key 的纯配置层在 apiKeys.ts不读写存储、不发起网络、不参与 provider 编排配置形态为ApiKeys Recordservice, string[]按服务保存有序 Key 列表normalizeApiKeys规范化非字符串项被过滤、每项trim()、逗号按字符串原样保留不被拆分getServiceApiKeys返回去重且非空的服务 Key 列表getServiceApiKeyRows供 UI 保留空行旧版兼容apiKeysToToken为旧 provider 路径生成「首个非空 Key」的 token 镜像旧token字段仅作为未迁移服务的单 Key 兼容来源新字段优先ApiKeyConfigSource的解析顺序。因此升级前只有一个 Key 的配置会在新模型下自动保留为第一项无需用户迁移。验证结果全量测试与浏览器专项该机制在报告对应的提交上通过了完整的质量门禁命令输出摘录保存在 validation.txt浏览器专项原始报告为 browser-report.json验证结果全量 Vitest305 个文件6,143 个用例通过严格覆盖率套件248 个文件5,017 个用例通过统计范围内 statements / branches / functions / lines 均为 100%测试审计305 个文件归类有效未发现重复、遗漏、违规跳过或覆盖率忽略TypeScript / Vue 类型检查通过Chrome / Firefox 构建与 manifest verifier通过Userscript 构建与 verifier通过文档构建通过生产扩展多 Key 浏览器专项13 / 13 通过控制台未捕获页面错误浏览器专项覆盖的 13 个场景来自 browser-report.json 的cases列表空行复用、重复项跳过、实际翻译消息经过 broker 后从失败的 A 切换到 B/C、逐项检查不代偿、单项重测、删除第一项、停止后续检查、检查中编辑、十行 Key、深色窄屏、重新打开后持久化、成对云凭据保持完整、单密钥云服务的多行编辑。两个云服务场景仅验证配置界面没有向外部供应商发送请求。自动化入口为 run-api-keys-ui-test.cjs它在本地启动 HTTP fixture对fixture-A返回 401、对其他合成 Key 返回成功并把生产 Chrome MV3 产物.output/chrome-mv3加载到隔离的 Edge 临时 profile 中执行全部场景同时记录请求、截图与控制台错误。从脚本头部注释可见浏览器启动模式为macos-background-cdp焦点策略为launchservices-no-foreground窗口位于第二块屏幕模式为background-visible-no-focus报告记录browserFrontmostfalse确保验证不被前台焦点干扰。复现命令报告给出了完整的复现命令可在当前仓库根目录执行pnpm exec vitest run --maxWorkers2 --minWorkers1 --testTimeout20000 pnpm exec vitest run --config vitest.coverage.config.ts --maxWorkers2 --minWorkers1 --testTimeout20000 --coverage.reportsDirectory/private/tmp/multikey-delivery-coverage pnpm compile pnpm build pnpm build:firefox pnpm verify:extension-manifests pnpm build:userscript node scripts/verify-userscript-build.mjs pnpm docs:build pnpm test:audit证据范围与限制浏览器专项验证的是实际生产扩展、消息链、HTTP 传输和 UI但服务响应来自本地模拟端点local-http-401-fixture未验证任何真实付费供应商的账号、额度或持续可用性。Firefox 与 Userscript 完成了构建验证但本次没有运行对应真实浏览器 UI 或用户脚本端到端测试。原有 full UI 技能脚本在run-ui-test.cjs:533等待旧 popup 标题「让阅读自然地流动 / 翻译功能已暂停」时超时当前标题已改变该套件未计为通过主分支此前已有相同的基线失败记录本次命令输出未重定向保存所指定的证据目录为空。此外本报告对应的交互界面在后续提交中已重整为多 Key 界面重整报告所述的新版密钥管理界面本页保留的是初版机制及其回归证据——本文所述的轮询算法与配置模型仍是新版界面的底层基础。赞分享前端AI 应用本地部署【免费下载链接】FluentReadAn open-source browser extension for bilingual translation. 一款开源的浏览器双语翻译插件。项目地址https://gitcode.com/gh_mirrors/fl/FluentRead点击查看免费下载相关推荐Apache DolphinScheduler 负载均衡机制全解析从加权随机、平滑轮询到动态加权调度Apache DolphinScheduler 负载均衡机制全解析从加权随机、平滑轮询到动态加权调度 本篇技术指南以 Apache DolphinSchedu任务调度大数据后端前端Apache DolphinScheduler Worker 负载均衡算法深度解析从随机分配到动态平滑加权轮询Apache DolphinScheduler Worker 负载均衡算法深度解析从随机分配到动态平滑加权轮询 导读 本文聚焦 Apache DolphinS任务调度数据编排工作流自动化后端大数据Apache DolphinScheduler Worker 负载均衡机制全解析从加权随机、平滑轮询到线性负载与动态加权实现Apache DolphinScheduler Worker 负载均衡机制全解析从加权随机、平滑轮询到线性负载与动态加权实现 导读 在 Apache Dolp任务调度大数据后端前端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考