指南 · macOS 内录 · 一手 · 更新于 2026-09-06
Mac 录电脑自己的声音：三种办法，和那个不报错的哑掉。
在 Mac 上录下电脑正在放的声音有三条路。想免驱动、不改输出设备，用基于 ScreenCaptureKit 的 App —— 这是现在这套系统自己提供的路，对你的机器改动最小。声音要送进另一个只认麦克风的 App（浏览器、会议客户端、编曲软件），装虚拟声卡。只想临时录一个文件、不想再装别的，QuickTime 加虚拟声卡。不管走哪条，有两件事所有人都会撞上，而且在你会去找的地方都没写：ScreenCaptureKit 要求屏幕醒着；它背后的守护进程会卡死成「流是通的、没有报错、一个字节都没有」。下面是这两件事，以及我们在这套接口上做实时字幕时量到的数。
办法一：ScreenCaptureKit，不装驱动
ScreenCaptureKit 是 Apple 用来采屏幕内容和系统音频的框架，音频这一面的文档在 Capturing screen content in macOS。基于它的 App 录别的 App 在放的声音，不用虚拟声卡、不用内核扩展、不动你的输入输出设备 —— 录着的时候耳机照常响。
- 打开 App 开始采集，macOS 会问一次「屏幕与系统音频录制」。
- 系统设置 → 隐私与安全性 → 屏幕与系统音频录制，勾上，再开一次。
- 整段录制期间别让屏幕休眠，原因在下面。
在依赖它之前，先知道这三条边界
屏幕必须醒着。它采集前要先枚举显示器，屏幕睡着时直接报 no display found，一个字节都采不到 —— 哪怕你要的只是声音。要挂着无人值守地录，就得先解决屏幕不睡这件事。
没有窗口的进程采不到。命令行里 afplay 某个.wav 放出来的声音，喇叭里听得见，采集里没有：这套接口是按「有窗口的应用」组织的。这一条在自测时特别坑，因为最顺手的造测试音的方法，恰好是唯一采不到的那种。换成用真的 App 播那个文件。
权限记在启动它的进程上。从「终端」跑起来的采集助手继承终端的授权，弹窗上写的也是终端，不是你的助手。同一个二进制被打包好的 App 拉起来，弹的就是那个 App。App 改名或换了 Bundle ID，macOS 当成另一个应用，用户得重新勾一次 —— 这一条会在你第一次给产品改名的当天变成一张客服工单。
办法二、三：虚拟声卡，配不配 QuickTime
虚拟声卡在 macOS 眼里同时是一个输出和一个输入。把系统声音送进它，任何能从麦克风录音的 App 就都能录到。这是更老的办法，但在接收方只认麦克风时（浏览器标签、会议客户端、编曲软件），它仍然是对的那条。
代价是它真的改了你的机器：装了一个音频驱动，而且录制期间你的输出设备是那块虚拟卡，得再把声音绕回喇叭才听得见。多输出设备能解决，配起来麻烦。
QuickTime Player 能录音，也乐意从虚拟输入设备录，这就是最省事的一次性配方：装虚拟声卡 → 选成输出 → QuickTime → 文件 → 新建音频录制 → 输入选那块虚拟卡。只有 QuickTime、不装虚拟声卡，是录不到系统声音的。
不报错的哑掉：replayd 卡死
这一段没有出现在任何一篇教程里，我们为它熬了两个晚上。
macOS 把 ScreenCaptureKit 跑在一个后台守护进程上：/usr/libexec/replayd。在 macOS 26.5.2、开机连续跑了 45 天之后，它卡死了。从 App 这边看一切正常：流建起来了，startCapture 成功返回，没有权限错误，没有异常。然后一个音频回调都不来。零字节，一直零，而界面有充分的理由相信自己正在录音。
怎么修：
- killall replayd —— 没用。
- kill -9 $(pgrep -x replayd) —— 有用，而且不用 sudo。launchd 秒把它拉回来，采集恢复。
如果你是在这套接口上做产品而不是录一次，有两个推论。第一，流启动成功不等于流在工作：维护一个单调不减的字节计数，把「ready 了、几秒后还是 0」当成一个独立的故障态，措辞和「没给权限」分开。第二，踢一次守护进程会打死这台机器上所有 ScreenCaptureKit 流，包括你自己开的另一路，所以其他流也要跟着重开。
我们自己的自愈在 2026-09-02 那天（守护进程正卡着）验过：判定零字节 → kill -9 一次 → 换一路新采集 → 接下来 15 秒进来 489,600 字节。只做一次，不循环 —— 回不来就是别的问题，重试循环只会把它盖住。
采集正常的时候，数字长什么样
想判断采集是不是真的在工作，比波形更好用的是比对速率。本机实测，采成 16 kHz 单声道 16 bit（语音识别要的那种形状）：
| 项 | 实测 | 说明 |
|---|---|---|
| 稳态字节率 | 31,782 B/s | 16k 单声道 16 bit 理论值 32,000 B/s 的 99.3% |
| 含启动的整段平均 | 理论值的 95.2% | ScreenCaptureKit 约 0.4 s 才给出第一个缓冲 |
| 48 kHz 立体声重采样到 16 kHz 单声道 | 比源短 17 ms | 0.025%，是重采样器启动延迟，不是漂移 |
| 重采样版与原生 16k 的能量包络相关性 | 0.9999 | 准确度的损失不在重采样这一步 |
四个数都来自我们自己的运行：Apple 芯片 MacBook，macOS 26.5.2，2026-08 与 2026-09。写出来是因为字节率可以被证伪，「效果很好」不能。
这些数从哪来：Voice Translator（Mac）就走这条路给英文会议出双语字幕，它的延迟也是这么量出来公开的。只想把 Mac 上的声音看成文字、不要翻译，先看系统自带的即时字幕；已经拿到字幕文件要换格式，用字幕格式转换器。
常见问题
Mac 内录一定要装虚拟声卡吗？+
不一定。基于 ScreenCaptureKit 的 App 可以直接采系统音频，不装驱动、不改你的输入输出设备，耳机照常用，只要授一次「屏幕与系统音频录制」。代价是它采不到没有窗口的进程：在终端里 afplay 放的音频你听得见，它采不到。
为什么录出来是一片静音，还不报错？+
多半不是权限。macOS 把 ScreenCaptureKit 跑在后台守护进程 /usr/libexec/replayd 上，这个进程会卡死：流建得起来、startCapture 成功、没有任何报错，但一个音频回调都不来。我们在 macOS 26.5.2 上开机 45 天后遇到过。killall replayd 没用；kill -9 $(pgrep -x replayd) 有用，不用 sudo，launchd 立刻把它拉起来，采集就恢复了。
屏幕必须一直亮着吗？+
是。ScreenCaptureKit 采集前要先枚举显示器，屏幕睡着时直接报 no display found，哪怕你只要声音也一样采不到。要挂着无人值守地录，就得让屏幕别睡。
权限到底是给哪个 App 的？+
给启动它的那个进程。从「终端」里跑起来的采集助手继承的是终端的权限，弹窗上写的也是终端；同一个二进制被一个打包好的 App 拉起来，弹的就是那个 App。App 改名或者换了 Bundle ID，macOS 当成另一个应用，权限要重新勾一次。
相关：Mac 即时字幕怎么开 · 字幕格式转换器 · 字幕延迟实测