Repository Wiki
BeyondDimension/SteamTools

项目概览

Watt Toolkit(原名 Steam++)是一个开源、跨平台的多功能游戏工具箱,本页从仓库顶层视角介绍其产品定位、功能矩阵、技术栈与源码组织方式,为深入各子系统文档提供导航入口。

目的与范围

本页覆盖整个 BeyondDimension/SteamTools 仓库的宏观视图:

  • 产品定位与目标用户(需要 Steam 的玩家群体)
  • 默认插件提供的六大功能模块及其平台支持情况
  • 支持的操作系统与分发渠道
  • 仓库顶层结构、解决方案组织、构建与全局配置资产
  • src/ 内嵌的 Avalonia 补丁工程与源码分层/命名约定

以下内容有意留给兄弟页面,本页不做深入:

  • 网络加速(YARP 反代与脚本注入)的内部实现 —— 见对应功能页
  • 账号切换、库存游戏、本地令牌等业务模块的实现细节 —— 见各功能页
  • 构建发布工具链(ST.Tools.Publish 等)的逐个剖析 —— 见工具链页

注:src/README.md 中的项目结构说明目前大部分处于 TODO 注释状态,本页对该文件的引用均标注其当前状态,并结合实际探测到的仓库文件交叉验证。

概述

产品定位

「Watt Toolkit」是一个开源跨平台的多功能游戏工具箱,此工具的大部分功能都是需要用户下载安装 Steam 才能使用。3.0 版本起支持自定义插件功能,仓库自带的六大功能均为默认插件,用户可自行删除或禁用:

#功能模块说明平台支持
1网络加速使用 YARP.ReverseProxy 进行本地反代以更快访问游戏网站;通过加速服务拦截网络请求将 JS 脚本注入网页,提供类似网页插件的功能Windows / Linux / macOS / Android
2账号切换快速切换已在当前 PC 上登录过的 Steam、Epic、Uplay 等多平台账号,管理 Steam 家庭共享库排序及禁用Windows / Linux / macOS
3库存游戏直接管理 Steam 游戏库存(编辑名称、自定义封面);监控下载进度实现定时关机;模拟运行游戏挂时长与掉卡;管理云存档;解锁/反解锁成就Windows / Linux / macOS
4本地令牌手机令牌统一保存在电脑中,支持通用 HOTP、TOTP、Steam、Google 令牌导入;支持 Steam 账号绑定生成令牌与批量确认交易Windows / Linux / macOS / Android
5自动挂卡集成 ArchiSteamFarm 挂机掉落 Steam 集换式卡牌(新版开发中,暂不可用)Windows / Linux / macOS / Android
6游戏工具强制游戏窗口使用无边框窗口化,更多功能待开发Windows

以上功能清单与平台标注直接摘自仓库根 README.md。

支持的操作系统

依据 README.md:

  • Windows 11、Windows 10 版本 1809(OS 内部版本 17763)或更高版本
  • macOS 10.15 或更高版本
  • Ubuntu 20.04+、Debian 11+、Fedora 37+、Deepin(UOS) 20+
  • Android 5.0(API 21)或更高版本
  • iOS 11+(开发中…)

技术栈与开发环境

README 徽章标明项目基于 .NET 7.0 / C# 11(见 README.md)。桌面 UI 基于 Avalonia(仓库内直接维护 Avalonia 补丁工程,见下文架构节),移动端涉及 Xamarin.Android / .NET 6+ Android / MAUI。推荐开发环境(README.md):

  • Visual Studio 2026 / JetBrains Rider / Visual Studio Code
  • OpenJDK 17(Android 构建)
  • Android Studio Electric Eel 或更高版本
  • Xcode 26 或更高版本(iOS/macOS)

分发渠道

README.md 列出的官方下载渠道:

  • Steam 商店(app/2425030)、Microsoft 应用商店(Watt Toolkit / 9MTCFHS560NG)
  • 软件官网 steampp.net
  • GitHub Releases 与码云(Gitee)发行版
  • Arch 用户仓库 watt-toolkit-bin(Release 构建)与 watt-toolkit-git(最新源码构建,可能构建失败)

