CodexBar 架构全景模块划分、入口点、数据流与并发设计【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar本篇技术指南围绕 CodexBar 的架构文档 docs/architecture.md 展开系统梳理其六个源码模块的职责边界、SwiftUI/AppKit 双入口点的生命周期分工、从后台刷新到菜单栏渲染的完整数据流以及 CLI 登录进程的取消/超时/输出捕获机制。读完本文你将能够基于模块边界定位功能代码、理解UsageStore与SettingsStore的观察驱动关系并掌握在 Swift 6 严格并发与 macOS 14 约束下进行架构级重构所需的全部上下文。模块划分职责边界一览CodexBar 采用内核只做抓取与解析、App 层只做状态与 UI的分层结构所有可执行目标都收敛在Sources/目录下共六个模块模块职责对应目录CodexBarCore抓取 解析Codex RPC、PTY runner、Claude probes、OpenAI web scraping、状态轮询Sources/CodexBarCoreCodexBar状态 UIUsageStore、SettingsStore、StatusItemController、菜单、图标渲染Sources/CodexBarCodexBarWidgetWidgetKit 扩展绑定共享快照Sources/CodexBarWidgetCodexBarCLI随应用捆绑的codexbarCLI输出 usage/statusSources/CodexBarCLICodexBarClaudeWatchdog辅助进程维持稳定的 Claude CLI PTY 会话Sources/CodexBarClaudeWatchdogCodexBarClaudeWebProbeCLI 辅助工具诊断 Claude web 抓取Sources/CodexBarClaudeWebProbeCodexBarCore无 UI 的抓取解析内核CodexBarCore是整个项目中最庞大的目录数百个 Swift 文件内部又按领域划分为Providers/485 个文件按厂商分目录、OpenAIWeb/、Hooks/、Host/、Logging/、Sync/、Plugins/等子模块。它的核心价值在于所有网络抓取、CLI 进程调用、Cookie/Keychain 访问都发生在这一层App 层不直接接触任何协议细节。以 usage 抓取为例Sources/CodexBarCore/UsageFetcher.swift 定义了RateWindow、NamedRateWindow等核心数据模型其中RateWindow携带usedPercent、windowMinutes、resetsAt、resetDescription、nextRegenPercent以及一个重要的isSyntheticPlaceholder标志——该标志用于区分真实归零的配额窗口与厂商未上报时合成的占位窗口防止菜单栏出现幻影的5h 0%会话指标。RateWindow.backfillingResetTime(from:)还实现了用缓存重置时间回填缺失resetsAt的逻辑同时保持占位标记不被误升级为真实窗口。CodexBar菜单栏应用的完整外壳CodexBar模块承载了菜单栏应用的全部状态与 UI其内部同样是按关注点拆分的巨型扩展集合UsageStore被拆成 30 个UsageStore*.swift扩展刷新、状态、令牌账户、配额告警、历史节奏等StatusItemController也有 40 个扩展文件。这种单一主类 按主题扩展的组织方式让每个关注点的代码都能被快速定位。Widget、CLI 与两个辅助进程CodexBarWidget通过 Sources/CodexBarWidget/CodexBarWidgetBundle.swift 的WidgetBundle注册 6 个 WidgetSwitcher、Usage、History、Compact、BurnDown、CombinedBurnDown全部依赖UsageStore发布的共享快照Widget Snapshot因此不存在独立的抓取路径。CodexBarCLI入口在 Sources/CodexBarCLI/CLIEntry.swift基于 Commander 解析codexbar usage、codexbar status、codexbar cards、codexbar serve等子命令支持-h/--help、-V/--version快速路径与CODEXBAR_LOG_LEVEL环境变量日志引导。CodexBarClaudeWatchdog见 Sources/CodexBarClaudeWatchdog/main.swift以-- binary [args...]方式包裹目标进程负责进程树级SIGTERM→SIGKILL的优雅终止含 0.5 秒宽限期轮询waitpid并解析退出码/信号编码。CodexBarClaudeWebProbe见 Sources/CodexBarClaudeWebProbe/ClaudeWebProbeEntry.swift默认探测 13 个claude.ai/api端点organizations、usage、billing、session 等逐条输出 status、content-type、顶层 key、邮箱与套餐提示供诊断 Claude web 抓取失败使用。入口点SwiftUI keepalive 与 AppKit 生命周期架构文档明确指出两个入口点CodexBarAppSwiftUI keepalive Settings scene与AppDelegate状态栏控制器、Sparkle 更新器、通知。在源码中实际入口比这多一层封装进程级入口Sources/CodexBar/CodexbarApp.swift 的CodexBarEntryPoint.main()先处理打包启动自检CodexBarCoreResourceSmoke用于 0.48.0 打包资源加载回归、DEBUG 下的菜单栏布局原生证明再通过CodexBarLaunchMode.resolve(arguments:)识别--hook-event参数——该模式用于处理其他 CodexBar 安装在~/.codex/hooks.json中遗留的注册避免 AppKit 创建第二组状态栏图标后直接 no-op 返回。SwiftUI 场景CodexBarApp负责日志引导CODEXBAR_LOG_LEVEL环境变量优先于UserDefaults的debugLogLevel、SettingsStore/UsageStore/ManagedCodexAccountCoordinator的组装以及一个空壳Settingsscene——它只用来占据应用菜单中的 Settings 命令位置真正的设置窗口由 AppKit 的SettingsWindowController管理。AppDelegateapplicationDidFinishLaunching中依次启动 Dock 图标控制器、内存压力监视器、ensureStatusController()、云同步协调器、通知授权并注册 session/weekly 额度重置的 NotificationCenter 观察者配合彩带庆祝动画applicationWillTerminate则反向执行停止同步、停止监视、prepareForAppShutdown()、终止活动子进程的清理序列。值得注意的细节状态栏控制器通过StatusItemController.factory延迟创建Sources/CodexBar/StatusItemController.swift其协议StatusItemControlling只暴露打开设置、快捷键开菜单、登录流程、彩带原点、缓存裁剪、关机准备等少量方法屏蔽了内部复杂度即便依赖缺失也会走一个防御性 fallback 路径并触发assertionFailure保证崩溃可观测。数据流从后台刷新到菜单、图标与 Widget架构文档给出了三条核心数据流逐一对应源码实现刷新管线UsageFetcher→UsageStore→ 展示层Background refresh → UsageFetcher/provider probes → UsageStore → menu / icon / widgets采集端UsageFetcher与各 provider 探针Codex RPC、PTY runner、Claude probes、OpenAI web scraping、状态轮询在后台执行不占用主线程。状态中枢Sources/CodexBar/UsageStore.swift 的UsageStore通过ObservableObservation 框架管理快照、错误、诊断、凭证、历史节奏、Spend Dashboard 发布等状态。其menuObservationToken/iconObservationToken计算属性以读取即注册依赖的方式列出所有参与菜单/图标渲染的状态源让 SwiftUI/AppKit 界面精确订阅所需变化。展示端StatusItemController读取快照渲染菜单栏图标与菜单CodexBarWidget通过共享的 Widget Snapshot 在桌面显示同一份数据。设置驱动SettingsStore反馈刷新节奏与特性开关Settings toggles → SettingsStore → UsageStore refresh cadence feature flagsUsageStore.observeSettingsChanges()见 Sources/CodexBar/UsageStore.swift用withObservationTracking观察backgroundWorkSettingsObservationToken一旦设置变化便失效 provider 可用性缓存、清空 probe 日志并在automaticallyStartsBackgroundWork开启时重启定时器、刷新 provider 运行时。刷新节奏Manual/1m/2m/5m/15m/30m/Adaptive的具体解析与回落规则见 docs/refresh-loop.md。运行时 Provider 设置类型化的快照注册第三条流是运行时才有的 provider 设置它们不写死进SettingsStore而是通过类型化、描述符注册的 section 汇入ProviderSettingsSnapshot再由设置界面按 provider 动态渲染。这样新增 provider 无需改动设置面板骨架只需注册自己的描述符与 section 类型。后台刷新的自适应节奏UsageStore通过startTimer()在每个 tick 前采集当前时间、上次开菜单时间、本地编码活动时间、低电量模式与热状态等不纯信号交给纯函数AdaptiveRefreshPolicySources/CodexBar/AdaptiveRefreshPolicy.swift计算下一次延迟与稳定的Reason——策略本身不读时钟、不读ProcessInfo天然可测试仓库中AdaptiveRefreshPolicyTests、AdaptiveRefreshHeuristicsTests即针对此设计。CLI 登录生命周期可取消、有超时、可诊断架构文档用较大篇幅描述了登录流程这是全项目进程管理最精细的部分分为三层第一层Provider 专属 RunnerCodexLoginRunnerSources/CodexBar/CodexLoginRunner.swift解析自身可执行文件与环境通过PathBuilder.effectivePATH(purposes: [.rpc, .tty, .nodeTooling], ...)构造 PATH再用CodexHomeScope.scopedEnvironment(base:codexHome:)注入 Codex home 作用域最后定位 codex 二进制并调用CLILoginRunner.run。默认超时 120 秒、输出排空超时 3 秒。KiroLoginRunnerSources/CodexBar/Providers/Kiro/KiroLoginRunner.swift与 Codex 同构说明该模式可复用于任意等待浏览器授权的 CLI 登录。第二层通用登录执行器CLILoginRunnerSources/CodexBar/CLILoginRunner.swift 是核心它统一返回一个Result类型enum Outcome: Equatable, Sendable { case success case cancelled case timedOut case failed(status: Int32) case missingBinary case launchFailed(String) }其执行过程的关键设计进程组管理setpgid(pid, pid)成功后记录processGroup超时/取消时由SubprocessRunner.terminateProcess(process, processGroup:)对整个进程组发起终止确保子进程不会泄漏。有界等待BoundedTaskJoin将退出任务封装为带 join grace 的有限等待区分.value正常退出/.failure取消/.timedOut超时三种结局。进度上报pollProgress每 500ms 扫描 stdout/stderr 快照一旦出现http://或https://即通过onProgress回调上报供界面展示浏览器授权链接随后立即退出轮询。诊断保留与防阻塞无论成功失败ProcessPipeCapture.finish(timeout:)都以有界时间排空输出默认 3 秒合并 stdout/stderr 后截取前 4000 字符保留继承的管道不会让调用方无限等待。取消登录时终止子进程、join 进度任务并不产生失败弹窗超时则保留捕获到的诊断输出。第三层共享的进程终止原语CLILoginRunner与SubprocessRunnerSources/CodexBarCore/Host/Process/SubprocessRunner.swift共享ProcessTerminationSources/CodexBarCore/Host/Process/ProcessTermination.swift与进程树终止逻辑。从源码搜索看这一原语被 Gemini、Doubao、Bedrock、Augment、Antigravity、Claude、VertexAI、Alibaba、Amp 等多个 provider 的 CLI 探针复用是全项目进程管理的统一底座。CodexBarClaudeWatchdog的killProcessTree同样实现了SIGTERM→ 轮询waitpid0.5 秒宽限→SIGKILL的降级序列与 App 层逻辑互为印证。并发与平台约束架构文档明确了两条硬约束重构与新增代码时必须遵守Swift 6 严格并发代码库启用-strict-concurrency倾向使用 Sendable 状态与显式MainActor跳转。典型体现CLILoginRunner.Result声明为Equatable, SendableStatusItemControlling协议与StatusItemController类标注MainActoronProgress回调类型为Sendable (String) - VoidCodexbarApp的 init 与 AppDelegate 方法均在MainActor上下文中完成状态组装与 UI 接管。macOS 14 目标重构时应避免已废弃 API。例如configureAppIconForMacOSVersion()用#unavailable(macOS 26)在旧系统上切换经典非 Liquid Glass图标体现了对系统版本差异的显式处理。数据模型与跨模块类型示例为帮助读者建立模块边界即类型边界的认知这里给出一个贯穿三层的示例配额窗口数据。CodexBarCore的UsageFetcher.swift定义RateWindow含占位标志与回填逻辑——这是抓取层的输出契约CodexBar的UsageStore将各 provider 的RateWindow汇总为快照并驱动menuObservationToken——这是状态层的聚合StatusItemController与 Widget 消费快照渲染百分比与重置倒计时——这是展示层的消费。新增一个 provider 时遵循该链路即可在CodexBarCore/Providers/下实现 fetcher 与解析器产出RateWindow在 App 层注册描述符与设置 sectionUsageStore通过 provider registry 自动纳入刷新与聚合。延伸阅读架构文档末尾推荐的三个专题文档与本文形成完整的知识闭环docs/providers.md69 个已注册 provider 的抓取策略web/cli/oauth/api token/local probe/web dashboard与数据来源说明docs/refresh-loop.md刷新节奏取值、Adaptive 模式的纯函数策略与存量配置回落规则docs/ui.md菜单与图标的 UI 呈现层设计。对于想从测试侧验证架构设计的读者仓库的 Tests/CodexBarTests 与 TestsLinux 提供了针对AdaptiveRefreshPolicy、登录隔离、进程清理等机制的大量回归用例可作为阅读架构文档后按图索骥的实践入口。【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CodexBar 架构全景：模块划分、入口点、数据流与并发设计
CodexBar 架构全景模块划分、入口点、数据流与并发设计【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar本篇技术指南围绕 CodexBar 的架构文档 docs/architecture.md 展开系统梳理其六个源码模块的职责边界、SwiftUI/AppKit 双入口点的生命周期分工、从后台刷新到菜单栏渲染的完整数据流以及 CLI 登录进程的取消/超时/输出捕获机制。读完本文你将能够基于模块边界定位功能代码、理解UsageStore与SettingsStore的观察驱动关系并掌握在 Swift 6 严格并发与 macOS 14 约束下进行架构级重构所需的全部上下文。模块划分职责边界一览CodexBar 采用内核只做抓取与解析、App 层只做状态与 UI的分层结构所有可执行目标都收敛在Sources/目录下共六个模块模块职责对应目录CodexBarCore抓取 解析Codex RPC、PTY runner、Claude probes、OpenAI web scraping、状态轮询Sources/CodexBarCoreCodexBar状态 UIUsageStore、SettingsStore、StatusItemController、菜单、图标渲染Sources/CodexBarCodexBarWidgetWidgetKit 扩展绑定共享快照Sources/CodexBarWidgetCodexBarCLI随应用捆绑的codexbarCLI输出 usage/statusSources/CodexBarCLICodexBarClaudeWatchdog辅助进程维持稳定的 Claude CLI PTY 会话Sources/CodexBarClaudeWatchdogCodexBarClaudeWebProbeCLI 辅助工具诊断 Claude web 抓取Sources/CodexBarClaudeWebProbeCodexBarCore无 UI 的抓取解析内核CodexBarCore是整个项目中最庞大的目录数百个 Swift 文件内部又按领域划分为Providers/485 个文件按厂商分目录、OpenAIWeb/、Hooks/、Host/、Logging/、Sync/、Plugins/等子模块。它的核心价值在于所有网络抓取、CLI 进程调用、Cookie/Keychain 访问都发生在这一层App 层不直接接触任何协议细节。以 usage 抓取为例Sources/CodexBarCore/UsageFetcher.swift 定义了RateWindow、NamedRateWindow等核心数据模型其中RateWindow携带usedPercent、windowMinutes、resetsAt、resetDescription、nextRegenPercent以及一个重要的isSyntheticPlaceholder标志——该标志用于区分真实归零的配额窗口与厂商未上报时合成的占位窗口防止菜单栏出现幻影的5h 0%会话指标。RateWindow.backfillingResetTime(from:)还实现了用缓存重置时间回填缺失resetsAt的逻辑同时保持占位标记不被误升级为真实窗口。CodexBar菜单栏应用的完整外壳CodexBar模块承载了菜单栏应用的全部状态与 UI其内部同样是按关注点拆分的巨型扩展集合UsageStore被拆成 30 个UsageStore*.swift扩展刷新、状态、令牌账户、配额告警、历史节奏等StatusItemController也有 40 个扩展文件。这种单一主类 按主题扩展的组织方式让每个关注点的代码都能被快速定位。Widget、CLI 与两个辅助进程CodexBarWidget通过 Sources/CodexBarWidget/CodexBarWidgetBundle.swift 的WidgetBundle注册 6 个 WidgetSwitcher、Usage、History、Compact、BurnDown、CombinedBurnDown全部依赖UsageStore发布的共享快照Widget Snapshot因此不存在独立的抓取路径。CodexBarCLI入口在 Sources/CodexBarCLI/CLIEntry.swift基于 Commander 解析codexbar usage、codexbar status、codexbar cards、codexbar serve等子命令支持-h/--help、-V/--version快速路径与CODEXBAR_LOG_LEVEL环境变量日志引导。CodexBarClaudeWatchdog见 Sources/CodexBarClaudeWatchdog/main.swift以-- binary [args...]方式包裹目标进程负责进程树级SIGTERM→SIGKILL的优雅终止含 0.5 秒宽限期轮询waitpid并解析退出码/信号编码。CodexBarClaudeWebProbe见 Sources/CodexBarClaudeWebProbe/ClaudeWebProbeEntry.swift默认探测 13 个claude.ai/api端点organizations、usage、billing、session 等逐条输出 status、content-type、顶层 key、邮箱与套餐提示供诊断 Claude web 抓取失败使用。入口点SwiftUI keepalive 与 AppKit 生命周期架构文档明确指出两个入口点CodexBarAppSwiftUI keepalive Settings scene与AppDelegate状态栏控制器、Sparkle 更新器、通知。在源码中实际入口比这多一层封装进程级入口Sources/CodexBar/CodexbarApp.swift 的CodexBarEntryPoint.main()先处理打包启动自检CodexBarCoreResourceSmoke用于 0.48.0 打包资源加载回归、DEBUG 下的菜单栏布局原生证明再通过CodexBarLaunchMode.resolve(arguments:)识别--hook-event参数——该模式用于处理其他 CodexBar 安装在~/.codex/hooks.json中遗留的注册避免 AppKit 创建第二组状态栏图标后直接 no-op 返回。SwiftUI 场景CodexBarApp负责日志引导CODEXBAR_LOG_LEVEL环境变量优先于UserDefaults的debugLogLevel、SettingsStore/UsageStore/ManagedCodexAccountCoordinator的组装以及一个空壳Settingsscene——它只用来占据应用菜单中的 Settings 命令位置真正的设置窗口由 AppKit 的SettingsWindowController管理。AppDelegateapplicationDidFinishLaunching中依次启动 Dock 图标控制器、内存压力监视器、ensureStatusController()、云同步协调器、通知授权并注册 session/weekly 额度重置的 NotificationCenter 观察者配合彩带庆祝动画applicationWillTerminate则反向执行停止同步、停止监视、prepareForAppShutdown()、终止活动子进程的清理序列。值得注意的细节状态栏控制器通过StatusItemController.factory延迟创建Sources/CodexBar/StatusItemController.swift其协议StatusItemControlling只暴露打开设置、快捷键开菜单、登录流程、彩带原点、缓存裁剪、关机准备等少量方法屏蔽了内部复杂度即便依赖缺失也会走一个防御性 fallback 路径并触发assertionFailure保证崩溃可观测。数据流从后台刷新到菜单、图标与 Widget架构文档给出了三条核心数据流逐一对应源码实现刷新管线UsageFetcher→UsageStore→ 展示层Background refresh → UsageFetcher/provider probes → UsageStore → menu / icon / widgets采集端UsageFetcher与各 provider 探针Codex RPC、PTY runner、Claude probes、OpenAI web scraping、状态轮询在后台执行不占用主线程。状态中枢Sources/CodexBar/UsageStore.swift 的UsageStore通过ObservableObservation 框架管理快照、错误、诊断、凭证、历史节奏、Spend Dashboard 发布等状态。其menuObservationToken/iconObservationToken计算属性以读取即注册依赖的方式列出所有参与菜单/图标渲染的状态源让 SwiftUI/AppKit 界面精确订阅所需变化。展示端StatusItemController读取快照渲染菜单栏图标与菜单CodexBarWidget通过共享的 Widget Snapshot 在桌面显示同一份数据。设置驱动SettingsStore反馈刷新节奏与特性开关Settings toggles → SettingsStore → UsageStore refresh cadence feature flagsUsageStore.observeSettingsChanges()见 Sources/CodexBar/UsageStore.swift用withObservationTracking观察backgroundWorkSettingsObservationToken一旦设置变化便失效 provider 可用性缓存、清空 probe 日志并在automaticallyStartsBackgroundWork开启时重启定时器、刷新 provider 运行时。刷新节奏Manual/1m/2m/5m/15m/30m/Adaptive的具体解析与回落规则见 docs/refresh-loop.md。运行时 Provider 设置类型化的快照注册第三条流是运行时才有的 provider 设置它们不写死进SettingsStore而是通过类型化、描述符注册的 section 汇入ProviderSettingsSnapshot再由设置界面按 provider 动态渲染。这样新增 provider 无需改动设置面板骨架只需注册自己的描述符与 section 类型。后台刷新的自适应节奏UsageStore通过startTimer()在每个 tick 前采集当前时间、上次开菜单时间、本地编码活动时间、低电量模式与热状态等不纯信号交给纯函数AdaptiveRefreshPolicySources/CodexBar/AdaptiveRefreshPolicy.swift计算下一次延迟与稳定的Reason——策略本身不读时钟、不读ProcessInfo天然可测试仓库中AdaptiveRefreshPolicyTests、AdaptiveRefreshHeuristicsTests即针对此设计。CLI 登录生命周期可取消、有超时、可诊断架构文档用较大篇幅描述了登录流程这是全项目进程管理最精细的部分分为三层第一层Provider 专属 RunnerCodexLoginRunnerSources/CodexBar/CodexLoginRunner.swift解析自身可执行文件与环境通过PathBuilder.effectivePATH(purposes: [.rpc, .tty, .nodeTooling], ...)构造 PATH再用CodexHomeScope.scopedEnvironment(base:codexHome:)注入 Codex home 作用域最后定位 codex 二进制并调用CLILoginRunner.run。默认超时 120 秒、输出排空超时 3 秒。KiroLoginRunnerSources/CodexBar/Providers/Kiro/KiroLoginRunner.swift与 Codex 同构说明该模式可复用于任意等待浏览器授权的 CLI 登录。第二层通用登录执行器CLILoginRunnerSources/CodexBar/CLILoginRunner.swift 是核心它统一返回一个Result类型enum Outcome: Equatable, Sendable { case success case cancelled case timedOut case failed(status: Int32) case missingBinary case launchFailed(String) }其执行过程的关键设计进程组管理setpgid(pid, pid)成功后记录processGroup超时/取消时由SubprocessRunner.terminateProcess(process, processGroup:)对整个进程组发起终止确保子进程不会泄漏。有界等待BoundedTaskJoin将退出任务封装为带 join grace 的有限等待区分.value正常退出/.failure取消/.timedOut超时三种结局。进度上报pollProgress每 500ms 扫描 stdout/stderr 快照一旦出现http://或https://即通过onProgress回调上报供界面展示浏览器授权链接随后立即退出轮询。诊断保留与防阻塞无论成功失败ProcessPipeCapture.finish(timeout:)都以有界时间排空输出默认 3 秒合并 stdout/stderr 后截取前 4000 字符保留继承的管道不会让调用方无限等待。取消登录时终止子进程、join 进度任务并不产生失败弹窗超时则保留捕获到的诊断输出。第三层共享的进程终止原语CLILoginRunner与SubprocessRunnerSources/CodexBarCore/Host/Process/SubprocessRunner.swift共享ProcessTerminationSources/CodexBarCore/Host/Process/ProcessTermination.swift与进程树终止逻辑。从源码搜索看这一原语被 Gemini、Doubao、Bedrock、Augment、Antigravity、Claude、VertexAI、Alibaba、Amp 等多个 provider 的 CLI 探针复用是全项目进程管理的统一底座。CodexBarClaudeWatchdog的killProcessTree同样实现了SIGTERM→ 轮询waitpid0.5 秒宽限→SIGKILL的降级序列与 App 层逻辑互为印证。并发与平台约束架构文档明确了两条硬约束重构与新增代码时必须遵守Swift 6 严格并发代码库启用-strict-concurrency倾向使用 Sendable 状态与显式MainActor跳转。典型体现CLILoginRunner.Result声明为Equatable, SendableStatusItemControlling协议与StatusItemController类标注MainActoronProgress回调类型为Sendable (String) - VoidCodexbarApp的 init 与 AppDelegate 方法均在MainActor上下文中完成状态组装与 UI 接管。macOS 14 目标重构时应避免已废弃 API。例如configureAppIconForMacOSVersion()用#unavailable(macOS 26)在旧系统上切换经典非 Liquid Glass图标体现了对系统版本差异的显式处理。数据模型与跨模块类型示例为帮助读者建立模块边界即类型边界的认知这里给出一个贯穿三层的示例配额窗口数据。CodexBarCore的UsageFetcher.swift定义RateWindow含占位标志与回填逻辑——这是抓取层的输出契约CodexBar的UsageStore将各 provider 的RateWindow汇总为快照并驱动menuObservationToken——这是状态层的聚合StatusItemController与 Widget 消费快照渲染百分比与重置倒计时——这是展示层的消费。新增一个 provider 时遵循该链路即可在CodexBarCore/Providers/下实现 fetcher 与解析器产出RateWindow在 App 层注册描述符与设置 sectionUsageStore通过 provider registry 自动纳入刷新与聚合。延伸阅读架构文档末尾推荐的三个专题文档与本文形成完整的知识闭环docs/providers.md69 个已注册 provider 的抓取策略web/cli/oauth/api token/local probe/web dashboard与数据来源说明docs/refresh-loop.md刷新节奏取值、Adaptive 模式的纯函数策略与存量配置回落规则docs/ui.md菜单与图标的 UI 呈现层设计。对于想从测试侧验证架构设计的读者仓库的 Tests/CodexBarTests 与 TestsLinux 提供了针对AdaptiveRefreshPolicy、登录隔离、进程清理等机制的大量回归用例可作为阅读架构文档后按图索骥的实践入口。【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考