运行时语言取舍

English

Codex Quota Monitor 当前用 Python 实现。这是一个有意识的工程取舍，不是说 Python 在所有部署场景里都是最高效的运行时。

当前决定

暂时继续使用 Python。不要只因为理论运行时开销，就把项目重写成 Go 或 Rust。

这个 monitor 是一个小型自托管运维服务。它的常规工作主要是低频 quota 采样、 HTTP dashboard/API 响应、JSON 解析、SQLite 历史、静态资源服务和 Prometheus metrics。对于预期的个人或小团队部署，这类负载更偏 I/O、低并发和长期运行。

浏览器 UI 也把显示默认值和运行时状态分开：服务端可以提供默认 locale、时区和 CSS 字体栈，每个浏览器仍可用本地偏好覆盖。locale 控制 UI 文案和浏览器侧日期 / 数字格式，timezone 只控制 reset 时间显示，字体设置仍只是 CSS font-family 栈。 Dashboard 现在内置 en 和 zh-CN 文案，API payload 仍保持结构化和语言中立。 这样以后做 localization 时，不会被某个 operator 的字体、locale 或部署时区绑死。

为什么这里 Python 可以接受

• 运行时依赖有意保持很小。判断是否真的引入了大型 web framework 或第三方依赖栈 前，先看 pyproject.toml。
• Python 让已经把它当成本地基础设施使用的 operator 更容易阅读、打包和修补。
• 当前服务是常驻进程。Python 冷启动成本没有频繁启动的 CLI helper 那么关键。
• 主要 correctness 风险在 quota / account state 解释，而不是原始吞吐。保留测试和 既有行为，比为了较小固定开销切换运行时更重要。

Go 或 Rust 会改善什么

Go 或 Rust 大概率会在这些方面更高效：

• 同样服务形态下常驻内存更低
• 冷启动更快
• release artifact、Nix closure 和 Docker runtime closure 更小
• 高请求并发下性能更强

这些收益是真实的，但目前还没有压过项目成本。重写需要完整迁移 snapshot model、 dashboard API、direct quota sampling、SQLite history、benchmark import、 Prometheus metrics、打包和测试，同时不能改变用户可见行为。

什么时候重新评估

出现以下任一情况时，再重新打开运行时选择：

• monitor 需要跑在内存受限设备或很小的 VPS 上
• 最小化 release image 或 Nix closure 变成产品目标
• 实测 RSS 或 CPU 已经变成真实 host-level 问题
• 账号数量、浏览器并发或刷新频率明显超出当前自托管 operator 场景
• 频繁冷启动变成正常工作流的一部分
• Python 依赖增长或代码组织开始让维护成本高于编译型实现

如果未来确实需要重写，默认先评估 Go。这个项目主要需要 HTTP、JSON、时间处理、 静态资源嵌入、SQLite 和 metrics，Go 的标准库和生态可以用较小运维体量覆盖。 只有当项目出现更复杂的状态建模、强 correctness 边界或明确 Rust 维护目标时， 才优先考虑 Rust。

如何测量

优先用实测代替语言预设：

nix build .#codex-quota-monitor --no-link --print-out-paths
nix path-info -S .#codex-quota-monitor
systemctl show codex-quota-monitor.service -p MemoryCurrent -p CPUUsageNSec

做本地前台测试时，应该在相同配置、账号数量、刷新间隔和浏览器负载下比较 RSS 和 启动时间。运行时语言只是运维决策的一个输入，不应该自动触发重写。