自动关联目录：音频预算：静音 Voice 仍然不是零成本

核心判断：把超预算声音音量设为零，只解决听感竞争，不等于停止中间件 Voice、空间更新、RTPC、组件同步和容器遍历成本。

一、业务冲突：海量声音要保持时间连续，又不能都付完整成本

创作者可以放置大量环境音、交互音、语音和音乐。玩家靠近时希望声音从正确时间点自然出现，因此不能简单 Stop 所有远处声音；但让所有逻辑声音持续创建物理 Voice 并每帧同步 3D 参数，又会让成本随全场对象数增长。

问题的本质是两种连续性：逻辑时间是否继续推进，与物理声源是否持续渲染。它们不该由同一个 Playing 布尔值表达。

二、实际实现：稳定排序控制可听集合

工程按声音组优先级、到发声体表面的距离、有效音量和稳定 ObjectId 组成字典序评分，选出预算内的可听集合。超出集合的声音保持逻辑 Playing 与时间线，只把实际音量降为零，因此重新进入预算时可以从正确进度继续。

空间增益使用业务定义的滚降公式和表面距离，不能直接等价映射为 UE Attenuation。Actor 自身不 Tick，Transform 变化通过事件同步；Subsystem 在活动时 Tick，并以事件触发重排加低频兜底处理纯距离变化。

flowchart LR
    L[全部逻辑 Voice] --> S[稳定重要度排序]
    S --> A[Audible: 物理 Voice]
    S --> V[Virtual: 仅逻辑时钟]
    A --> M[空间/RTPC/混音更新]
    V --> C[低频资格检查]
    C --> S
    M --> S

三、值得保留：排序稳定且把距离算到发声表面

ObjectId 作为最后 tie-breaker，避免临界预算附近的声音每次遍历随机抢占。语音、音乐和音效分组后再比较空间与音量，也比全局只按距离更符合可懂度和业务优先级。

以发声体表面而非 Actor 原点计算距离，能正确处理大型区域音源。编辑器预览不占运行时预算、不修改脚本 Playing 状态，也正确隔离了工具试听与游戏语义。

四、结构性缺陷：静音项仍在每帧路径和中间件中存活

当前播放中的空间 Voice 仍会进入 Tick，更新 Transform、衰减与 RTPC；逻辑列表可以远大于物理预算，所以“最大可听数”并没有限制主线程遍历和中间件实例。音量为零也可能继续解码、混音和触发回调。

全量排序是 O(N log N)，且低频兜底轮询仍与全部 Playing 对象有关。若大量静态音源只因 Listener 移动而改变距离，更合理的入口应是空间索引和临界候选集，而不是每次扫描世界。

五、目标设计：Logical、Virtual、Physical 三层 Voice

Logical Voice 只保留播放意图、时间锚点和资源身份；Virtual Voice 以低频或事件推进资格，不持有解码/混音句柄；Physical Voice 才占中间件预算并更新空间参数。晋升时按逻辑时钟 Seek，降级时保存时间并释放 PlayingId，而不是简单静音。

静态发声体进入空间索引，Listener 移动只查询进入“预算边界 + 滞回区”的候选。动态声源按更新桶分帧，重要 Voice 高频、临界 Voice 中频、远端 Virtual Voice 事件驱动。预算按平台和声音组配置，并为语音等关键类别保留配额。

void Rebalance(const Listener& listener)
{
    CandidateSet c = spatialIndex.Query(listener, promotionRadius);
    RankedSet desired = budgets.SelectStable(c, groupQuotas, hysteresis);
    for (VoiceId id : physical - desired) DemoteToVirtual(id);
    for (VoiceId id : desired - physical) PromoteAndSeek(id, LogicalTime(id));
}

六、成本模型：预算要约束真实工作而非一个数字

平台降级优先减少 Physical Voice、更新频率和空间精度，不应改变关键语音与玩法提示的顺序。音频优化的正确终点是“听感不变量仍成立，实际工作集受预算约束”。