企业官网建设流程全解析

1. 从"装完就吃灰"说起：Cordis 插件架构到底解决了什么

DeepSeek Harness 这个工具，很多人第一次接触是冲着"本地跑模型、离线写代码"去的，装完之后发现它本身只是个壳，真正决定它好不好用的，是插件。而 Cordis 就是这套插件体系的地基。我见过太多人把 Harness 装好、模型接上、然后对着空荡荡的界面发呆——不是工具不行，是没搞明白 Cordis 这套架构的设计逻辑，插件装了一堆却互相打架，或者干脆装不上。

先把结论摆前面：Cordis 不是一个"插件市场"，它是一套依赖注入 + 生命周期管理 + 服务注册的运行时框架。你可以把它理解成 Harness 内部的"操作系统内核"，插件是跑在这个内核上的进程。它管的事情包括：插件什么时候加载、依赖谁、暴露什么能力给别的插件、什么时候卸载、卸载时怎么清理。搞懂这四件事，Harness 的插件生态你就通了八成。

这篇文章适合三类人：一是刚装完 Harness、想搞清楚插件该怎么选怎么配的新手；二是想自己写插件、但被 Cordis 的 Fiber、Service、Context 这些概念绕晕的开发者；三是在内网/离线环境部署 Harness、需要把插件和 Skill 一起搬进去的运维同学。我会从架构原理讲到实操配置，再到踩坑排查，尽量把每个"为什么"都讲透，而不是甩一堆 API 让你自己猜。

需要提前说明的是，Cordis 的很多设计借鉴了现代前端框架的依赖注入思想（类似 Angular 的 Provider、Vue 的 provide/inject），如果你有 TypeScript 和前端工程化背景，理解起来会快很多。没有也没关系，我会用生活化的类比把概念拆开。

2. Cordis 的三根支柱：Context、Fiber 与 Service

要理解 Cordis，先得把三个核心概念吃透。这三个东西是整套架构的骨架，插件的一切行为都围绕它们展开。我用一个类比贯穿：把 Harness 想象成一栋大楼，Cordis 是物业管理公司，插件是入驻的商户。

2.1 Context：插件的"身份证 + 工具箱"

Context（上下文）是 Cordis 里最核心的对象。每个插件在加载时都会拿到一个属于自己的 Context 实例，这个实例既是它的身份标识，也是它访问外部能力的入口。

为什么需要 Context 而不是让插件直接 import 全局对象？因为隔离。如果所有插件都直接操作全局状态，A 插件改了配置，B 插件莫名其妙就崩了，排查起来是灾难。Context 通过一层代理，把"谁能访问什么"这件事管起来。插件想用数据库，得通过ctx.database；想用日志，得通过ctx.logger；想注册一个自己的服务给别人用，得通过ctx.provide()。

Context 还有一个关键特性：继承与派生。子 Context 会继承父 Context 的能力，但可以覆盖或追加。这就像商户可以共用大楼的水电（父 Context 提供的基础服务），但每家可以装自己的独立电表（子 Context 的私有配置）。插件加载时，Cordis 会给它创建一个子 Context，插件内部再创建的 Context 又是这个子 Context 的子级，形成一棵树。

实操中你会经常看到这样的代码结构：

