弃用与生命周期
被夜莺标记为弃用的功能、字段和界面项及各自的替代方案；项目未公布移除时间表，版本信息以 GitHub Release 为准。
这页列的是夜莺标记为弃用的东西，以及各自的替代方案。它不列移除时间， 因为项目方没有公布过任何时间表——读下面之前先看第一节。
没有公开的版本维护政策
项目方没有公布支持矩阵，没有 LTS 版本，没有说明每个小版本维护多久， 也没有宣布过这页上任何一项的移除计划。兼容性矩阵 在平台版本这件事上是同样的口径，理由也一样。
实际情况是：修复只会打在发布线的最新一版上，v9.1.1 是打在 v9.1.0 上的补丁版本， Bug 修复出现在那里。除此之外，权威记录在 GitHub：
| 你想知道的 | 去哪儿看 |
|---|---|
| 有哪些版本、各自什么时候发的 | GitHub Releases |
| 某个修复进没进 | 每个 release 里的 fix: 条目，见发布说明 |
| 某个字段引擎还读不读 | 源码。除此之外没有别的能作准 |
下面标记为弃用的东西，在 v9.1.1 里全都还在、全都还能用。 没有任何一项被移除。 把「弃用」读成「新增的东西应该做在替代方案上」，不要读成「下个版本就不能用了」—— 没有人说过时间，也不要从这页去推一个时间出来。
你能看到什么，取决于安装日期
界面隐藏弃用菜单的依据是这套系统是什么时候装的，不是它跑的哪个版本。 分界线是 2025-06-20，也就是 v8 beta 14 的发布时间：
- 在这个时间之后装的，永远看不到被弃用的那两个通知页面， 告警规则表单上也没有通知版本切换入口；
- 在这个时间之前装的，这些还都在，侧栏里旁边挂着一个弃用标记。
所以两套都跑 v9.1.1 的系统，菜单可以不一样，而且两边都没坏。 同事的界面上有你没有的入口，说明他那套装得比这个分界线早。
界面上被弃用的
| 什么 | 原来在哪 | 替代 |
|---|---|---|
通知设置（/help/notification-settings） | 告警通知 | 通知规则 加 通知媒介 |
通知模板（/help/notification-tpls） | 告警通知 | 消息模板 |
| 告警规则表单上的事件标签重写（Relabel） | 告警规则表单 | 工作流里的事件标签重写处理器 |
前两个就是上面那条安装日期规则会隐藏掉的入口。第三个不会隐藏—— 表单自己带了一句提示，说已有的 relabel 配置更适合改用工作流处理器来表达。
告警规则上被弃用的字段
下面这些在告警规则模型里带着 Deprecated 标记。它们全都还能传、API 也还会返回：
| 字段 | 替代 | 说明 |
|---|---|---|
datasource_ids、cluster | datasource_queries | datasource_ids 是读的时候反填给列表页用的；引擎只读 datasource_queries |
notify_channels、notify_groups、callbacks | notify_rule_ids | 三层通知模型。notify_version: 1 的规则不用这几个字段 |
enable_stime、enable_etime、enable_days_of_week | enable_stimes、enable_etimes、enable_days_of_weeks | 单数形式只能表达一个生效时段，复数形式能表达多个 |
prom_for_duration | 标注的是 use cron pattern instead | 它仍然是「持续时长」唯一的实现，每次判定都还在读。不要把它从规则 JSON 里删掉 |
任何读写告警规则 JSON 的东西——导出脚本、批量下发工具、同步任务——都该改用替代字段，
但无论如何要保留 prom_for_duration。
新通知版本下会被清空的订阅规则字段
保存一条 notify_version: 1 的订阅规则时，后端会把下面这些字段清空，
不报错，也没有提示：
- 授权团队（
user_group_ids）； - 重新定义的通知媒介（
redefine_channels、new_channels）； - 重新定义的回调地址（
redefine_webhooks、webhooks）； - 重新定义的告警级别（
redefine_severity、new_severity）。
这是设计如此，不是 Bug：在新模型里这些决定属于订阅所选的那几条通知规则，不属于订阅本身。
见订阅规则。如果你是用脚本创建订阅的，
把这些字段和 notify_version: 1 一起发过去，它们会被静默丢掉。
代码还在、但已经不在任何链路上的
两样你读源码或者抓包时可能会撞见的东西。它们都还会响应，但都不要基于它们做事。
POST /api/n9e/busi-group/alert-rules/notify-tryrun和.../enable-tryrun。 前端还各留着一个封装函数，而唯一那处调用被注释掉了。它们的活现在由 测试触发干了——一次走完查询 → 阈值 → 事件 → 通知， 而不是分成两个局部检查。alert/sender/下那套 v7 时期的发送器（钉钉、企业微信、飞书、Lark、Telegram、 Mattermost、邮件）。它们还编译在里面、也还挂着，但只有旧链路会走到： 一条notify_version: 0的规则产生的、带着notify_channels和notify_groups的事件。 通知规则走的是完全不同的另一条路，经过你在告警通知 → 通知媒介里配的媒介。 改旧链路上的模板，不会改变通知规则发出去的内容。