音效延迟播放却一直不响？先核对 Web Audio 使用哪一条时钟

希望按钮点击后半秒响一声，代码没有报错，却一直等不到音效。先固定同一份音频文件，检查传给start的时间值究竟来自哪里；没有异常并不表示声音被安排在你以为的时间点。

单位相同，不代表属于同一条时间轴

MDN 的start说明指出，when以秒为单位，使用与AudioContext.currentTime相同的时间坐标。它不是从现在起等待多少秒的相对延迟参数。

Date.now描述的墙上时钟时间，即使除以1000，也不能直接当作音频上下文的时间戳。currentTime文档说明了音频上下文自己的时间属性。先查时间来源，再检查单位，不要只在毫秒与秒之间反复转换。

用一个可手算的虚构例子检查语义

假设读取到的上下文时间为12秒，设计需要再等0.5秒，则对应调度时刻为12.5秒，而不是把when直接写成0.5。这是说明绝对时间与延迟区别的算术示例，不是本文在设备上测出的时延。

文件内从哪里开始播放是另一项需求。不要把文件偏移填进调度时刻，也不要用延后开始掩盖文件开头的静音；先明确自己要改变的是触发时刻还是素材内容。

先记录，再做一次受控调度

1. 记录真实接口、音频上下文状态与文件是否已经解码，不假设所有播放器都使用Web Audio。
2. 在安排播放时记录currentTime、期望延迟、计算后的when，以及它们各自的单位。
3. 检查声音实例与输出链路，保留立即播放的对照分支。
4. 在可控测试中观察实际触发，区分尚未运行的上下文、错误调度和输出链路异常。

这些记录是建议排查项，不是现成的完整播放器。若立即播放也无声，先检查上下文与播放许可等基础条件，不因为调度计算正确就认定是素材损坏。

不要把一个定时器回调当作精确同步证明

主线程繁忙、页面状态与播放器生命周期都值得记录。用JavaScript定时器稍后才创建声音，和提前在音频时间轴上安排声音，是需要分别验证的实现。本文不承诺固定设备延迟或所有浏览器都达到同一同步精度。

当游戏逻辑需要与动画事件同步时，还要定义迟到事件的处理规则：立即播放、丢弃还是重新安排应由产品需求决定，不能默默堆积越来越多过期提示音。

保留原始音效作为对照

从音效工具选定一个版本后保留导出文件名，用相同素材比较立即播放、延迟播放与连续触发。工具内试听成功，不等于接收项目的调度时间正确。

验收记录应同时包含期望延迟、实际调度数值、上下文状态与听到的结果；没有测量设备时不编造毫秒级延迟指标。只有确认文件本身需要改变时，才回到素材生成环节。