下载细节另见仓库内 doc/download-guide.md。

架构

仓库顶层结构

下图为仓库(develop 分支)顶层资产的组成关系。其中业务工程分组依据 src/README.md 中规划的结构说明(当前为 TODO 注释状态),Avalonia 补丁工程与全局构建文件为实际探测到的文件:

Loading diagram...

各组成部分说明:

  • WattToolkit.slnx:XML 格式的解决方案清单,统一管理 src 下全部工程。
  • src/Directory.Build.props 与 src/Directory.Packages.props:目录级 MSBuild 属性与中央包版本管理(CPVM),让所有子工程共享统一的构建属性与依赖版本,这是仓库避免各工程版本漂移的关键手段。
  • src/ImplicitUsings.*.cs:按框架域拆分的隐式全局 using(如 ImplicitUsings.Avalonia.cs、ImplicitUsings.AspNetCore.cs、ImplicitUsings.EntityFrameworkCore.cs、ImplicitUsings.Common.Mvvm.cs 等),使各工程无需重复书写常用命名空间。
  • src/AssemblyInfo.*.cs / AboutAppInfoPopup.cs:程序集信息、版本常量与"关于"弹窗等共享源文件。
  • Avalonia 补丁工程:仓库在 src/ 内直接维护 Avalonia.Base、Avalonia.Base.Internals、Avalonia.Controls.Internals、Avalonia.Desktop、Avalonia.Diagnostics 等工程,即对 Avalonia UI 框架源码做内嵌定制。这解释了为什么桌面客户端能获得深度的窗口/绘图行为控制(例如 DrawingContextExtensions.cs、WindowExtensions.cs 这类扩展)。仓库根目录同时存在 avalonia.snk 与 WattToolkit.snk 强名称密钥文件,用于对定制程序集签名。
  • 业务工程(依据 src/README.md 规划,详见下节):Common(通用基础类库)、Lib(业务类库与平台实现)、Tool(构建辅助工具)、Launch(各平台启动项)。

源码分层规划(src/README.md)

src/README.md 描述的规划结构(当前内容整体处于 TODO 注释中,仅作架构意图参考):

  • Common 通用基础类库:Common.AreaLib(地区数据)、Common.ClientLib(客户端通用)、Common.ClientLib.Droid / Common.ClientLib.iOS(移动平台)、Common.CoreLib(全局通用)、Common.ServerLib(AspNetCore 服务端)、Common.PinyinLib(汉字转拼音,多实现:iOS 用 CFStringTransform、其他平台用 TinyPinyin.Net)、Repositories.EFCore / Repositories.sqlite-net-pcl(仓储层双实现)、Services.SmsSender(统一短信发送)。
  • Lib 业务类库:ST(业务通用)、ST.Client(客户端通用)、Bindings(平台原生绑定)、Platforms/ST.Client.Windows|Mac|Linux|Android|iOS(按平台拆分的实现)、ResSecrets(以资源形式存储的密钥)、UI 框架层 ST.Client.Avalonia(含通过友元程序集裁剪的 Avalonia.Ref)与 ST.Client.XamarinForms,以及 Web API 层 ST.Services.CloudService(.Models/.ViewModels)(客户端调用服务端 API 的定义与 DTO)。
  • Tool 工具:ST.Tools.Publish(发布控制台工具)、ST.Tools.Translate(Resx 自动翻译,需 Azure Translation Key)、ST.Tools.OpenSourceLibraryList(开源许可清单生成,需 GitHub API Token)、ST.Tools.AndroidResourceLink、ST.Tools.AreaImport、ST.Tools.Packager 等。
  • Launch 启动项:FDELauncher(.NET FX 3.5 框架依赖启动器)、ST.Client.Desktop.Avalonia.App(桌面客户端)、ST.Client.Android.App(.Modern)(Android 客户端)、ST.Client.Maui.App(MAUI 客户端)、DesktopBridge 与单项目 MSIX 打包工程。

命名空间/文件夹约定