import { Context } from 'cordis' export function apply(ctx: Context, config: PluginConfig) { // ctx 是 Cordis 注入的，不需要自己 new ctx.logger.info('插件已加载') // 注册一个服务供其他插件使用 ctx.provide('myService', { doSomething() { /* ... */ } }) // 监听事件 ctx.on('some-event', () => { /* ... */ }) }

这里apply函数是 Cordis 插件的标准入口。Cordis 在加载插件时，会调用这个函数，把 Context 和配置传进去。你不需要关心 Context 是怎么创建的，框架帮你搞定了。

注意：不要在apply函数外部持有ctx的引用。插件卸载后 Context 会失效，外部持有会导致内存泄漏或者调用报错。这是新手最容易踩的坑之一。

2.2 Fiber：插件的生命周期控制器

Fiber 是 Cordis 里管理插件生命周期的单位。每个插件实例对应一个 Fiber，Fiber 记录了插件的状态（加载中、已加载、卸载中、已卸载）、依赖关系、以及它注册的所有副作用（事件监听、定时器、服务等）。

为什么要有 Fiber？因为可撤销。插件卸载时，不能只是把代码从内存里删掉就完事，它注册的事件监听、开的定时器、占用的端口、注册的服务，统统要清理干净。Fiber 就是那个"记账本"，插件通过 Context 做的每一个有副作用的操作，都会被 Fiber 记录下来，卸载时统一回滚。

这解决了一个非常现实的问题：Harness 里插件热重载。你改了一个插件的配置，想让它重新加载，如果没有 Fiber 这套机制，旧插件残留的监听器会和新插件的一起触发，行为完全不可预测。有了 Fiber，卸载时自动清理，重新加载就是干净的状态。

Fiber 的状态流转大致是这样的：

理解这张表很重要。当你遇到"插件装了但没生效"的问题时，第一件事就是看它的 Fiber 处于什么状态。如果卡在 PENDING，说明依赖没满足；如果卡在 LOADING，说明 apply 函数里有异步操作没完成或者抛异常了。

2.3 Service：插件之间的"通信协议"

Service 是 Cordis 里插件互相调用的机制。一个插件通过ctx.provide('serviceName', implementation)注册服务，另一个插件通过ctx.serviceName或者ctx.get('serviceName')来消费。

这套机制的精髓在于解耦。插件 A 不需要知道插件 B 的存在，它只需要知道"系统里有一个叫 xxx 的服务"。谁提供了这个服务、怎么实现的，A 不关心。这样插件就可以自由替换——今天用本地模型服务，明天换成远程 API 服务，只要接口一致，上层插件不用改一行代码。

Service 的注册和消费有几个细节值得注意：

• 服务名冲突：如果两个插件注册了同名服务，后注册的会覆盖先注册的，但 Cordis 通常会给出警告。命名时建议加前缀，比如myplugin.database而不是笼统的database。
• 可选依赖：如果某个服务可能不存在，用ctx.get('serviceName')返回 undefined 而不是抛错，配合ctx.inject()声明可选依赖。
• 服务的作用域：服务注册在哪个 Context 上，就只在那个 Context 及其子级可见。全局服务注册在根 Context 上。

把这三个概念串起来看：Context 是入口，Fiber 是账本，Service 是接口。插件通过 Context 拿到能力，通过 Service 暴露能力，Fiber 在背后记录一切、负责清理。这三者配合，才有了 Harness 插件生态的稳定性和可扩展性。

3. 插件加载的完整链路：从配置文件到 apply 执行

搞懂了三个核心概念，接下来看一个插件从"你点了启用"到"真正跑起来"中间发生了什么。这条链路里藏着很多排查问题的线索，理解了它，遇到"插件装不上""插件不生效"这类问题你就能自己定位。

3.1 配置解析与依赖图构建

Harness 启动时，会读取插件配置文件（通常是 JSON 或 YAML 格式），里面列出了所有要加载的插件及其配置。Cordis 拿到这份清单后，第一件事不是急着加载，而是构建依赖图。

每个插件在声明时会通过inject字段声明自己依赖哪些服务。比如一个"代码补全"插件可能声明inject: ['llm', 'editor']，意思是它需要 LLM 服务和编辑器服务。Cordis 根据所有插件的 inject 声明，构建一张有向图，然后做拓扑排序，确定加载顺序。

为什么必须拓扑排序？因为如果插件 A 依赖插件 B 提供的服务，B 必须先加载。如果顺序错了，A 加载时找不到 B 的服务，就会失败。拓扑排序保证了"被依赖的先加载"。

这里有个常见的坑：循环依赖。如果 A 依赖 B，B 又依赖 A，拓扑排序就无解了。Cordis 检测到循环依赖会报错并拒绝加载相关插件。实际开发中，循环依赖往往不是真的需要，而是设计问题——通常可以通过提取公共部分成第三个插件来解决。

3.2 依赖注入与 apply 调用

依赖图确定后，Cordis 按顺序逐个加载插件。对每个插件，它会：

1. 创建该插件的子 Context，继承父 Context 的能力
2. 检查 inject 声明的服务是否都已就绪
3. 如果就绪，调用插件的apply(ctx, config)函数
4. 如果 apply 返回 Promise，等待它 resolve
5. 将 Fiber 状态置为 ACTIVE

第 3 步是关键。apply函数是插件逻辑的入口，你所有的初始化代码都写在这里。Cordis 不关心 apply 里面做了什么，它只关心 apply 有没有正常返回。

这里要强调一个实操要点：apply 函数应该尽快返回。如果你在 apply 里做耗时的同步操作（比如读一个大文件、做复杂计算），会阻塞整个加载流程，其他插件都得等着。正确的做法是把耗时操作放到异步任务里，或者用ctx.setTimeout延迟执行。

export function apply(ctx: Context, config: PluginConfig) { // 快速完成注册 ctx.provide('myService', createService(config)) // 耗时初始化放到异步任务 ctx.setTimeout(async () => { await heavyInitialization() ctx.logger.info('重型初始化完成') }, 0) }

用ctx.setTimeout而不是原生setTimeout的原因，是前者会被 Fiber 记录，插件卸载时自动清理。原生 setTimeout 如果没手动 clear，插件卸载后回调还会执行，访问已失效的 Context 就会报错。

3.3 卸载与热重载的清理逻辑

插件卸载时，Cordis 会遍历该插件 Fiber 记录的所有副作用，逐个清理：

• 移除所有通过ctx.on注册的事件监听
• 清除所有通过ctx.setTimeout/ctx.setInterval创建的定时器
• 注销所有通过ctx.provide注册的服务
• 调用所有通过ctx.effect注册的清理函数

清理完成后，Fiber 状态置为 DISPOSED，Context 失效。

热重载就是"卸载 + 重新加载"的组合。你改了插件配置，Harness 触发卸载，清理干净后再走一遍加载流程。因为清理彻底，新加载的插件不会受旧插件残留影响。

实操心得：如果你自己写插件，任何有副作用的操作都要通过 Context 提供的方法来做，不要用原生 API。原生 API 创建的副作用 Fiber 管不到，卸载时不会清理，这是内存泄漏和诡异 bug 的主要来源。我踩过最典型的一次是用了原生setInterval做轮询，插件卸载后轮询还在跑，日志疯狂刷屏，查了半天才发现是这个问题。

4. 实战：给 Harness 配一套能打的生产级插件组合

理论讲完，进入实操。这一节我按"一个开发者日常用 Harness 写代码"的场景，给出一套经过验证的插件组合方案，并解释每个插件为什么选它、配置时要注意什么。

4.1 按使用场景分类的插件选型

Harness 的插件大致可以分成几类，不同场景需要的组合不一样。先看一张分类表：

选型的第一原则是按需，不要一股脑全装。插件越多，加载越慢，冲突概率越高。我见过有人装了二十多个插件，结果启动要一分多钟，还经常有插件互相抢服务。正确的做法是先装核心的（模型接入 + 代码理解 + 编辑增强），跑顺了再按需加。

4.2 模型接入插件的配置要点

模型接入是所有插件的基础，没有它其他插件都是空转。配置时几个关键参数：

• 模型路径或 API 地址：本地模型填模型文件路径，远程服务填 API endpoint。注意路径要用绝对路径，相对路径在不同工作目录下会解析失败。
• 上下文长度：这个参数要和模型实际能力匹配。填大了模型处理不了会截断，填小了浪费能力。一般填模型标称值的 80% 比较稳妥。
• 并发数：本地模型受显存限制，并发数别开太高。经验值是显存 8G 开 1-2，16G 开 2-4，24G 以上可以开到 4-6。
• 超时时间：本地模型首次加载慢，超时时间给足，建议 120 秒起步。

配置完先做一次连通性测试，确认模型能正常响应再启用其他插件。这一步别省，不然后面出问题你分不清是模型的问题还是插件的问题。

4.3 代码索引与编辑增强的协同

代码索引插件负责把代码库向量化，编辑增强插件负责在补全时检索相关代码。这两个插件是协同工作的，配置时要保证它们的向量维度一致。如果索引插件用的是 768 维向量，编辑插件检索时也得用 768 维，否则检索结果全是乱的。

索引的粒度也值得调。默认按函数或类切块，对于大文件可能切得太碎，检索时上下文不完整。可以调大块大小，或者按语义边界切。我的经验是块大小控制在 500-1000 token 之间，重叠 100 token 左右，检索效果和上下文完整性比较平衡。

索引是耗资源的操作，首次全量索引可能要几分钟到几十分钟，取决于代码库大小。建议在空闲时做，索引完成后增量更新就快了。

4.4 Skill 与文件权限的坑

Skill 是 Harness 里执行具体任务的单元，比如"读文件""写文件""执行命令"。Skill 运行时插件负责调度这些 Skill。这里最容易出问题的是文件权限。

在 Windows 上，如果 Harness 没有以足够权限运行，Skill 读写某些目录会报setnamedsecurityinfow failed这类错误。解决办法有两个：一是把 Harness 的工作目录设在用户目录下（权限宽松），二是以管理员身份运行。Linux 下类似，注意工作目录的 owner 和权限位。

内网/离线部署时，Skill 依赖的外部工具（比如某些命令行程序）要提前装好，并且确保在 PATH 里。离线环境没法临时下载，缺什么就是缺什么，部署前一定要列清单核对。

5. 自己写一个 Cordis 插件：从零到能跑

用别人的插件是消费，写自己的插件才是真正掌握这套架构。这一节我带你把一个最小可用插件写出来，然后逐步加上依赖注入、服务注册、配置项这些能力。

5.1 最小插件骨架与 TypeScript 类型声明

一个 Cordis 插件的最小结构就是一个导出apply函数的模块。但要用好 TypeScript 的类型系统，需要做一些声明扩展。

import { Context, Schema } from 'cordis' // 声明插件配置的类型 export interface Config { greeting: string repeat: number } // 用 Schema 定义配置校验规则 export const Config: Schema<Config> = Schema.object({ greeting: Schema.string().default('hello'), repeat: Schema.number().default(1), }) // 插件元信息 export const name = 'my-plugin' export const inject = ['logger'] // 声明依赖 // 插件入口 export function apply(ctx: Context, config: Config) { for (let i = 0; i < config.repeat; i++) { ctx.logger.info(config.greeting) } }

这里有几个 TypeScript 相关的点要展开。Schema是 Cordis 提供的配置校验工具，它既做运行时校验，也做类型推导。你定义了 Schema，Config 的类型就能自动推出来，不用手写两遍。

关于.d.ts声明文件：如果你要扩展 Context 的类型（比如给 ctx 加一个自定义属性），需要做模块声明扩展：

declare module 'cordis' { interface Context { myCustomService: MyServiceType } }

这段声明告诉 TypeScript，"Context 上有一个 myCustomService 属性"。没有这段声明，你在代码里写ctx.myCustomService会报类型错误。这是 TypeScript 项目里扩展第三方库类型的标准做法，Harness 插件开发里非常常用。

注意：声明扩展要放在能被 TypeScript 编译到的文件里，通常放在插件的入口文件或者单独的types.d.ts里，并在 tsconfig 的 include 里包含它。放错位置会导致类型不生效，但运行时又是对的，这种"类型和运行时不一致"的问题最难查。

5.2 依赖注入与服务暴露的写法

插件之间协作靠 Service。假设我们写一个"翻译服务"插件，它依赖 LLM 服务，同时暴露翻译能力给别的插件用。

import { Context, Schema, Service } from 'cordis' export const inject = ['llm'] // 依赖 LLM 服务 export interface Config { targetLang: string } export const Config: Schema<Config> = Schema.object({ targetLang: Schema.string().default('zh'), }) // 定义服务类 class TranslateService extends Service { constructor(ctx: Context, private config: Config) { super(ctx, 'translate') } async translate(text: string): Promise<string> { // 通过 ctx.llm 访问依赖的服务 const prompt = `Translate to ${this.config.targetLang}: ${text}` return this.ctx.llm.complete(prompt) } } export function apply(ctx: Context, config: Config) { // 注册服务，其他插件可以通过 ctx.translate 访问 ctx.plugin(TranslateService, config) }

这段代码里有几个关键点。inject: ['llm']声明了依赖，Cordis 会保证在 apply 执行前 llm 服务已就绪。Service基类提供了服务注册的标准模式，继承它并调用super(ctx, 'serviceName')就完成了注册。服务方法里通过this.ctx.llm访问依赖，这个 ctx 是 Cordis 注入的，不是自己 new 的。

服务暴露出去后，别的插件只要声明inject: ['translate']，就能通过ctx.translate.translate(text)调用。整个过程中，调用方不知道 TranslateService 的存在，只知道有个 translate 服务，这就是解耦的价值。

5.3 配置项校验与默认值处理

配置校验是插件健壮性的第一道防线。用户填错配置是常态，好的插件应该在加载时就报出清晰的错误，而不是运行到一半莫名其妙崩溃。

Cordis 的 Schema 支持丰富的校验规则：

export const Config: Schema<Config> = Schema.object({ // 字符串，必填，有默认值 apiKey: Schema.string().required(), // 数字，范围限制 timeout: Schema.number().min(1000).max(60000).default(30000), // 枚举 mode: Schema.union(['fast', 'balanced', 'quality']).default('balanced'), // 数组 excludeDirs: Schema.array(Schema.string()).default(['node_modules', '.git']), // 嵌套对象 advanced: Schema.object({ retries: Schema.number().default(3), }).default({}), })

Schema 的好处是校验和类型推导一体。你定义一次，运行时校验和编译时类型都有了。而且 Schema 的默认值处理很智能，用户没填的字段自动用默认值，不用在代码里写一堆config.x ?? defaultX。

配置校验失败时，Cordis 会拒绝加载插件并给出错误信息。错误信息里会指明哪个字段、期望什么类型、实际是什么。排查配置问题时，先看这条错误信息，八成能直接定位。

5.4 插件调试与日志排查

插件写完了，怎么确认它工作正常？日志是第一工具。Cordis 的 logger 服务支持分级输出：

ctx.logger.debug('调试信息，开发期看') ctx.logger.info('常规信息') ctx.logger.warn('警告，可能有问题') ctx.logger.error('错误，需要处理')

开发期把日志级别调到 debug，能看到插件加载的详细过程。生产环境调到 info 或 warn，避免日志刷屏。

除了日志，Cordis 还提供了插件状态查询。你可以通过 Harness 的调试面板或者命令行查看所有插件的 Fiber 状态、依赖关系、注册的服务。插件不生效时，先看状态，再看依赖，最后看日志，这个顺序能覆盖 90% 的问题。

实操心得：写插件时养成"每个关键节点打一条日志"的习惯。加载开始、依赖就绪、服务注册完成、初始化完成，各打一条。出问题时看日志就知道卡在哪一步。我见过太多插件出问题只能靠猜，就是因为日志太少，根本不知道执行到哪了。

6. 插件装不上、不生效、互相打架：排查链路实录

这一节是纯干货，把我实际遇到过的几类典型问题，按排查过程完整还原。你遇到类似问题时可以照着这个思路走。

6.1 依赖未满足导致的静默失败

现象：插件在配置里启用了，但完全没反应，日志里也没有明显报错。

排查过程：第一步看 Fiber 状态，发现卡在 PENDING。PENDING 意味着依赖没满足。查看插件的 inject 声明，发现它依赖database服务，但当前没有插件提供这个服务。Cordis 不会因为依赖缺失就报错，它只是把插件挂起，等依赖出现。如果依赖永远不出现，插件就永远不加载。

解决：要么装上提供 database 服务的插件，要么把该依赖改成可选（用ctx.get而不是ctx.database直接访问）。改可选后，插件会在依赖缺失时用降级逻辑运行。

教训：插件"启用但无反应"，第一反应就是查依赖。Cordis 的静默挂起机制是设计如此，但对新手不友好，容易误以为插件坏了。

6.2 服务名冲突引发的覆盖问题

现象：两个功能相似的插件同时启用后，其中一个行为异常，像是用了另一个插件的配置。

排查过程：查日志发现有一条服务覆盖警告，两个插件都注册了名为completion的服务，后加载的覆盖了先加载的。上层插件调用ctx.completion时，拿到的是后加载的那个，但它的配置和预期不符。

解决：给服务名加命名空间前缀，比如pluginA.completion和pluginB.completion。或者只启用其中一个插件。

教训：服务命名要加前缀，这是 Cordis 插件开发的约定。裸服务名（如database、logger）留给框架核心服务，插件自己的服务一律加前缀。

6.3 原生副作用导致的卸载残留

现象：插件热重载后，旧插件的行为还在，和新插件叠加，日志重复输出。

排查过程：检查插件代码，发现用了原生setInterval做轮询，没有用ctx.setInterval。插件卸载时，Cordis 清理了它记录的副作用，但原生 setInterval 不在记录里，所以还在跑。旧轮询访问已失效的 Context，报了一堆错。

解决：把所有原生副作用 API 换成 Context 提供的版本。setTimeout→ctx.setTimeout，setInterval→ctx.setInterval，事件监听用ctx.on而不是addEventListener。

教训：这是 Cordis 插件开发最核心的纪律——所有副作用必须走 Context。违反这条，热重载和卸载就会出问题。

6.4 内网离线环境的部署清单

现象：在内网服务器部署 Harness，插件装不上，Skill 执行报错。

排查过程：内网没有外网访问，插件的依赖包下载不了，Skill 依赖的外部工具也没装。逐个核对后发现缺了三样：插件的 npm 依赖包、Skill 需要的命令行工具、模型文件。

解决：在外网环境准备好所有依赖，打包成离线包，拷进内网。部署前用清单核对：

教训：离线部署的核心是"清单化"。别靠记忆，列清单逐项核对。我吃过一次亏，漏了一个 Skill 依赖的小工具，部署到内网才发现，又得重新走一遍审批流程拷文件，浪费一整天。

7. 让插件组合真正提效的几个配置技巧

插件装对了只是及格，配置调优才能让它真正好用。这一节分享几个我反复验证过的配置技巧。

7.1 提示词优化插件的上下文管理

提示词优化插件（提示词管理器）的核心价值是管理上下文。Harness 写代码时，上下文里塞什么、塞多少，直接决定输出质量。几个配置要点：

• 上下文预算：给提示词留的 token 预算别超过模型上下文长度的 60%，剩下的留给模型输出和系统提示。
• 检索优先级：当前编辑的文件 > 最近修改的文件 > 语义相关的文件 > 其他。按这个优先级填充上下文，相关性最高。
• 去重：同一段代码可能被多个来源检索到，去重能省不少 token。

这些参数没有万能值，要根据你的代码库和模型调。建议先按默认值跑，观察输出质量，再针对性调整。

7.2 代码回退与版本快照的配合

Harness 的代码回退功能依赖版本快照。配置时注意快照的粒度和保留策略：

• 快照粒度：按"每次模型修改前"打快照，粒度太细会占空间，太粗回退不精确。
• 保留策略：保留最近 N 个快照，或者保留最近 M 天的。N 和 M 根据你的磁盘空间和回退需求定。
• 快照位置：放在工作目录外的独立目录，避免被代码索引插件索引到，浪费索引资源。

回退功能在模型改错代码时是救命稻草。我建议默认开启，快照保留至少 50 个，磁盘占用不大但关键时刻能救急。

7.3 多插件协同的性能调优

插件多了之后，性能问题会显现。几个调优方向：

• 延迟加载：不是所有插件都需要在启动时加载。把非核心插件配成按需加载，启动能快不少。
• 索引缓存：代码索引插件的索引结果要缓存，避免每次启动重新索引。缓存目录放在 SSD 上，读取快。
• 并发控制：多个插件同时调用模型时，并发数要统一控制，避免把模型服务打爆。可以在模型接入插件层做全局并发限制。

性能调优没有银弹，核心是"观察 - 定位 - 调整"循环。先用性能面板看哪个环节慢，再针对性优化，别盲目调参数。

8. 关于这套架构，我踩过之后才明白的几件事

写到这里，Cordis 插件架构的核心内容基本覆盖了。最后分享几点个人体会，都是踩过坑之后才真正理解的。

第一，Context 不是可有可无的包装，它是隔离的边界。刚开始写插件时我觉得 Context 麻烦，直接 import 全局对象多简单。后来插件一多，全局状态互相污染，排查到崩溃，才明白 Context 这层代理的价值。它强制你声明依赖、明确边界，短期麻烦，长期省心。

第二，Fiber 的自动清理是热重载的前提。没有 Fiber 记录副作用，热重载就是灾难。我早期写插件不守规矩，用原生 API，热重载后各种诡异行为。后来严格走 Context，热重载变得丝滑，改配置秒生效，开发效率完全不一样。

第三，Service 的解耦让插件可以自由组合。这套机制最大的好处是，你可以像搭积木一样组合插件，只要接口一致，实现随便换。今天用本地模型，明天换远程 API，上层插件不用动。这种灵活性在快速迭代的场景下价值巨大。

第四，离线部署的功夫在部署之前。内网环境没有试错空间，所有依赖必须提前备齐。清单化、逐项核对，是唯一可靠的方法。别指望"到时候再说"，内网里没有"到时候"。

这套架构还在演进，插件生态也在丰富。但底层这三根支柱——Context、Fiber、Service——是稳定的。把这三点吃透，无论插件怎么变，你都能快速上手。