Lithe 模块化架构解析：从 Module 生命周期到插件签名体系的完整指南

• 开发工具
• 代码编辑器
• AI 应用
• 人工智能
• 插件系统

Lithe（Lithe-IDEA）是一款轻量级跨平台 IDE，面向 AI 时代提供按需加载的工具与服务。它的低内存秘诀藏在模块化架构里：每个功能都是可独立启停的 Module，配合严格的插件签名体系，保证官方插件包分毫未改。本文带你从 Module 生命周期讲到插件 Ed25519 签名验证，看懂这套架构如何把基线内存压到 300–400 MB。

上面这张截图里，每种语言的服务都可以单独开关——这正是模块化架构在产品层面的直接体现：语言服务器模块按需激活、空闲休眠，而不是全部常驻内存。

架构总览：三个层次的分工

Lithe 的模块化体系分为清晰的三层，职责互不越界：

核心思想一句话：模块只描述"我是谁、我需要什么"，运行时统一决定"何时启动、何时休眠"。

内置模块目录：一份声明式清单

所有内置模块的"身份证"集中声明在 BuiltInModuleCatalog.swift 中，包括 Workspace Foundation、Git Review、Database、Terminal、Build / Run / Test、AI Assistance 等十余个模块。

每个 ModuleManifest 声明五个关键属性：

• activationPolicy：eager（启动即激活）/onDemand（用到才激活）/manual
• sleepPolicy：如.whenIdle(afterSeconds: 600)，空闲多久后休眠
• dependencies：依赖哪些模块或能力
• providedCapabilities：对外提供哪些能力
• isRequired：是否为必需模块（必需模块不可被禁用）

以 Workspace 模块为例：它是唯一eager且isRequired的模块，因为 Git、搜索、终端等都依赖它的workspace-foundation能力。而其他模块几乎全部是onDemand——这正是"按需服务"的落地方式。

模块生命周期：从激活到休眠的完整流转

生命周期状态机定义在 ModuleTypes.swift 的ModuleState中：disabled → inactive → activating → active → idle → preparingToSleep → sleeping，另有sleepBlocked和failed两个异常分支。

驱动这一切的是 ModuleRuntime.swift，关键规则有：

1. 先验证依赖图，再启动：validateGraph()会检查依赖缺失、能力冲突（两个模块提供同一能力）和依赖环，全部通过后才允许启动任何模块。
2. 激活时递归拉起依赖：激活某模块前，其声明的模块/能力依赖会先被激活。
3. 资源租约防止误休眠：模块可以发放 lease（租约）登记"我正在被使用"，只要还有活动租约或活跃资源，sleep()就会拒绝休眠并进入sleepBlocked状态。
4. 空闲自动休眠：ModuleLifecycleCoordinator.swift 每 30 秒评估一次，空闲超过sleepPolicy时长的模块会被优雅地prepareForSleep() → sleep() → 停止资源 → 释放实例。
5. 失败自动恢复：激活期间若进程意外退出，下次启动时 ModuleRecoveryStore 会把"卡在激活中"的模块隔离（quarantine），保证应用外壳能先启动，用户再手动重新启用即可。
6. 安全模式：ModuleLaunchMode.safeMode下只运行必需模块，用于排障。

配套的 verify-module-boundaries.sh 脚本在 CI 中强制执行架构纪律：特性实现不得泄漏回主应用、模块必须拥有独立生命周期测试、模块不得导入 SwiftUI/AppKit——保证"模块边界"不会随开发慢慢腐化。

插件体系：Manifest 静态验证

除了内置模块，Lithe 支持以插件包形式分发的官方插件（如 PHP 支持），按平台组织在 Plugins/ 目录下。

一份真实的插件清单 Plugins/mac/Official/PhpSupport/plugin.json 展示了完整声明：

• 声明apiVersion与hostCompatibility（最低 0.3.0、最高不含 0.4.0）
• 声明两个模块：dev.lithe.language.php.execution与dev.lithe.language.php.language-server，均为onDemand+ 空闲 600 秒休眠
• 声明语言识别规则：.php扩展名、composer.json项目文件

加载前，PluginManifestValidator.swift 会对整个插件目录做静态验证：schema 版本、API 版本、宿主兼容性、模块 ID 是否被多个插件抢占、语言支持声明是否合法，以及入口点（builtIn 或 nativeBundle）元数据是否自洽。任何一条不满足，插件根本不会进入运行时。

插件代码通过 LithePluginEntrypoint 入口协议返回模块工厂，并且只能通过PluginHostContext按 ID 获取宿主服务——插件无法直接 import 应用可执行目标，天然隔离。

插件签名体系：Ed25519 保证分毫未改

单独分发（非内置）的官方插件包，必须通过 PluginPackageSignature.swift 定义的软件包签名。这套体系与 Apple 代码签名相互独立、双重防护，流程如下：

1. 文件摘要：递归遍历包内所有文件，计算 SHA-256 摘要；符号链接、路径穿越（..）、控制字符一律拒绝。
2. 规范化负载：将 schema 版本、算法（ed25519）、密钥 ID（lithe-official-plugins-v1）、插件 ID/版本与全部文件摘要，按排序后的行格式拼成规范化文本。
3. 签名：用发布方私钥对负载做 Ed25519 签名，连同摘要一起写入包内lithe-plugin-signature.json。
4. 验证：verify() 重新计算摘要，比对文件清单是否一致、每个文件摘要是否匹配、签名是否有效——任何一个文件被改动过，验证都会失败并抛出具体错误（如"文件在签名后被修改"）。

打包与分发由 macos/Tools/LithePluginPackageSigner/ 签名工具和 scripts/official-plugin-distribution.mjs 协同完成：只有明确内置的插件（如 Go Support）会随主程序分发，其余官方插件均通过插件管理界面单独安装，安装位置是已签名的资源包根目录。

这套架构给开发者的启示

• 声明先行，运行时收敛：Manifest 是唯一事实来源，静态验证（插件目录）+ 图验证（运行时）双重把关，问题在加载前就暴露。
• 能力优于依赖：模块间通过 capability ID 解耦，依赖的是"能做什么"而不是"谁是谁"。
• 生命周期即资源管理：租约、资源快照、空闲休眠策略把"内存何时释放"变成了可推理的问题。
• 签名防篡改：文件级摘要 + Ed25519 签名让每个插件包可独立鉴权。

如果你想继续深入，可以阅读 macos/README.md 了解 macOS 构建方式，或从 macos/Tests/LitheApplicationKernelTests/ModuleRuntimeTests.swift 入手，看生命周期各规则如何通过单元测试被完整覆盖。理解了这个从激活到休眠、从清单到签名的闭环，你就掌握了 Lithe 轻而稳的底层逻辑。

• 开发工具
• 代码编辑器
• AI 应用
• 人工智能
• 插件系统