src/README.md 还约定了统一的目录语义(同样处于 TODO 注释中):Properties(程序集信息与本地化资源 SR)、Application(业务应用,内含 Columns/Converters/Data/Entities/Models/Mvvm/Repositories/UI 等子目录)、Logging(日志自定义实现)、Services(业务服务接口与 Implementation 实现)等。其中 DI 注册统一收敛到 ServiceCollectionExtensions.cs,并显式落入微软命名空间:

csharp
// ReSharper disable once CheckNamespace namespace Microsoft.Extensions.DependencyInjection

Source: src/README.md

这一约定的设计意图是让各工程的 DI 扩展方法在调用侧无需额外 using 即可被发现(Microsoft.Extensions.DependencyInjection 本就是 IServiceCollection 所在命名空间),从而降低多工程下的注册样板代码。

功能模块视图

从用户视角看,各功能模块与平台实现的关系如下(平台支持摘自 README):

Loading diagram...

网络加速是唯一同时覆盖桌面三平台与 Android 的"基础设施型"功能,其本地反代能力也支撑了脚本注入;而账号切换、库存游戏受限于需要读取本机 Steam 客户端数据,仅覆盖桌面平台;游戏工具(无边框窗口化)依赖 Windows 窗口 API,故仅限 Windows。

仓库顶层资产一览

以下文件由仓库根目录实际探测得到(develop 分支),构成全局构建与项目元数据:

资产类型作用
WattToolkit.slnx解决方案XML 格式的 .NET 解决方案清单,聚合 src 下全部工程
global.jsonSDK 配置固定本仓库使用的 .NET SDK 版本,保证团队构建一致性
NuGet.Config包源配置定义 NuGet 包源与凭据策略
src/Directory.Build.propsMSBuild目录级公共构建属性,被 src 下所有子工程继承
src/Directory.Packages.propsMSBuild中央包版本管理(CPVM),统一依赖版本
crowdin.yml本地化配置对接 Crowdin 翻译平台(项目徽章显示本地化进度)
WattToolkit.snk / avalonia.snk强名称密钥对 WattToolkit 与定制 Avalonia 程序集进行强名称签名
LICENSE许可证仓库开源许可证
README.md / README.en.md文档中/英文项目说明
doc/文档download-guide.md 下载指南、open-source-library.md 开源代码库清单

以上 global.json、NuGet.Config 等文件的具体键值未包含在本次读取范围内,此处仅说明其标准职责;如需精确配置值请直接查看对应文件。

隐式全局 using 体系

src/ 根下的 ImplicitUsings.*.cs 系列文件按框架域拆分了全局 using,使不同工程按需引用,避免在每个源文件中重复书写命名空间。实际存在的分组包括(节选):

  • ImplicitUsings.BCL.cs、ImplicitUsings.Common.cs、ImplicitUsings.Common.Mvvm.cs、ImplicitUsings.Enums.cs、ImplicitUsings.Data.cs
  • ImplicitUsings.Avalonia.cs(Avalonia UI)
  • ImplicitUsings.AspNetCore.cs、ImplicitUsings.Controllers.cs、ImplicitUsings.Identity.cs(Web/服务端)
  • ImplicitUsings.EntityFrameworkCore.cs(ORM)
  • ImplicitUsings.ArchiSteamFarm.cs(对接 ArchiSteamFarm 挂卡功能)
  • ImplicitUsings.Jobs.cs(后台作业)
  • ImplicitUsings.AutoMapper.cs(对象映射)

这一拆分方式与"通用基础类库 / 客户端类库 / 服务端类库"的工程分层一一对应:桌面工程引用 Avalonia 分组,服务端工程引用 AspNetCore 分组,挂卡模块单独引用 ArchiSteamFarm 分组,互不污染。

Avalonia 内嵌补丁工程

仓库未以普通 NuGet 依赖方式消费 Avalonia,而是在 src/ 内维护多个 Avalonia 框架工程,包括:

