Phaser 自适应音乐系统：音频总线、分层音乐和状态切换要平滑

音乐不是播一首循环就结束

Phaser 游戏里，音频经常被放到最后：进入场景播放 BGM，点击按钮播音效，战斗时换一首更激烈的音乐。这样能工作，但很难形成高级体验。玩家从探索走进危险区域，音乐应该逐渐紧张；Boss 破防时鼓点可以加重；战斗结束后音乐不该突然切断；打开菜单时音乐可以降低而不是停止。自适应音乐的目标是让声音跟随游戏状态变化，同时不打断节奏。

浏览器音频环境又带来额外限制：移动端需要用户手势解锁音频，标签页失焦可能暂停，蓝牙设备有延迟，自动播放策略随平台不同。Phaser 封装了 Sound，但我们仍然需要一个 AudioMixer 管理音乐层、音效总线、淡入淡出和状态切换。不要让每个 Scene 自己控制全局音乐，否则切场景时会互相覆盖。

先建立音频总线

总线是混音的基本边界。至少可以分为 music、sfx、ui、ambience、voice。每条总线有音量、静音、淡入淡出和全局设置。玩家设置音乐音量时，只影响 music；点击音效走 ui；环境风声走 ambience。这样菜单、战斗、剧情对话都能协调声音。没有总线，后期所有音量调整都会变成找具体 sound key。

Phaser WebAudioSoundManager 支持音量控制，但项目层仍应保存自己的总线状态。音频对象创建后挂到总线，Mixer 每帧或按事件更新最终音量。若浏览器退化到 HTML5 Audio，某些精细控制会受限，也要有降级策略。

flowchart TD
  A["GameState：探索、战斗、Boss、菜单"] --> B["MusicStateMachine"]
  B --> C["LayerMixer：底层、鼓组、紧张层、胜利层"]
  D["Settings：音乐/音效/语音音量"] --> E["AudioBusManager"]
  C --> E
  F["SfxEvent：攻击、按钮、环境"] --> E
  E --> G["Phaser Sound / WebAudio"]
  H["PageFocus / MobileUnlock"] --> E

分层音乐比硬切更自然

自适应音乐常见做法是分层。比如探索音乐有底层 pad、旋律、轻打击；战斗时逐渐加入鼓组和低音；Boss 时加入高强度层。所有层长度相同、节拍对齐，同时播放但音量不同。状态变化时，只调整各层音量。这样音乐连续，玩家不会感到突然换歌。

分层音乐要求音频素材制作时就规划好。每层必须无缝循环，长度、BPM 和起点一致。工程上也要确保同步播放。不要在状态变化时才启动新层，因为启动时间可能有微小偏差。可以在进入场景时同时启动所有层，未使用层音量为 0。代价是内存和解码成本更高，所以移动端要控制层数。

状态切换要有滞后

如果玩家刚碰到敌人就进入战斗音乐，敌人被秒杀又切回探索，音乐会来回抖。MusicStateMachine 需要滞后和最短持续时间。比如进入战斗需要敌人威胁持续 0.5 秒；退出战斗需要 5 秒无威胁；Boss 音乐一旦开始，至少持续到 Boss 战结束。菜单打开时降低音乐音量，但不改变底层状态。

状态优先级也很重要。Boss 高于普通战斗，剧情高于探索，失败结算高于一切。优先级要集中管理，不能多个系统同时说“我要播放我的 BGM”。AudioMixer 接收意图，按优先级选择最终音乐状态。

一个音乐层混音器

下面的代码展示了一个简化 LayerMixer，按目标音量平滑过渡。

interface MusicLayer {
  key: string;
  sound: Phaser.Sound.BaseSound;
  volume: number;
  target: number;
}

export class LayerMixer {
  private layers: MusicLayer[] = [];

  addLayer(key: string, sound: Phaser.Sound.BaseSound) {
    this.layers.push({ key, sound, volume: 0, target: 0 });
  }

  setTargets(targets: Record<string, number>) {
    for (const layer of this.layers) {
      layer.target = targets[layer.key] ?? 0;
      if (!layer.sound.isPlaying) layer.sound.play({ loop: true, volume: 0 });
    }
  }

  update(deltaMs: number, masterVolume: number) {
    const speed = deltaMs / 700;
    for (const layer of this.layers) {
      layer.volume += (layer.target - layer.volume) * Math.min(1, speed);
      layer.sound.setVolume(layer.volume * masterVolume);
    }
  }
}

这里的过渡是简单指数靠近。真实项目可以按音乐小节切换，在下一拍或下一小节开始淡入。节奏类或强音乐驱动游戏尤其需要按拍点切换，否则鼓点会乱。普通动作游戏使用 500 到 1500ms 淡入淡出已经足够自然。

音效也需要混音规则

音效不是越响越好。攻击、受击、拾取、按钮、环境音都可能同时播放。如果没有混音规则，战斗中按钮音听不见，或者金币声盖过 Boss 预警。SFX 可以按组设置最大并发和优先级。同一种小音效短时间内重复触发，可以合并或随机挑选变体。玩家受伤、Boss 读招、关键 UI 确认属于高优先级，不能被普通命中淹没。

空间音效在 2D 游戏里也有价值。远处爆炸音量更低，左右声道略有偏移，能帮助玩家判断方向。Phaser 的基础 Sound 不提供完整 3D 音频，但可以按距离手动调整音量和声像，或者直接使用 WebAudio Panner。移动端外放声道有限，不要依赖声像传达关键信息。

移动端解锁和恢复

