通知渠道在 HarmonyOS 里不是一个分类标签，它是系统决定“这条通知用什么方式打扰用户”的总开关。SlotType 填错，最迷惑的表现不是报错，是通知发出去之后横幅没有、声音没有、锁屏不显示，用户只能自己去通知中心翻。

SOCIAL_COMMUNICATION 对应 IM、VOIP、未接来电，横幅、锁屏、铃声振动全开；SERVICE_INFORMATION 对应出行、健康、账户提醒，也是全提醒；CUSTOMER_SERVICE 有铃声但没有横幅和锁屏；CONTENT_INFORMATION 和 UNKNOWN_TYPE 连铃声都没有，只有通知中心里的一条静默记录。

如果你把“客服回复”随手扔进了 OTHER_TYPES，用户收不到横幅也听不到声音，体验直接降级，但代码不会报任何错。

依赖隐式创建是在赌默认行为

文档里有一句话很容易被当成便利功能：NotificationRequest 携带 notificationSlotType，如果对应渠道不存在，会自动创建。这看起来省事，但渠道一旦被隐式创建，它的提醒能力就固定在了该 SlotType 的系统默认行为上，你后续很难再把它调成另一种打扰级别。

正确的做法是在应用初始化阶段，按业务模块显式 addSlot 创建渠道，让代码意图和渠道类型一一对应：

typescript

import { notificationManager } from '@kit.NotificationKit'

function initSocialChannel(): void {
  notificationManager.addSlot(
    notificationManager.SlotType.SOCIAL_COMMUNICATION,
    (err) => {
      if (err) {
        console.error(`addSlot failed: ${err.code}`)
      }
    }
  )
}

bypassDnd 不是默认选项

NotificationSlot 的 bypassDnd 字段控制是否绕过系统免打扰模式，默认 false。把它设成 true 意味着用户开了免打扰，你的通知仍然会响。这个字段只应该留给真正紧急且用户明确预期会响的场景，比如安全告警或用户自己设置的强提醒。普通消息为了“保证送达”去开 bypassDnd，是在透支用户对通知的信任。

渠道创建之后，用户可以在系统设置里单独关掉某一个渠道。应用侧应该通过 getSlot 查询 enabled 状态，检测到用户主动关闭时，不要在业务层反复弹窗求开启，也不要把强依赖该渠道能力的消息静默降级后假装已经送达。通知渠道的语义边界比“能不能发出去”更重要——发出去但不该响的时候响了，和该响的时候没响，对用户来说都是 bug。