选择合适的推送方式

选择渠道时先判断“发给谁”和“是否需要收消息”，再比较消息格式和开发成本。固定群告警与企业级精准触达看似都能发文本，但权限模型、凭据生命周期和故障排查路径完全不同。

决策顺序

1. 接收对象：固定群、动态群、指定用户、部门、外部联系人，还是个人设备。
2. 消息方向：只发送通知，还是需要接收命令、按钮回调或自然语言对话。
3. 身份与权限：群成员能否自行添加，还是必须由应用管理员创建、审批和发布。
4. 可靠性要求：是否需要任务状态、失败名单、幂等发送和可追踪的消息 ID。
5. 合规与数据边界：消息是否允许经过第三方服务，是否必须自托管，是否跨地区或跨租户。
6. 长期运维：凭据能否轮换、Token 是否需要缓存、出口 IP 是否稳定、配额是否满足峰值。

场景选择矩阵

场景	首选方式	不适合时改选	主要代价
固定内部群告警	群机器人、Incoming Webhook	企业应用或完整 Bot	目标通常与 Webhook 绑定，接收范围不动态
指定用户或部门	企业应用推送	平台工作流	需要应用权限、可用范围和 Token 生命周期管理
多群或跨频道发送	应用 Bot	每群独立 Webhook	需要更完整的权限、安装和审核流程
业务命令与审批	双向对话 Bot	平台工作流	必须处理入站验签、幂等、权限和超时
AI 助手	双向对话 Bot + 独立 AI 层	普通命令 Bot	额外承担上下文、内容安全、工具鉴权和费用控制
个人或移动通知	ntfy、Pushover、PushDeer	企业协作平台	依赖第三方服务或自建服务可用性
数据必须自主管理	Gotify、自建 ntfy	公共推送服务	需要维护域名、TLS、升级、备份和客户端连接

机器人还是应用推送

群机器人适合“一个凭据对应一个固定群”的简单链路。配置通常由群内完成，上线快，但不能随意指定其他群或用户，也通常不能接收消息。

应用推送适合组织级场景。它能按成员、部门、标签或会话标识精确发送，但需要应用管理员、权限申请、可用范围、版本发布和访问令牌缓存。不要因为调用代码多几行就回退到为每个群创建一个 Webhook，这会把权限和轮换成本扩散到大量凭据。

双向对话选择

需要收消息时，先在长连接与 HTTP 回调之间选择：

• 长连接适合内网开发和快速接入，不需要公网回调地址，但需要官方 SDK、连接保活和重连监控。
• HTTP 回调适合已有 API 网关、WAF、队列和统一验签体系的服务，公网入口和证书必须稳定。
• Telegram getUpdates 适合单实例调试；生产多实例通常使用 Webhook，二者不能同时启用。

普通 API 对话应先完成 /ping、/status 等确定性命令，再接 AI。LLM 只负责生成内容，不能代替平台验签、用户权限、事件去重和工具调用鉴权。

可靠性与成本判断

不要只比较平台公布的单接口 QPS，还要确认目标级限流、每日额度、消息大小、附件上传、异步任务查询和失败名单。告警系统应支持聚合和退避；运营群发应支持审批、审计和撤回边界。

付费渠道还要确认套餐、地区和接收端成本。自建服务没有按条费用，但需要计算基础设施、升级、备份、推送连接和故障响应成本。

上线前检查

• 接收目标和消息方向已确定，教程的能力边界与实际场景一致。
• 使用最小权限和最小可用范围的测试应用完成验证。
• 凭据只在服务端保存，轮换和撤销责任人明确。
• 发送端检查 HTTP 状态和平台业务码，限流与临时故障有上限退避。
• 双向渠道已完成验签、事件去重、快速确认、会话隔离和 Bot 自消息过滤。
• 内容包含隐私或跨地区数据时，已经完成组织内的合规确认。

需要横向浏览所有已收录方式时，使用渠道能力对比；确定平台后，再进入对应方式教程核对控制台步骤和限制。