移动端浏览器通常要求用户手势后才能播放音频。游戏启动页应该有明确点击开始，点击后解锁 AudioContext，并预热关键音频。不要在还没解锁时悄悄调用播放，然后失败后没有恢复。AudioMixer 应知道当前是 locked、ready、suspended 还是 muted。页面失焦时，可以降低或暂停音乐；恢复时按状态机重新设置音量。

蓝牙耳机延迟对普通游戏影响不如音游大，但 UI 点击和攻击音效仍可能显得慢。不要把关键判定绑定到音效结束。声音是反馈，不是游戏逻辑的时钟。对于剧情语音，字幕必须独立显示，不能因为音频播放失败而剧情卡住。

调试音频需要可见化

音频 bug 很难截图。开发模式可以显示当前音乐状态、每层目标音量和实际音量、总线音量、正在播放的音效数量、被限流的音效次数。再加几个按钮模拟进入战斗、退出战斗、打开菜单、失焦恢复，就能快速调试。音频团队也可以用这个面板确认层是否对齐。

还要记录音频事件日志。比如玩家反馈“Boss 音乐没响”，日志能显示是否进入 Boss 状态、层目标是否设置、sound 是否播放失败、AudioContext 是否 suspended。没有日志只能猜平台策略或资源加载问题。

上线前检查清单

确认音频分 music、sfx、ui、ambience、voice 总线；确认所有全局音乐由 AudioMixer 控制；确认分层音乐素材 BPM、长度和起点一致；确认状态切换有优先级和最短持续时间；确认菜单打开只 duck 音量而不是乱切曲；确认移动端有音频解锁流程；确认页面失焦恢复后音乐状态正确；确认高优先级音效不会被普通音效淹没；确认开发面板能查看层音量和 AudioContext 状态。

好的自适应音乐不是炫技，而是让玩家情绪自然跟上游戏。Phaser 足以承载分层音乐和音效总线，但需要一个统一 Mixer 来协调。把声音当作系统，而不是散落在 Scene 里的播放调用，游戏会立刻显得更完整。

横向重编排和纵向分层

自适应音乐常见两条路线：纵向分层和横向重编排。纵向分层是同时播放多层，通过音量组合改变强度；横向重编排是从探索段跳到战斗段，再跳到胜利段。前者平滑但素材占用多，后者结构清晰但切换点要求高。Phaser 项目可以混合使用：普通探索和战斗用分层，Boss 入场、胜利、失败用横向段落。

横向切换最好在音乐小节边界发生。AudioMixer 可以记录当前播放时间和 BPM，计算下一小节剩余时间，把切换请求排队。若危险事件非常紧急，比如玩家死亡，可以立即切换；普通状态变化则等待小节边界。这样音乐不会在鼓点中间断掉。即使不是音游，玩家也能感到声音更专业。

资源加载和内存预算

音频资源比很多人想象更占内存。分层音乐如果每层都是长音频，移动端会吃紧。可以按场景预加载当前需要的音乐组，离开场景后延迟卸载；常用 UI 音效和短提示音常驻；大型语音和活动音乐按需加载。AudioMixer 应知道某个层还没加载时怎么降级，比如先播放底层，鼓组加载完成后再淡入。

音频格式也要考虑浏览器兼容。通常需要提供压缩格式，控制码率，避免首屏加载被音乐拖慢。音乐加载失败时，游戏不能卡住。最多提示音频不可用，继续游戏。声音增强体验，但不应成为进入游戏的硬依赖，除非玩法本身完全依赖音乐。

Ducking 和侧链思路

菜单打开时降低背景音乐，语音播放时压低环境音，Boss 预警时让普通音效让位，这些都可以称为 ducking。实现上不需要复杂音频工程，只要总线支持临时音量修正。比如 voice 总线播放时，music 目标音量乘 0.55，ambience 乘 0.4；语音结束后缓慢恢复。关键预警音效也可以短暂压低普通 SFX，让提示更清楚。

Ducking 请求也要有优先级和生命周期。一个语音请求持续 3 秒，一个菜单请求持续到关闭，暂停界面请求可能覆盖所有。用 token 管理这些请求，避免某个请求结束时把另一个仍在生效的音量恢复掉。音频系统和输入锁一样，都需要认真处理叠加状态。

语音、字幕和本地化

如果游戏有语音，AudioMixer 还要配合字幕系统。语音播放失败、玩家关闭语音、语言包未下载时，字幕仍应正常推进。剧情不要等待音频结束作为唯一条件，可以使用语音时长和文本阅读时长中的较大值，也允许玩家手动继续。不同语言语音长度差异很大，时间线不能只按中文或英文素材写死。

语音和音乐的 ducking 也要考虑语言。某些语言音量偏小，某些角色声音频段接近环境音，统一压低 30% 未必够。可以给语音资源标注 loudness 或在制作阶段做响度归一。客户端不一定要做专业响度分析，但至少要给 voice 总线单独音量和优先级。

音频测试清单

音频验证不能只在开发机上听一遍。至少测试：首次点击解锁、切后台恢复、静音开关、蓝牙耳机、低电量模式、iOS Safari、Android WebView、桌面 Chrome、资源加载失败、快速切场景、连续打开关闭菜单。每个场景记录当前音乐状态和总线音量。很多音频 bug 只在生命周期边界出现。

还要做“无声可玩”检查。关闭全部音频后，关键预警是否仍有视觉提示？剧情是否有字幕？节奏玩法以外的游戏不应因为声音关闭而无法理解。声音增强沉浸，但基础可玩性要独立成立。

如果音频资源热更新，配置里还要记录资源版本。客户端发现版本不匹配时，应继续使用旧资源或静音降级，而不是在战斗中反复重试下载。