RSA + HMAC 签名实现#

传统的 API 网关通常依赖成熟的加密库（如 cryptography）来处理签名。然而，loomy2api 选择了纯 Python 标准库，这意味着开发者必须手动实现 RSA 加密和 HMAC 签名逻辑【S5】。这种做法虽然增加了开发难度，但也带来了部署的极致简化——无需 pip install 任何第三方依赖，仅需 Python 3.9+ 环境即可运行。

设备标识的随机化#

在逆向过程中，项目发现上游协议对“设备标识”有强校验。为了实现多账号池管理，loomy2api 采用了动态生成设备标识的策略：每个账号在首次登录时随机生成一套 devid（设备 ID）和校园设备号，并将其绑定到该账号上下文【S5】。后续的请求续期将复用该标识，从而在协议层面实现账号与设备的强绑定，避免了多账号共用同一设备指纹导致的冲突。

静默回落与模型映射陷阱#

上游服务器对未知的模型名称通常不会直接报错，而是静默回落到默认模型。例如，当请求 gpt-4o-mini 时，如果该模型在当前账号下不可用，服务器可能返回 deepseek-v4-flash-0731 作为响应，且响应头中的 model 字段会被修改【S5】。这对网关开发者提出了一个隐性的工程挑战：不能仅依赖客户端传入的模型名来验证可用性，必须解析回包中的 model 字段以确认实际调用的模型。这要求网关层具备更复杂的响应解析与路由校验逻辑。

账号隔离与信任边界#

尽管项目实现了设备标识隔离，但其文档明确指出：“这不是防封保证”【S5】。协议层面仅涉及四个设备相关字段，而上游风控系统真正看重的通常是出口 IP。因此，账号隔离策略在工程上只能视为一种“协议层面的合规性处理”，而非“业务层面的风控方案”。这一结论提醒我们，在构建此类中转网关时，必须清晰界定协议适配与业务风控的边界，避免过度承诺。

CI 环境下的 Bug 发现#

在 CI 环境中，由于上游服务不可达，测试脚本意外捕获到了 socket 和 DNS 层的异常。然而，原始代码仅捕获了自定义异常，导致断网环境下执行 loomy2api accounts 命令时直接崩溃【S5】。这一发现揭示了纯标准库实现的一个潜在风险：开发者容易忽略底层网络库抛出的系统级异常。

异常捕获的补丁#

修复方案是在异常捕获逻辑中增加了对通用异常的兜底处理，并引入了回归测试【S5】。这一案例为同类“零依赖”项目提供了宝贵的经验：在追求轻量化的同时，必须构建完善的异常监控体系，确保在 DNS 解析失败、连接超时等极端场景下，服务依然具备优雅的降级或报错能力。

验证清单#

对于希望复现或部署该项目的工程师，建议遵循以下验证步骤：

1. 环境准备：确保 Python 3.9+ 环境，克隆仓库并复制配置文件。
2. 账号接入：执行 python -m loomy2api add 命令，注意在账号中心设置密码（客户端无此入口）。
3. 服务启动：使用 docker compose up -d 启动服务，访问 http://127.0.0.1:17890/panel 检查各账号余额与登录态。
4. 连通性测试：配置 OpenAI 兼容客户端（如 LobeChat）指向网关地址，验证流式与非流式响应。