工程补丁定位
Avalonia.Base基础类型与元数据(如 Metadata/XmlnsDefinitionAttribute.cs)
Avalonia.Base.Internals绘图上下文扩展(DrawingContextExtensions.cs),访问内部 API
Avalonia.Controls.Internals控件/窗口扩展(Extensions/WindowExtensions.cs、IPlatformLifetimeEventsImplExtensions.cs)
Avalonia.Desktop桌面平台 AppBuilder 扩展(AppBuilderDesktopExtensions.cs)
Avalonia.Diagnostics诊断相关定制

src/README.md 规划中的 ST.Client.Avalonia/Avalonia.Ref("通过友元程序集调用内部函数或空程序集实现手动裁剪")解释了这种做法的动机:需要触达 Avalonia 的 internal 成员并做体积裁剪,同时配合 InternalsVisibleTo.cs(Properties 目录约定中"指定 internal 对单元测试可见")保持可测试性。这对"网络加速"的窗口 Hook、"游戏工具"的无边框窗口化等深度平台能力是必要的。

构建与协作流程

从仓库资产可以还原出完整的工程化协作链路:

Loading diagram...

其中 ST.Tools.Translate 与 Crowdin 共同支撑多语言(README 顶部提供中英双语,且 Crowdin 徽章显示本地化进度);ST.Tools.OpenSourceLibraryList 生成的开源清单发布在 doc/open-source-library.md。Android 构建链需要 OpenJDK 17 与 Android Studio,iOS/macOS 构建需要 Xcode(见 README 开发环境一节)。

使用示例

跨平台启动入口规划

src/README.md 规划的 Launch 层展示了"一套业务类库,多个平台壳工程"的组织方式(以下为该文件中的结构摘录):

text
1- Launch 启动项 2 - FDELauncher FDE(框架依赖) 启动器,判断运行时是否安装与提示,使用 .NET FX 3.5 3 - ST.Client.Android.App Android 客户端(Xamarin.Android) 4 - ST.Client.Android.App.Modern Android 客户端(.NET 6+) 5 - ST.Client.Desktop.Avalonia.App 桌面客户端 6 - ST.Client.Avalonia.App.MsixPackage 桌面客户端单项目 MSIX 打包 7 - ST.Client.Maui.App MAUI 客户端

Source: src/README.md

设计意图:FDELauncher 用 .NET FX 3.5 实现且通过 App.config 的 supportedRuntime 兼容 4.x,用于在缺少 .NET 运行时(FDE = Framework-Dependent)的机器上给出安装提示;桌面主壳为 ST.Client.Desktop.Avalonia.App,Windows 商店分发走 DesktopBridge 与单项目 MSIX 打包。

DI 注册命名空间约定

src/README.md 中给出的 DI 扩展类命名空间统一写法:

csharp
// ReSharper disable once CheckNamespace namespace Microsoft.Extensions.DependencyInjection

Source: src/README.md

该约定的收益:ServiceCollectionExtensions.cs 中定义的扩展方法落入 Microsoft.Extensions.DependencyInjection 命名空间后,任何已 using 该命名空间(几乎总是如此)的调用方都能直接发现这些注册方法,多工程协作时无需记忆各业务库的自定义命名空间。

说明:受本次源码读取预算限制,本页未展开读取业务工程(如 ST.Client.Avalonia 视图层、ST.Services.CloudService 等)的内部源文件,其实现细节由对应的功能页与子系统工程页承载;本页所有结构结论均来自仓库根 README 与 src/README.md 的原文及顶层文件的实际探测结果。

配置项参考

本页为仓库级概览,不涉及单个组件的运行时配置键。与全局构建相关的仓库级配置资产如下(键值详见文件本身):

资产层级职责
global.json仓库根固定 .NET SDK 版本,锁定团队与 CI 构建环境
NuGet.Config仓库根NuGet 包源与凭据配置
src/Directory.Build.propssrc 目录公共 MSBuild 属性(目标框架、版本号、强命名等),子工程自动继承
src/Directory.Packages.propssrc 目录中央包版本管理,所有 PackageReference 的版本统一在此维护
crowdin.yml仓库根Crowdin 本地化平台的项目映射配置

