加速器插件与加速模式
加速器（Accelerator）插件是 Watt Toolkit（SteamTools）中实现"网络加速"能力的客户端插件模块，以独立项目 BD.WTTS.Client.Plugins.Accelerator 存在，并依托兄弟项目 BD.WTTS.Client.Plugins.Accelerator.ReverseProxy 提供反向代理、DNS 解析与证书管理等底层服务。本文介绍该插件的工程结构、编译标识、与宿主应用的集成方式，以及加速能力所依赖的代理服务组件划分。
Purpose and Scope
本页覆盖以下内容：
- 加速器插件项目（
BD.WTTS.Client.Plugins.Accelerator）的工程结构与构建配置 - 插件编译常量（
WTTS_PLUGIN、WTTS_PLUGIN_ACCELERATOR）的标识机制与设计意图 - 插件与宿主应用（
BD.WTTS.Client.Avalonia.Designer.HostApp）的集成方式 - 插件与
Accelerator.ReverseProxy子系统之间的源码级共享（Compile Include）关系 - 加速能力所依赖的服务组件划分：反向代理中间件、DNS（DoH）解析服务、证书生成与管理
- 与上述组件相关的单元测试覆盖情况
以下内容属于兄弟页面，本页仅做指引、不展开：
- 反向代理 HTTP 中间件的内部实现细节（脚本注入插入位置查找等），参见 ReverseProxy 相关页面
- DNS over HTTPS 解析服务的完整实现，参见 DNS 解析服务页面
- 证书生成器（
CertGenerator）的算法细节，参见证书管理页面 - 插件的 UI 页面与视图模型实现细节
说明：本次源码核查受工具调用预算限制，未能读取插件内部的 C# 实现文件（如加速模式枚举、服务接口的完整签名）。涉及这些细节处，文中会明确标注"实现细节未在本次源码核查范围内"，不做臆测。所有可验证结论均来自已读取的构建配置文件（
.csproj）中的真实内容。
Overview
Watt Toolkit 采用"插件化项目 + 共享源码"的组织方式来实现加速器功能：
- 独立插件项目：
BD.WTTS.Client.Plugins.Accelerator是一个独立的 Avalonia 客户端插件项目，通过<DefineConstants>注入WTTS_PLUGIN与WTTS_PLUGIN_ACCELERATOR两个编译符号，使插件代码可以用条件编译（#if WTTS_PLUGIN_ACCELERATOR）区分插件内代码与通用代码。 - 宿主引用集成：宿主应用
BD.WTTS.Client.Avalonia.Designer.HostApp通过ProjectReference引用该插件项目，将加速器编译进宿主程序。 - 源码级共享：插件项目并不通过项目引用依赖整个 ReverseProxy 项目，而是用
<Compile Include>精确摘取 ReverseProxy 中的契约与常量文件（ICertificateManager、IDnsAnalysisService.Constants），在保持契约一致的同时避免引入完整实现。 - 底层服务支撑：真正的加速执行链路由 ReverseProxy 子系统提供，包括 HTTP 反向代理中间件（
HttpReverseProxyMiddleware）、DNS over HTTPS 解析（DnsDohAnalysisService）以及自签证书生成（CertGenerator）。 - 关键路径有测试兜底：
BD.WTTS.UnitTest项目以同样的"源码摘取"方式直接编译了脚本注入插入位置查找、证书生成、DoH DNS 解析等关键实现文件，对加速链路中最易出错的边界逻辑进行单元测试。
关键概念
| 概念 | 说明 |
|---|---|
| 插件（Plugin） | 以独立 .csproj 组织的功能模块，通过 ProjectReference 被宿主引用，通过 WTTS_PLUGIN* 编译符号标识 |
| 编译常量（DefineConstants） | WTTS_PLUGIN 与 WTTS_PLUGIN_ACCELERATOR，用于条件编译与插件边界识别 |
| 源码共享（Compile Include） | 跨项目摘取单个 .cs 文件参与编译，而非引用整个项目，用于共享契约/常量 |
| 反向代理中间件 | HttpReverseProxyMiddleware，加速流量转发与内容处理的核心中间件 |
| DoH DNS 解析 | DnsDohAnalysisService，基于 DNS over HTTPS 的域名解析服务 |
| 证书管理 | ICertificateManager 契约与 CertGenerator 实现，支撑 HTTPS 流量代理所需的自签证书 |
Architecture
Loading diagram...
架构要点说明：
- 宿主 → 插件是强集成关系：
HostApp对插件是完整的ProjectReference（实线），加速器作为宿主的组成部分一起编译发布；而插件对 ReverseProxy 是"按需摘取"的松耦合关系（虚线Compile Include），只拿契约与常量，不拖入整个实现。 - 测试项目采用同一模式：
BD.WTTS.UnitTest不引用整个 ReverseProxy 项目（项目引用在 csproj 中被注释掉），而是直接编译被测源文件，这使得单元测试可以在不启动完整插件的前提下测试算法级逻辑（如脚本注入插入位置的查找）。 - 加速链路的职责划分：DNS 解析（
DnsDohAnalysisService）、证书（CertGenerator/ICertificateManager）与 HTTP 反向代理（HttpReverseProxyMiddleware）分属独立的可测试单元。
主内容：工程结构与集成机制
插件标识：编译常量 WTTS_PLUGIN 与 WTTS_PLUGIN_ACCELERATOR
加速器插件项目在 .csproj 中注入了专属编译符号：
xml
1<PropertyGroup>
2 <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
3 <DefineConstants>WTTS_PLUGIN;WTTS_PLUGIN_ACCELERATOR;$(DefineConstants)</DefineConstants>
4 <!--<EnableDynamicLoading>true</EnableDynamicLoading>-->
5</PropertyGroup>Source: BD.WTTS.Client.Plugins.Accelerator.csproj
设计意图：
WTTS_PLUGIN是所有插件共享的通用符号，允许编写跨插件通用、但与核心程序集有差异的代码路径。WTTS_PLUGIN_ACCELERATOR是加速器插件独有的符号，其他插件（如ArchiSteamFarmPlus，同样被宿主引用）使用各自的后缀符号。这种"通用前缀 + 插件后缀"的命名约定让源码中的#if条件编译可以精确到具体插件。<EnableDynamicLoading>被注释掉，表明插件当前并非运行时动态加载（无AssemblyLoadContext隔离），而是编译期静态链接进宿主——"插件"在此更多是代码组织与构建边界意义上的划分，而非运行时热插拔。AllowUnsafeBlocks=true提示插件内存在非托管/指针级代码，这在网络栈（如 socket、内存拷贝）中常见。
宿主集成：ProjectReference
宿主设计器应用直接引用插件项目：
xml
1<ItemGroup>
2 <ProjectReference Include="..\BD.WTTS.Client.Avalonia\BD.WTTS.Client.Avalonia.csproj" />
3 <ProjectReference Include="..\BD.WTTS.Client.Plugins.Accelerator\BD.WTTS.Client.Plugins.Accelerator.csproj" />
4 <ProjectReference Include="..\BD.WTTS.Client.Plugins.ArchiSteamFarmPlus\BD.WTTS.Client.Plugins.ArchiSteamFarmPlus.csproj" />
5</ItemGroup>Source: BD.WTTS.Client.Avalonia.Designer.HostApp.csproj
这体现了 Watt Toolkit 的插件装配模型：宿主（HostApp）本身很薄，通过逐条 ProjectReference 把各功能插件"装配"成完整的客户端。新增一个插件 = 新建插件项目 + 在宿主加一条引用，无需修改插件框架本身。
与 ReverseProxy 子系统的源码级契约共享
插件项目从 ReverseProxy 项目摘取了两份契约/常量文件：
xml
1<ItemGroup>
2 <Compile Include="..\BD.WTTS.Client.Plugins.Accelerator.ReverseProxy\Services\Certificate\ICertificateManager.cs">
3 <LinkBase>Services\Certificate</LinkBase>
4 </Compile>
5 <Compile Include="..\BD.WTTS.Client.Plugins.Accelerator.ReverseProxy\Services\Net\IDnsAnalysisService.Constants.cs">
6 <LinkBase>Services\Net</LinkBase>
7 </Compile>
8</ItemGroup>Source: BD.WTTS.Client.Plugins.Accelerator.csproj
这段配置揭示了两个重要的设计决策：
- 契约优先，实现解耦：插件只摘取
ICertificateManager（证书管理契约）与IDnsAnalysisService.Constants（DNS 解析常量），而不是整个 ReverseProxy 项目。插件侧代码面向接口与常量编程，具体实现由宿主侧在运行时通过 DI 容器装配——这保证了插件 UI/逻辑与代理引擎可以独立演进。 LinkBase保持目录语义：<LinkBase>让被摘取的文件在插件项目内仍显示在Services\Certificate、Services\Net等与原项目相同的逻辑目录下，避免代码导航时契约"漂移"到根目录。
实现细节未在本次源码核查范围内：
ICertificateManager与IDnsAnalysisService的完整方法签名未读取，无法在本页给出参数/返回值级别的 API 文档。
插件资源与 UI 层
插件自带图标与背景资源，作为 Avalonia 资源嵌入：
xml
1<ItemGroup>
2 <None Remove="UI\Assets\accelerator.ico" />
3 <None Remove="UI\Assets\defaultBackground.png" />
4</ItemGroup>
5<ItemGroup>
6 <AvaloniaResource Include="UI\Assets\accelerator.ico" />
7 <AvaloniaResource Include="UI\Assets\defaultBackground.png" />
8</ItemGroup>Source: BD.WTTS.Client.Plugins.Accelerator.csproj
accelerator.ico 是插件在主界面的功能图标，defaultBackground.png 是加速器页面的默认背景图——说明加速器是客户端中带独立视觉呈现的一级功能入口。
加速模式：执行链路的组件划分
从已核查的源码看，加速能力由 ReverseProxy 子系统中的三类服务协同实现：
Loading diagram...
上图为依据源码中真实存在的服务划分绘制的职责协作示意，不表示精确的运行时调用时序；各服务间的确切调用顺序未在本次源码核查范围内。
三个组件的职责与证据来源：
| 组件 | 文件（位于 Accelerator.ReverseProxy 项目） | 职责（依据文件路径与测试内容推断的边界） |
|---|---|---|
| HTTP 反向代理中间件 | Services.Implementation/HttpServer/Middleware/HttpReverseProxyMiddleware.cs | 承接被加速的 HTTP(S) 流量并转发；存在 FindScriptInjectInsertPosition 分部文件，说明其具备向响应 HTML 注入脚本的能力（如缓存控制、脚本替换） |
| DoH DNS 解析 | Services.Implementation/Net/DnsDohAnalysisService.cs + Services/Net/IDnsAnalysisService(.Constants).cs | 以 DNS over HTTPS 方式解析域名，避免本地 DNS 污染对加速链路的影响；常量文件独立拆分供插件共享 |
| 证书生成 | Services.Implementation/Certificate/CertGenerator.cs + Services/Certificate/ICertificateManager.cs | 生成代理 HTTPS 流量所需的自签证书；配套 ICertificateManager 契约管理证书生命周期 |
关于"加速模式"（如系统代理 / 进程代理 / TUN 等具体模式枚举）：AccelerateMode 之类的枚举定义与切换逻辑位于插件内部 C# 代码中，未在本次源码核查范围内读取到，本页不作臆测。可确认的客观事实是：加速的执行面由上述"反向代理 + DoH DNS + 自签证书"三件套构成，这正是 HTTPS 流量本地代理的标准技术组合——中间件负责转发与内容处理，证书服务解决 TLS 拦截的可信问题，DoH 解决域名解析的污染问题。
配置选项（构建层面）
加速器插件可从构建配置文件确认的选项如下：
| 选项 | 类型 | 默认值 | 说明 |
|---|---|---|---|
WTTS_PLUGIN | 编译符号 | 插件内启用 | 所有插件共用的通用标识，供 #if 条件编译使用 |
WTTS_PLUGIN_ACCELERATOR | 编译符号 | 插件内启用 | 加速器插件专属标识，其他插件使用各自后缀 |
AllowUnsafeBlocks | bool | true | 允许插件内使用 unsafe 代码（网络栈常见需求） |
EnableDynamicLoading | bool | 注释禁用（未启用） | 未启用运行时动态加载，插件为编译期静态集成 |
Compile Include（ICertificateManager 等） | ItemGroup 项 | 2 个文件 | 从 ReverseProxy 摘取契约/常量参与插件编译 |
AvaloniaResource（accelerator.ico 等） | ItemGroup 项 | 2 个资源 | 插件图标与页面默认背景图 |
运行时配置项（如加速端口、代理模式开关、证书设置等）位于插件与 ReverseProxy 的 C# 实现代码中，未在本次源码核查范围内，此处不列出。
测试覆盖
BD.WTTS.UnitTest 项目对加速链路的关键算法做了单元测试，其取材方式与插件一致——直接编译被测源文件：
xml
1<ItemGroup>
2 <Compile Include="..\BD.WTTS.Client.Plugins.Accelerator.ReverseProxy\Services.Implementation\HttpServer\Middleware\HttpReverseProxyMiddleware.FindScriptInjectInsertPosition.cs">
3 <LinkBase>Services.Implementation\HttpServer\Middleware</LinkBase>
4 </Compile>
5 <Compile Include="..\BD.WTTS.Client.Plugins.Accelerator.ReverseProxy\Services.Implementation\Certificate\CertGenerator.cs">
6 <LinkBase>Services.Implementation\Certificate</LinkBase>
7 </Compile>
8 <Compile Include="..\BD.WTTS.Client.Plugins.Accelerator.ReverseProxy\Services.Implementation\Net\DnsDohAnalysisService.cs">
9 <LinkBase>Services.Implementation\Net</LinkBase>
10 </Compile>
11 <Compile Include="..\BD.WTTS.Client.Plugins.Accelerator.ReverseProxy\Services\Net\IDnsAnalysisService.cs">
12 <LinkBase>Services\Net</LinkBase>
13 </Compile>
14 <!--<ProjectReference Include="..\BD.WTTS.Client.Plugins.Accelerator.ReverseProxy\BD.WTTS.Client.Plugins.Accelerator.ReverseProxy.csproj" />
15 <ProjectReference Include="..\BD.WTTS.Client.Plugins.Accelerator\BD.WTTS.Client.Plugins.Accelerator.csproj" />-->
16</ItemGroup>Source: BD.WTTS.UnitTest.csproj
从测试取材可以读出三层设计意图：
- 被测对象是纯算法边界：
HttpReverseProxyMiddleware.FindScriptInjectInsertPosition被拆成独立分部类（partial class）文件，且单独被测试项目编译——说明"查找 HTML 中脚本注入位置"被刻意实现为不依赖 ASP.NET Core 管道上下文的纯函数式逻辑，才得以脱离宿主环境测试。 - 证书与 DNS 是重点风险面：
CertGenerator与DnsDohAnalysisService直接进测试，印证证书生成与 DoH 解析是加速链路中最容易因边界输入（过期时间、异常 DNS 响应等）出错、也最需要回归保障的环节。 - 项目级引用被注释掉：测试项目刻意不引用整个插件项目与 ReverseProxy 项目，避免拖入 UI/Avalonia 依赖，让测试保持轻量、可在 CI 快速运行。
失败模式、边界与运维要点
以下基于已核查的构建结构给出工程层面的分析与提示：
- 契约漂移风险：插件与测试项目均通过
Compile Include硬编码相对路径摘取 ReverseProxy 的源文件。若 ReverseProxy 侧重命名或移动文件，引用方构建会立即失败（文件找不到）。这是"共享源码"模式的固有代价——失败会显式暴露在编译期而非运行期，属于可接受的快速失败设计。 - 证书信任边界：加速 HTTPS 流量依赖
CertGenerator生成自签证书，且需用户将根证书导入系统信任区。证书生成或信任配置失败是最常见的加速不可用原因之一；插件仅摘取ICertificateManager契约，说明证书的生成/安装/清理被封装在 ReverseProxy 侧统一管理。 - DNS 解析路径：加速链路使用 DoH（
DnsDohAnalysisService）而非系统默认解析，可规避本地 DNS 污染，但引入了对 DoH 服务器可达性的依赖——DoH 端点不可达时解析会失败，属于加速开启后需关注的运维点。 - 非托管代码：插件开启
AllowUnsafeBlocks，涉及指针/内存操作的代码路径在崩溃时可能产生原生异常，调试时需注意混合模式调用栈。 - 静态集成即全量发布：插件未启用
EnableDynamicLoading，无法单独热更新加速器模块；插件变更需随宿主整体重新发布。
相关链接
- 源码：BD.WTTS.Client.Plugins.Accelerator.csproj
- 源码：BD.WTTS.Client.Avalonia.Designer.HostApp.csproj
- 源码：BD.WTTS.UnitTest.csproj
- 契约：ICertificateManager.cs
- 契约：IDnsAnalysisService.Constants.cs
- 实现：CertGenerator.cs
- 实现：DnsDohAnalysisService.cs
- 实现：HttpReverseProxyMiddleware.FindScriptInjectInsertPosition.cs
兄弟主题（反向代理实现细节、DNS 解析服务、证书管理、插件 UI）在各自独立页面中展开，本页不重复覆盖。