而且就 block 这个做法来讲，开发者在开发测试上线各个环节都会遇到崩溃的情况，能够及时修复这个问题，基本没有机会让用户操作导致页面崩溃的情况发生，这样既保护了用户又约束了开发者，这种做法不合适嘛？

@xiangyuecn @Huelse @gadfly3173 请各位看看这个 policy ，是不是我说的这个意思

"web browsers are moving towards stricter autoplay policies in order to improve the user experience"，就提升用户体验来讲，chrome 团队认为 "block unwanted media autoplays" 要比 allow unmuted media autoplays 好，所以他们进行了 block 处理，如何实现 block ，这个 policy 没提到，我个人认为就是直接让页面崩溃，他们找不到比这更合适的做法了

@ie88 更正一下，是 roughly half 而不是 all

effectively blocking roughly half of unwanted media autoplays in Chrome ，是 half 而不是 all ，不也正好解释大家半天测试的时候，有的时候出现崩溃，有的时候没崩溃的情况吗

@gadfly3173 https://developer.chrome.com/blog/autoplay/#webaudio
我刚看了下 Autoplay policy in Chrome ，有以下描述

The Autoplay Policy launched in Chrome 66 for audio and video elements and is effectively blocking roughly half of unwanted media autoplays in Chrome. For the Web Audio API, the autoplay policy launched in Chrome 71. This affects web games, some WebRTC applications, and other web pages using audio features. More details can be found in the Web Audio API section below.

As you may have noticed, web browsers are moving towards stricter autoplay policies in order to improve the user experience, minimize incentives to install ad blockers, and reduce data consumption on expensive and/or constrained networks. These changes are intended to give greater control of playback to users and to benefit publishers with legitimate use cases.

Chrome's autoplay policies are simple:

Muted autoplay is always allowed.
Autoplay with sound is allowed if:
The user has interacted with the domain (click, tap, etc.).
On desktop, the user's Media Engagement Index threshold has been crossed, meaning the user has previously played video with sound.
The user has added the site to their home screen on mobile or installed the PWA on desktop.
Top frames can delegate autoplay permission to their iframes to allow autoplay with sound.

我觉得这个 policy 已经说得很明确了，所以页面直接崩溃（ effectively blocking roughly half of unwanted media autoplays in Chrome ）是 Chrome 现在正在用的做法，不属于 bug 不是吗？

@gadfly3173 哦，我大致明白了，多谢指点。

@gadfly3173 你说的自动播放视频通常视频流是被加密了的，应该不会被恶意篡改。而 AudioContext 这个 API 播放音频流应该没有做到加密处理，应该被恶意篡改的风险很高吧

@gadfly3173 你说的这些目前是这样的，可是如果 AudioContext 这个 API 没经过用户操作就能进行音频播放的话，是不是很容易出现类似网页被挂马这种情况，自动播放一些不和谐的音频，可能让审查机构误认为是网站开发人员故意操作的。

@gadfly3173 刚回答忘了 @

“而且这样崩溃了，谁知道问题是出在这里啊”：页面崩溃，这段提示"The AudioContext was not allowed to start. It must be resumed (or created) after a user gesture on the page." 已经在 console 有了，所以是能帮助开发者定位到问题的。现在应该是缺少给用户提示的信息，尤其是这种恶意行为，要警示用户，小心访问此类站点，类似 ssl 过期这种提示，让用户选择继续访问还是不访问

而且 The AudioContext was not allowed to start. It must be resumed (or created) after a user gesture on the page.
用到的是 not allow 和 must be ，而不是 not recommend 和 should be ，已经很严格了不是吗？

@gadfly3173 那用户层面应该怎么防止利益持续被损害呢？或者说怎么让用户知道该网页存在这种恶意行为？我个人觉得让网页直接崩溃可以有效提醒用户，至少让用户知道网页代码有 bug ，这个时候反馈到开发者，由开发者来处理这个 bug 或者恶意篡改，不然页面不崩溃，用户利益持续受损，用户也没办法察觉这种恶意行为，只在 console 里 log 出来并不能告知用户，这个页面存在一定安全隐患，让他停止访问这种站点。

@Huelse 我是前端初学者，请赐教：浏览器不允许无用户操作的情况下 new AudioContext()，你在浏览器引擎 catch 了这个 exception 应该怎样提示用户，告诉用户这个页面有代码使用了 AudioContext ，又怎样提示开发者，没有用户操作不能使用 AudioContext ？除了页面崩溃我还没想出来什么合适的方法

@pi0piK 我和你版本一样，我的一点就崩

@xiangyuecn 是呀，我的截图可以看到具体说明说明了：The AudioContext was not allowed to start. It must be resumed (or created) after a user gesture on the page.
所以是觉得直接导致页面崩溃是属于 bug 嘛？

所以，有人可以告诉我这有什么意义嘛？
https://imgur.com/a/tvtsDic

@JerryY 方便加下 VX 吗，我想了解一下，azU0NTQ2MjcyMQ==