首先得说，你已经做了非常全面的客户端方案排查，iOS Safari对HEVC的Web生态支持确实是当前的痛点之一，尤其是大文件场景下的内存限制问题。

关于iOS Safari 16.4+是否存在无解码替换音频轨道的Web API #

目前没有原生Web API能直接实现不解码视频帧的情况下，安全地替换MP4/MOV容器中的音频轨道。原因很简单：

• WebCodecs不支持HEVC解码（你已经验证过VideoDecoder.isConfigSupported返回false），所以无法绕过解码直接操作视频轨道；
• 任何容器级操作（比如mp4box.js的轨道替换）都需要将至少部分核心容器数据（moov+mdat）加载到内存，大文件必然触发OOM；
• 其他像captureStream、Canvas这类方案，本质还是需要解码帧，内存开销根本扛不住大HEVC文件。

对你已考虑方案的进一步分析 #

1. mp4box.js + AudioDecoder提取音频：这个方案能解决裁剪音频的问题，但复用环节还是卡在内存上——替换音频轨道必须修改容器结构，大文件的mdat段加载到JS堆里肯定会崩溃，所以只能完成一半流程。
2. 服务器端复用：这是目前最可靠、最落地的方案。虽然会增加延迟和带宽消耗，但好处是：
   • 服务器有足够的内存和算力处理大HEVC文件，不用受客户端的限制；
   • 可以在服务器端用成熟的工具（比如FFmpeg）直接完成“裁剪视频前60秒+替换音频”的全流程，兼容性和稳定性都有保障；
   • 你甚至可以在服务器端对HEVC视频做轻量转码，后续返回给用户的文件体积可能还会更小。
3. mp4box.js容器级替换：如你所说，还是绕不开加载moov和mdat的内存问题，大文件场景下基本不可行。

有没有其他客户端尝试方向？ #

其实还有几个偏小众的思路，但实用性都不高：

• 强制用户上传H.264视频：通过<input accept="video/mp4;codecs=avc1">限制上传格式，但这会牺牲用户体验，毕竟iPhone默认是HEVC；
• MediaSource流式处理：尝试用mp4box.js将视频拆分为分片，流式加载并替换音频，但iOS Safari对MediaSource的HEVC支持很有限，而且流式替换音频轨道的逻辑复杂度极高，大概率得不偿失。

结论 #

针对iOS Safari上的大体积HEVC文件，服务器端复用是目前唯一可行的生产级方案。客户端方案要么受限于API支持，要么过不了内存这一关，暂时没有完美的替代方案。

内容的提问来源于stack exchange，提问作者Marble