项目背景
机器人数量和群组数量增加后，简单脚本很快会遇到配置分散、重复处理、消息失序、权限不清和故障难追踪的问题。DefaultBot 的目标，是把 Telegram 机器人从“多个独立脚本”升级成统一的控制面与数据面。
控制面负责机器人、群组、成员、规则、账务和审计；数据面负责 Webhook、异步任务、Telegram 动作与失败重试。每个业务动作都需要明确来源、权限、幂等键和执行结果。
我的工作
建设多机器人接入、Token 加密保存、连接测试和 Webhook 管理。
建设群组自动发现、成员登记、身份基线和用户名/名称变动提醒。
实现新人按钮验证、超时处理、群组开关与权限控制。
建立广告关键词、正则、链接规则、自动处置和事件复核。
建立群组记账、RMB/USDT 流水、错账修正与汇率参考。
建设统一回复中心，支持全局、机器人、群组三级继承与版本记录。
将 Telegram 入站处理与出站动作分离，使用 Redis/BullMQ 和数据库 Outbox 处理重试与失败。
完成后台唯一入口、会话、RBAC、审计、指标、容器加固与离线生产包。
核心架构
Webhook 只做验签、标准化、去重和快速入队，慢业务由 Worker 异步执行；同一群组保持顺序，不同群组并行。业务数据和 Outbox 在数据库事务中同时落盘，Telegram Action Worker 再负责发送、删除、限制、批准和回调响应。
这种结构解决了三个关键问题：Telegram 重复投递不会重复记账或重复执行；某个群组积压不会遮住其他群组；外部 API 暂时失败时，动作仍能保留并重试。
安全与可靠性
Bot Token 使用 AES-256-GCM 加密，后台与日志只展示脱敏信息。
Webhook Secret、唯一入口、HttpOnly 会话、CSRF 与服务端 RBAC 共同保护管理面。
修复 Outbox 卡头、任务丢失、定时任务非原子、双入群事件、权限恢复和运行表无限增长等并发问题。
上传链路使用真实图片解码、尺寸限制、统一重编码和固定公共读取路径。
生产容器启用最小权限、明确组件版本和本机端口绑定。
交付结果
后端测试 27/27 通过。
前后端类型检查、ESLint、Stylelint、生产构建与 Prisma 校验通过。
前后端依赖审计无 critical/high/moderate/low 风险项。
86 个数据库迁移已执行到最新状态。
API、Web、PostgreSQL、Redis、Caddy 等六个服务完成运行与健康检查。
形成单文件预编译生产包：服务器只导入镜像并启动，不在线编译 TypeScript 或前端资源。
项目价值
DefaultBot 的核心成果，是把机器人业务从“能回复消息”提升到“可以长期运营”：数据可追踪、动作可重试、权限可审计、群组可扩展、生产环境可重复部署。