边界情况与注意事项

  • src/README.md 处于未完成状态:其标题为 "Steam++ v3.X Source Code",正文 项目结构 一节仅有一行 TODO,完整结构说明目前整段包裹在 HTML 注释中。因此本页对"Common/Lib/Tool/Launch"四层结构的描述属于仓库规划的架构意图,实际工程名与目录可能存在出入;阅读时应以 WattToolkit.slnx 与实际目录为准。
  • 移动端覆盖不完整:iOS 客户端标注为"开发中…",ST.Client.iOS 属于规划中的平台实现;Android 存在 Xamarin.Android 与 .NET 6+ 两代启动项并存的情况。
  • 自动挂卡功能当前不可用:README 中该项使用删除线标注,说明集成 ArchiSteamFarm 的新版本仍在开发中,但 ImplicitUsings.ArchiSteamFarm.cs 表明相关源码分组的准备工作已就位。
  • AUR watt-toolkit-git 可能构建失败:该包每日拉取最新源码构建,README 明确提示"也许会构建失败",需要稳定版本时应使用 watt-toolkit-bin。
  • 功能强依赖 Steam:README 明确"此工具的大部分功能都是需要您下载安装 Steam 才能使用",账号切换、库存游戏等模块在本机无 Steam 时不可用。
  • 平台能力差异:网络加速覆盖桌面三平台 + Android;账号切换与库存游戏仅桌面;游戏工具(无边框窗口化)仅 Windows。功能可用性以各功能页的平台支持矩阵为准。

性能与运维要点

  • 中央包版本管理(CPVM):src/Directory.Packages.props 集中管理依赖版本,避免多工程间依赖漂移;升级第三方库(尤其是内嵌的 Avalonia 定制工程)只需改动一处。
  • Avalonia 源码内嵌的维护成本:直接维护 Avalonia.Base、Avalonia.Desktop 等框架工程意味着上游升级需手工合并补丁,avalonia.snk 与 WattToolkit.snk 双密钥体系用于区分框架定制程序集与应用程序集的签名。
  • 发布渠道多样化带来的矩阵负担:Steam 商店、MS Store(MSIX)、GitHub/Gitee Release、AUR 等渠道并存,ST.Tools.Publish 与 GitHub Actions(develop 分支 CI,见 README 构建徽章)负责统一产出;MS Store 版本走 DesktopBridge/单项目 MSIX 打包工程。
  • 本地化流水线:Crowdin(crowdin.yml)+ ST.Tools.Translate(Resx 自动翻译,需 Azure Translation Key)+ Properties/SR 本地化资源目录约定,共同构成多语言交付链路。
  • 开源合规:ST.Tools.OpenSourceLibraryList(需 GitHub API Token)自动生成开源许可清单 doc/open-source-library.md,这是分发到 MS Store/Steam 等商店的合规前提。

扩展点

  • 插件体系(3.0+):README 明确"全新的 3.0 版本,支持自定义插件功能,以下功能为下载时自带的默认插件,可以自行删除或禁用"。即网络加速、账号切换等六大功能本身以插件形态交付,第三方可开发自定义插件扩展工具箱能力。插件机制的内部实现细节由对应的功能/插件系统页面承载。
  • 拼音库多实现切换:规划中 Common.PinyinLib 按平台选择实现(iOS 走 CFStringTransform、Android 走 TinyPinyin、其余平台走 TinyPinyin.Net),是典型的平台服务抽象扩展点。
  • 仓储层双实现:Repositories.EFCore 与 Repositories.sqlite-net-pcl 并存,说明数据访问被抽象为可替换实现(EF Core 面向桌面/服务端,sqlite-net-pcl 面向移动端),业务层通过仓储接口解耦具体 ORM。
  • UI 框架可替换层:规划中同时存在 ST.Client.Avalonia 与 ST.Client.XamarinForms 两套 View 层,View 与 ViewModel(ST.Services.CloudService.ViewModels)分离,UI 框架理论可替换。

相关链接

Sources

(2 files)