到目前为止，这真是一场冒险……我成功在 Ubuntu 机器上的 Chrome 与 iPhone 上的 iOS Safari 之间设置了远程调试，但过程可谓波折重重。不过令人恼火的是，Network（网络）标签页是空白的，而这恰恰是调试中最关键的部分。
我发现，将 preload="metadata" 设置后，音频在 iOS Safari 中首次点击即可播放；而如果设置为 preload="none"，则必须依次执行“播放 > 暂停 > 再播放”的操作，音频才能真正播放。
我用 video 标签也进行了测试，似乎存在类似的问题。
之前将 preload 改为 none 是出于您在此处提交的错误报告：https://meta.discourse.org/t/secure-media-uploads-expire/140894。现在我们陷入了一个相当尴尬的境地：如果把 preload 改回 metadata，上述问题又会重现。我们最近已将预签名 URL 的过期时间延长至 5 分钟（参见 https://github.com/discourse/discourse/pull/10160），因此原始问题现在会 减轻，但依然存在。
我仍在思考并尝试各种方案……目前还不确定是否能两全其美。对于受保护的多媒体内容来说，需要多次点击才能查看，这并非理想的体验。
编辑：我的调试器中的 Network 标签页现在可以正常工作了。以下是我们内部 Discourse 实例中一个 preload="none" 的 audio 标签的示例：
-
点击播放：GET /secure-media-uploads/dev/original/4X/6/1/8/618a6b19a07de18205cc9889cb604e414b30372b.mp3，返回状态为 Finished（已完成）。
-
点击暂停。
-
再次点击播放：GET
presigned_url_here，返回状态为 206 Partial Content（部分内容），音频正常加载。
奇怪的是，当使用 preload="metadata" 时，我们得到的请求序列完全相同，而且只需一次点击播放。就像 Safari 在首次点击播放时获取元数据，然后仍需一次暂停和再次播放才能开始播放音频。
我不确定其他设备（例如 Android）是否也会出现这种情况？我目前没有设备可以在此方面进行测试。