提供的能力
@nocobase/app-plugin-notification-providers 为通知提供 SMTP、Resend、飞书机器人和钉钉机器人渠道。它只有 Server 运行时入口，不提供配置页面或用户邮箱工作台。
选择渠道类型
type | 使用场景 | 消息要求 |
|---|---|---|
smtp | 通过 SMTP 服务器发送邮件 | 原生邮箱地址、subject、text 或 html |
resend | 通过 Resend 发送邮件 | 原生邮箱地址、subject、text 或 html |
feishu-webhook | 向飞书机器人 Webhook 发消息 | text，可选完整 HTTP(S) target URL |
dingtalk-webhook | 向钉钉机器人 Webhook 发消息 | text，可选完整 HTTP(S) target URL |
一个类型可以配置多个命名渠道，分别使用不同凭据。新增配置使用 type；旧 provider 别名仍兼容，但两者同时出现时必须一致。
使用场景与示例
示例：业务通知与运维告警分开
将 system-email 配置为邮件渠道，将 ops-feishu 配置为飞书渠道。业务调用 notification.send() 时，分别在 messages['system-email'] 和 messages['ops-feishu'] 提供完整消息。
邮件可传单个邮箱或邮箱数组；机器人 Webhook 不接受 to，目标由配置的 Webhook 决定。插件不负责把用户 ID 换成邮箱。飞书、钉钉渠道校验官方 HTTPS Webhook 主机，且不跟随重定向。
开发提示词（交给当前应用目录中的 Coding Agent）：
请使用通知渠道插件，将业务邮件与运维飞书告警分开。
配置 system-email 与 ops-feishu 两个具名渠道，凭据来自服务端私有配置，显式处理环境变量映射。
邮件提供邮箱收件人，机器人使用配置中的 Webhook，不传 to。
使用受控收件人与测试群验证实际投递及失败结果，不额外开发个人邮箱页面。完成标志：测试邮件与告警分别到达指定目标，错误凭据的失败可在日志中定位。
重要原理与实现
以下是实现本例时的接入位置与预期界面变化；它们是开发说明，具体文件名沿用当前应用结构。
| 接入位置 | 代码或配置变化 | 界面与行为变化 |
|---|---|---|
| server/plugins.ts 与通知配置 | 注册 Server 渠道插件和具名实例 | 不新增页面，服务端可以选择投递实现 |
| 配置工厂和私密环境配置 | 显式映射 SMTP 或 Webhook 凭据 | 配置名称与实际读取路径一致 |
| 业务通知构造 | 按渠道准备邮件或机器人消息 | 两类消息投递到各自目标 |
配置渠道
将 Server 插件放在通知插件之后注册，并在 notification.channels 下添加命名渠道：
notification:
channels:
system-email:
type: smtp
host: smtp.example.com
port: 587
from: notifications@example.com此示例只展示配置结构；实际 SMTP 认证需通过服务端私有配置提供。YAML 值是字面量，不会自动展开 ${...}。默认模板的 defineMailChannelsConfig 将 SMTP_PASSWORD 映射到 channels.system-email.auth.pass；自定义渠道名称或凭据路径需要显式环境变量映射。
AI 开发的约束与验证
本插件的开发约束
- 区分渠道名与 type，YAML 不自动展开环境变量，不能把占位表达式当作有效凭据。
- 保留官方 Webhook 主机与重定向校验；不要为跑通测试关闭提供方校验。
- 实际检查认证失败、收件人格式和投递日志；使用测试目标避免将验收消息发给业务用户。
验证与扩展
通过真实业务或服务端发送验证渠道，并检查通知日志。同时确认配置可读、认证可用和收件人格式正确；不要仅凭配置保存成功判断发送成功。
需要新渠道时，通过 ChannelInstance 与 registry.registerChannelType() 扩展；通用扩展实现属于插件开发。本插件不包含站内信和 Web Push，它们分别由站内信和浏览器推送提供。需要连接用户自己的邮箱，参阅邮件。
上述检查是接入后的验收要求，不表示本文已完成运行验证。让 Agent 报告实际改动、执行过的检查和未验证项；项目指引、Skills 与通用检查流程见持续开发应用和测试。
源码依据：插件公开入口与实现。