通知渠道配置
按选择渠道、填写参数、测试发送和上线治理的顺序建立稳定的通知出口。
功能概述
通知渠道配置决定平台里的通知到底从哪里发出去。
如果通知规则已经定义好,但渠道没有配置或配置不稳定,最终用户仍然收不到任何提醒。
适用场景
适合下面几类需求:
- 第一次接入邮件、Webhook 或企业 IM 通知
- 把平台事件发给运维、审批人或业务群组
- 排查通知为什么没有成功送达
前置条件
开始前建议准备:
- 渠道所需的账号、SMTP 信息、Webhook URL 或 Bot Token
- 一个测试接收对象,例如测试邮箱或测试群
- 一条可重复触发的测试事件
操作步骤
第 1 步:进入站点设置,确认通知入口
先进入后台的 站点设置 页面,确认平台通知和邮件配置入口是否已经可见。
这里通常会集中放置平台级通知能力。

这一步的重点是先确定通知属于全局配置,而不是每个团队单独随意维护。
第 2 步:先选择一个主渠道
第一次配置时,不建议同时接多个渠道。
推荐先从最容易验证的一种开始,例如:
- 邮件
- Webhook
先跑通一条主链路,再考虑补充 Slack、飞书、钉钉或企业微信。
第 3 步:填写渠道参数并保存
不同渠道通常需要填写:
- SMTP 主机、端口和发件人
- Webhook URL
- Bot Token、签名或额外请求头
填写时建议同步记录:
- 这个渠道给谁用
- 用于哪些事件
- 后续由谁维护

第 4 步:执行测试发送
保存后不要直接上线。
先使用测试对象验证:
- 是否能成功送达
- 内容格式是否可读
- 鉴权、签名和网络策略是否正常
如果平台里有通知中心,也可以同步查看测试通知是否成功进入通知链路。

第 5 步:把渠道绑定到真实事件前,先定义使用规则
测试通过后,再明确:
- 哪些事件走这个渠道
- 哪些事件只在站内通知
- 哪些事件需要备用渠道
这样可以避免一上线就通知泛滥,或者关键告警没有兜底。
结果验证
通知渠道配置完成后,至少应满足:
- 测试消息可以成功送达
- 失败时可以看到明确错误信息
- 通知中心或发送状态中能看到链路结果
常见问题
为什么保存成功了,但实际没有收到通知
优先检查:
- 接收地址或群配置是否正确
- Webhook、SMTP 或签名参数是否完整
- 是否真的触发了对应事件
为什么第一次建议只接一个主渠道
因为一次接太多渠道后,问题会同时混入网络、签名、接收方限制和通知规则,很难快速定位。
为什么测试发送不能省略
通知是跨系统链路。
只要不做测试发送,你就无法确认平台之外的那一段链路到底是不是通的。
注意事项
- 所有渠道都要先做测试发送,再接真实事件
- Webhook 和企业 IM 渠道尤其要关注签名、超时和重试
- 建议明确主渠道和备用渠道,避免关键通知只有单点出口