纯html+css无法实现真正可交互的dj混音台，因其缺乏实时音频处理、滑块精准联动与节拍同步能力；必须依赖javascript结合web audio api实现毫秒级响应、对数映射、声像控制及ios手势唤醒等核心功能。
纯 HTML + CSS 做不出真正可交互的 DJ 混音台界面——它必须依赖 JavaScript 处理实时音频、滑块联动、节拍同步等逻辑；HTML 只能负责结构和视觉层，且默认不带任何音频能力。
为什么 <input type="range"> 不能直接当音轨推子用
浏览器原生 <input type="range"> 渲染的是系统控件，样式不可控、拖动响应延迟高、无法绑定音频参数（如 Web Audio API 的 gainNode.gain.value），且在 macOS Safari 和部分移动端存在惯性滑动干扰。真实混音台推子需要：毫秒级响应、线性/对数映射、防抖更新、键盘微调支持（←→↑↓）、以及与音频图实时同步。
- 用
<div> + <code>mousedown/touchstart+mousemove/touchmove自实现滑块容器，才能精确控制拖动坐标到分贝值（dB）的映射关系 - 推子值建议映射为
-∞ dB → +6 dB范围，用对数公式：Math.pow(10, value / 20)转成线性增益值传给gainNode.gain.setValueAtTime() - 避免直接监听
input事件更新音频——它触发太频繁，应节流（requestAnimationFrame或setTimeout(..., 0)）后批量提交
Web Audio API 中 createGain() 和 createChannelSplitter() 怎么配对做声像（Pan）控制
DJ 混音台左右声道平衡（Pan）不是简单改左/右音量，而是要保持总能量守恒。直接调两个 gainNode 会导致中间位置音量衰减 3dB。正确做法是用 stereoPannerNode，或手动用 channelSplitter + channelMerger 构建双通道处理链：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
const splitter = audioCtx.createChannelSplitter(2); const merger = audioCtx.createChannelMerger(2); source.connect(splitter); // 左通道走左 gain，右通道走右 gain，再合并 splitter.connect(leftGain, 0); splitter.connect(rightGain, 1); leftGain.connect(merger, 0, 0); rightGain.connect(merger, 0, 1);
但注意：createChannelSplitter() 仅支持 2+ 通道输入，若源是单声道（MediaElementAudioSourceNode），需先用 convolverNode 或 gainNode 显式复制通道，否则 splitter 输出为空。
AudioContext 在 iOS Safari 上静音后无法自动恢复播放的硬伤怎么绕
iOS Safari 要求所有音频必须由用户手势（click、touchend）触发首次 audioCtx.resume()，之后才能播放。但 DJ 台常需“点击旋钮即生效”，不能只靠一个全局播放按钮。
- 每个可触发音频操作的 UI 元素（如
playButton、cueButton、甚至volumeKnob的mousedown）都得绑一次audioCtx.resume()，且只能调用一次（后续调用无效） - 不要在
DOMContentLoaded或load里调resume()——iOS 会静默失败，控制台也不报错 - 检测是否已激活：
audioCtx.state === 'running'，否则提示用户“请点一下屏幕任意位置启用声音”
真正卡住人的从来不是画几个旋钮或推子，而是音频时序精度（currentTime 漂移）、跨设备节拍同步（WebRTC DataChannel 延迟不稳定）、以及 iOS 后台音频中断恢复——这些没法靠 HTML 标签解决，得一层层啃 Web Audio 的 timing model 和平台行为差异。
