必须同时满足设备识别、权限授权、音频上下文激活三条件；需用户点击按钮触发navigator.requestMIDIAccess()和AudioContext.resume()，并在地址栏点击MIDI图标授权，SysEx需额外启用flag并调用sysex:true参数。
要在谷歌浏览器中让网页端MIDI键盘真正发出声音，必须同时满足设备识别、权限授权、音频上下文激活三个硬性条件，缺一不可；仅连接设备或点击“开始”按钮无法触发音频输出。
启用网站MIDI设备访问权限
第一步：打开目标网页（如Sonic Pi Web、Tone.js Playground或MuleRun），确保页面完全加载完毕。
第二步：在页面上执行一次明确的用户手势——例如点击标有“Connect MIDI”“Enable Keyboard”或“Start”字样的按钮，该按钮必须绑定 navigator.requestMIDIAccess() 调用。
第三步：地址栏左侧将立即出现MIDI图标（形似钢琴键或音符），【务必点击该图标并选择“允许”】；若未弹出，说明按钮未正确绑定API，或页面脚本未注入。
第四步：如仍无反应，手动访问 chrome://settings/content/midi，确认“网站可以请求访问您的MIDI设备”已开启，并检查下方“不允许”列表里是否误加入了当前域名。
激活Web Audio上下文以驱动MIDI发声
这一步是绝大多数失败案例的根源：MIDI消息能被接收，但音符静音，就是因为AudioContext没被用户手势唤醒。
在网页中找到并点击任意带 onclick 或 onpointerdown 的交互控件（比如一个灰色“▶”播放按钮），确保它内部执行了以下逻辑链：
const ctx = new (window.AudioContext || window.webkitAudioContext)(); ctx.resume(); → 紧接着调用 navigator.requestMIDIAccess() → 绑定 input.onmidimessage 处理器。
注意：如果页面自动执行这些代码（如放在 window.onload 里），Chrome会直接拒绝激活音频上下文，【必须由真实点击/触摸触发整条链路】。
验证MIDI输入是否被正确捕获
方法一：打开开发者工具（F12）→ Console 标签页，粘贴运行：
navigator.requestMIDIAccess().then(acc => { acc.inputs.forEach((i, idx) => console.log(`输入${idx}:`, i.name, i.state)); });
若输出中某项 state 为 "connected"，说明设备已识别；若全为 "disconnected"，返回第一步检查USB连接与驱动。
方法二：访问 chrome://webrtc-internals → 点击右上角“Enable diagnostic audio recordings” → 回到网页敲击MIDI键 → 观察是否生成新PeerConnection及活跃音频轨道。无轨道更新=AudioContext未resume成功。
启用SysEx支持（仅限高级MIDI控制器）
如果你的MIDI键盘需发送系统专有消息（如Korg nanoKONTROL2的LED反馈、Akai MPK Mini MK3的旋钮映射），必须额外开启SysEx通道：
① 访问 chrome://flags → 搜索“sysex” → 找到“Web MIDI API System Exclusive Messages” → 设为“Enabled” → 点击右下角“重启”。
② 再次进入目标网站 → 点击地址栏锁图标 → “网站设置” → “MIDI设备” → 勾选“允许系统专有消息（SysEx）”。
③ 页面JS中必须使用带参数的调用：navigator.requestMIDIAccess({sysex: true})；无参调用即使UI已授权，仍会静默拒绝SysEx端口。
