DbusSmsForward/debian-refactor-design.md

DbusSmsForward Debian 深度重构设计

现状判断

当前公开仓库并不是 OpenWRT 专用实现，实际上已经围绕 Debian + ModemManager + DBus 工作。但它离“可在 Debian 上长期稳定使用”的目标还有明显差距，主要是工程结构过于原始。

当前架构主要问题

1. 纯交互式入口

   • Program.cs 通过 Console.ReadLine() 完成模式选择、渠道选择、首次配置。
   • 这导致它无法无交互运行，不适合 systemd、daemon、自启动、容器化或远程运维。

2. 配置模型不适合服务部署

   • ConfigHelper 只读写 AppContext.BaseDirectory/appsettings.json。
   • 这意味着配置和程序强绑定，无法自然放到 /etc/dbussmsforward/、~/.config/ 或通过环境变量注入。
   • 也没有配置校验、默认值归一化、密钥与普通配置分层。

3. 发送渠道实现高度耦合

   • ProcessChoise 既处理交互，又决定启用哪些发送器，又触发各发送器自己的“首次输入配置流程”。
   • 每个 SendBy* 类都直接读配置、拼接 HTTP、同步阻塞调用、直接向控制台打印结果。
   • 不利于扩展新渠道，也无法做统一重试、超时、日志与错误处理。

4. HTTP/证书处理有风险

   • HttpHelper 全局使用 DangerousAcceptAnyServerCertificateValidator。
   • 这在 Debian 长期运行场景下非常危险，等于默认跳过 TLS 校验。

5. 同步阻塞 + 弱错误处理

   • 大量 .Result 阻塞异步调用。
   • 错误处理基本是 catch(Exception ex) Console.WriteLine(...)，缺乏分级日志和可观测性。

6. 项目目标平台过窄

   • DbusSmsForward.csproj 固定 RuntimeIdentifiers=linux-musl-arm64
   • 启用 PublishAot=true
   • TargetFramework=net10.0
   • 这对 Debian x64/arm64 通用部署非常不友好，也加大本地构建门槛。

7. 缺少 daemon/service 概念

   • 没有 DaemonConfig 这种运行期控制配置。
   • 没有 systemd unit、工作目录规范、日志规范、停止信号处理、启动健康检查。

8. 历史记忆中的配置未在公开仓库中体现

   • 本地历史记忆提到 AutmanPushConfig 与 DaemonConfig。
   • 当前公开仓库未包含这两项，说明需要在本次 Debian 重构中主动引入统一的新配置结构。

Debian 化重构目标

核心目标

将项目改造成：

• 非交互式配置驱动
• 可作为 systemd 服务运行
• 支持 Debian x64 / arm64
• 保留现有发送能力
• 增加统一配置模型与运行控制能力
• 为未来新增 Autman Push / Webhook / 更多通知渠道预留扩展点

建议的新架构

1. 宿主层改为 Generic Host

用 .NET Generic Host 替代当前顶层裸 Program.cs：

• Host.CreateApplicationBuilder(args)
• IHostedService / BackgroundService
• ILogger<T>
• IOptions<T> / 配置绑定
• ConsoleLifetime / Systemd 集成

建议拆成以下角色：

• SmsForwardWorker：监听 ModemManager 短信事件并派发
• SmsSendService：主动发送短信
• ModemManagerClient：封装 DBus/ModemManager 访问
• NotificationDispatcher：统一调度多个通知器
• INotificationSender：每种发送渠道一个实现

2. 配置体系重构

建议引入新的配置根模型，例如：

• DaemonConfig
• ModemConfig
• ForwardingConfig
• NotificationTargets
• AutmanPushConfig
• WebhookConfig
• TelegramConfig
• EmailConfig
• ShellConfig

并支持以下优先级：

1. /etc/dbussmsforward/appsettings.json
2. ./appsettings.json
3. 环境变量（如 DBUSSMSFORWARD__...）
4. 命令行参数

3. 命令模式替代交互模式

建议把交互式入口改成命令式：

• dbussmsforward run
• dbussmsforward send --to 138... --text "..."
• dbussmsforward validate-config
• dbussmsforward print-sample-config

保留旧参数 -fE/-fP/.../-sS 作为兼容层，但内部只转换成新命令，不再触发交互式流程。

4. 发送渠道抽象

定义统一接口：

• INotificationSender
  • string Name
  • Task SendAsync(SmsMessage sms, CancellationToken ct)

每个渠道单独实现：

• EmailNotificationSender
• PushPlusNotificationSender
• TelegramNotificationSender
• DingTalkNotificationSender
• BarkNotificationSender
• WeComNotificationSender
• ShellNotificationSender
• AutmanPushNotificationSender（新增）

由 NotificationDispatcher 统一完成：

• 启用判断
• 超时控制
• 错误隔离
• 日志记录
• 可选并发发送

5. 安全与可靠性修复

• 默认启用 TLS 证书校验
• 仅在配置显式允许时跳过证书校验
• 用 HttpClientFactory 替换手写同步 HttpClient
• 所有外部调用改为 async/await
• 增加超时、重试（至少对 HTTP 类通知）
• 用结构化日志替代 Console.WriteLine

6. 构建与发布策略调整

建议不要默认强绑 NativeAOT。 更适合 Debian 的策略：

• 默认：net8.0 或 net9.0 framework-dependent / self-contained
• 可选：额外保留 AOT 发布 profile
• RIDs 至少支持：
  • linux-x64
  • linux-arm64

这样更利于 Debian VPS/小主机/工控盒子直接部署。

建议分阶段实施

Phase A：最小可用 Debian 服务化

• 改造配置加载
• 去掉首次运行交互依赖
• 引入 run/send/validate-config 命令
• 统一日志
• 补 systemd unit 示例

Phase B：通知通道抽象化

• 拆 SendBy* 为 sender 实现
• 引入 dispatcher
• 补 AutmanPushConfig
• 允许多渠道并行转发

Phase C：兼容与增强

• 保留旧 CLI 参数兼容
• 支持环境变量覆盖
• 支持跳过证书校验的显式开关
• 输出 Debian 部署文档

本次实际重构建议

如果现在开始直接动代码，我建议这样做：

1. 新建 Configuration/、Services/、Notifications/、Models/ 目录
2. 引入新的配置类，其中补上：
   • DaemonConfig
   • AutmanPushConfig
3. 重写 Program.cs 为 host + command 模式
4. 保留现有 ModemManagerHelper，但包一层服务接口
5. 逐步把 SendBy* 改为异步 sender
6. 补 appsettings.example.json
7. 补 dbussmsforward.service
8. 最后整理 README 的 Debian 使用方式

结论

这次重构的重点不是“把 OpenWRT 代码移植到 Debian”，而是： 把一个能在 Debian 上跑的个人脚本式 .NET 工具，重构成一个适合 Debian 长期托管运行的服务程序。

下一步应进入 t3：实施重构、补齐配置/服务化/兼容逻辑。