HTML5 Notification本身不带声音，所谓“通知声音”实为页面额外用Audio对象或Web Audio API主动触发；关闭需定位并禁用相关play()调用或第三方库的sound配置。
HTML5 Notification 默认不带声音，关什么？
HTML5 的 Notification API 本身**不提供声音播放能力**，也没有 sound、audio 或类似配置项。你听到的声音，几乎一定是页面额外用 Audio 对象、play() 或 Web Audio API 主动触发的——和通知本身无关。
所以“关闭通知声音”，实际是关掉那个被开发者手动绑定在 notification.onclick、notification.onshow 甚至定时器里的 new Audio().play()。
怎么找到并禁用那个偷偷播音的 Audio
常见做法是：页面监听通知显示或点击后，立即播放一段提示音。这段逻辑往往藏在事件回调里，不容易一眼看出。
- 打开浏览器 DevTools →
Application标签页 → 查看Service Workers是否注册了后台脚本（有些通知音由 SW 触发） - 在
Console中执行getEventListeners(document)或搜索Notification.prototype.onshow是否被重写 - 全局搜索代码中的
new Audio(、.play()、AudioContext，尤其关注Notification创建之后的几行 - 临时屏蔽：在控制台运行
HTMLMediaElement.prototype.play = function() {};（仅当前页生效，可快速验证是否为音频对象导致）
如果用的是第三方通知库（如 noty、izitoast）
这些库常自带「响铃」开关，但命名五花八门，且默认可能开启：
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
-
noty：检查初始化时是否有sound: true或timeout: false配合自动播放逻辑 -
izitoast：确认没调用iziToast.show({ sound: '/path/to/sound.mp3' })—— 这个sound字段才是真凶 -
snackbar类组件：留意是否在onOpen回调里嵌了new Audio().play()
别信文档里写的「silent by default」，很多库的 demo 示例里就带着 sound: 'xxx.mp3'，一复制就中招。
浏览器扩展或企业策略强制加音效？
极少数情况，声音不是网页代码发出的，而是：
- Chrome 扩展（比如「通知增强器」「消息提醒大师」）劫持了
Notification构造函数，注入自己的音频逻辑 - 公司内网统一部署的浏览器策略（通过 ADMX / Intune）启用了系统级通知音效，这类无法被网页 JS 控制
- macOS 系统设置 → 通知 → 对应网站勾选了「播放声音」（注意：这是系统级行为，只影响 Safari，Chrome/Edge 不走这个通道）
真正难排查的，永远是那一行没写注释的 new Audio('/beep.mp3').play() —— 它可能被包在 Promise 里、延迟 300ms 执行、甚至藏在 catch 分支里报错时才响。
