模块化移除需协同前端减法与后端精简：GUI模块须满足无状态、非核心、低耦合才可安全剥离；服务器端须避免HttpClient滥用、class-level字段存会话、无过期静态缓存；下线GUI后须联动清理对应API、DTO及测试。
模块化系统不是“删代码”的快捷键，而是有策略地收缩作用域、切断隐式依赖、释放运行时资源。移除 gui 模块和优化服务器端变量开销，本质是两个协同动作：前端界面层做减法，后端执行层做精简。
明确 GUI 模块的可剥离边界
不是所有带 UI 的组件都能直接删除，关键看它是否满足“无状态、非核心、低耦合”三条件。例如在 WPF 中使用 Prism 架构时，一个报表预览模块若只通过 IRegionManager 注册到 MainContentRegion，且不被其他模块直接 new 实例或强引用 ViewModel，就属于高安全移除目标。
操作建议：
- 检查模块是否实现 IModule 接口，并在 RegisterTypes 中仅注册视图与轻量服务（如本地缓存）
- 确认其 OnInitialized 方法未调用全局事件总线或修改共享状态容器
- 在测试套件编辑器中先“移出配置”，再观察主流程是否仍能启动、导航、提交——无报错即初步验证隔离性
精准识别并清理服务器端变量执行开销
变量开销常藏在“看似无害”的地方：重复初始化的单例对象、未 dispose 的数据库连接上下文、长生命周期的静态集合缓存。SQL Server 默认已自动优化多数配置，但应用层变量滥用仍会绕过这些机制。
典型高开销模式：
- 每次 HTTP 请求都 new 一个 HttpClient 实例（应复用静态实例或用 IHttpClientFactory）
- 在 Controller 中声明 class-level 字段存储用户会话数据（应改用 scoped service 或 HttpContext.Items）
- 用 static Dictionary
缓存未设过期策略的数据（易内存泄漏，改用 IMemoryCache 并配滑动过期）
联动验证：移除 GUI 后同步收紧后端契约
GUI 模块下线后，对应的服务接口、DTO 类型、验证规则往往还在后台默默运行。这会造成“前端已删，后端白跑”的隐性开销。
推荐步骤：
- 用 IDE 的“查找用法”功能，定位被移除 View/ViewModel 所依赖的 API Controller Action
- 检查该 Action 返回的 DTO 是否被其他模块复用；若无，则一并标记为 [Obsolete] 并计划下线
- 运行覆盖率工具（如 dotCover），确认相关 controller 层单元测试已失效或跳过，避免虚假绿灯
模块化移除不是终点，而是让系统呼吸更均匀的开始。真正节省下来的不只是 CPU 和内存，还有后续每一次调试、部署和扩缩容时的确定性。
