外置 SSD 在 Mac 上为何越用越慢：被忽视的 Trim 问题

去年春天还能以 900 MB/s 拷完 40 GB 项目文件夹的那块外置 SSD，如今做同样的事要花十一分钟。其他什么都没变：同一根线、同一个接口、同一台 Mac、同一块硬盘。而当你把那个文件夹从硬盘里拷回来时，速度依旧飞快。读取和当初一模一样，只有写入彻底崩了。

这种不对称本身就是全部线索。线材有问题会同时拖慢读和写。接口故障会同时拖慢读和写。过热降频会让所有操作都变慢，等外壳凉下来又恢复。而一块写入速度崩塌、读取速度却毫发无损的硬盘，正在向你展示一个具体且早已被研究透彻的故障：它的闪存已经耗尽了预先擦除好的块，而且没有任何人告诉它哪些块可以擦除。这就是 Trim 问题。

令人抓狂的是接下来发生的事。你去搜索如何在 Mac 上检查 Trim 状态，会在几十个网站上找到同样的两条建议——其中一篇还是我们自己发的。用 system_profiler SPSerialATADataType | grep TRIM 检查，用 sudo trimforce enable 修复。在现代 Mac 上，第一条命令什么都不会输出，第二条对 USB 硬盘毫无作用。这两条既不是笔误，也不是被弃用，更不会报错告诉你它没生效。它们只是悄无声息地变得毫不相干。

这篇指南要解决的就是这个问题。它会解释 Trim 到底做了什么、为什么它的缺席偏偏惩罚写入，教你如何把 Trim 问题和四种长得很像的故障区分开，用你可以亲手运行的命令演示那两个标准检查究竟为何失效，然后给出在 Apple 芯片 Mac 上真正管用的两种检查方法。本文中所有标注为「实测」的内容，都是在一台运行 macOS 26.5.2、版本号 25F84 的 Apple 芯片 Mac 上采集的。

核心要点

• 读写不对称就是诊断依据 —— The Eclectic Light Company 的 Howard Oakley 给出了一个具体数字：「如果它的写入速度已经降到读取速度的 20% 或更低，那你可以确信存在 Trim 问题。」
• sudo trimforce enable 不是外置硬盘的解药 —— 它自己的手册页写着，它启用的是「连接到 AHCI 控制器的第三方硬盘」的 Trim，也就是 SATA 接口，因此它对 USB 或 NVMe 硬盘毫无作用。
• system_profiler SPSerialATADataType 在 Apple 芯片上什么都不输出 —— 这个数据类型在那些机器上根本不存在，所以互联网上被抄得最多的这条 Trim 检查命令，返回的是一个空结果，而人们却把它误读成了某种证据。
• 真正管用的是 system_profiler SPNVMeDataType 和挂载时刻的统一日志 —— APFS 只在卷宗挂载时输出它的 Trim 扫描记录，所以你必须拔掉硬盘、记下时间、重新插上，然后立刻读日志。
• 唯一的治本办法是彻底抹掉并重新格式化 —— 没有任何面向用户的命令可以按需对硬盘执行 Trim，而且 Apple 也没有发布任何兼容性列表，告诉你哪些硬盘盒在购买前就能确认可以透传 Trim。

Trim 到底做了什么，以及为什么只有写入受害

擦除块难题

闪存的不对称是刻在硅片里的。你可以随意读取任何页。你可以往一个当前处于擦除状态的页里写入。但你无法覆写一个已经存有数据的页。要复用它，硬盘必须先擦除它，而擦除不是逐页进行的，它以一个大得多的单位进行，这个单位叫做擦除块，里面包含许多页。

Howard Oakley 直白地描述了后果：「在 SSD 能够写入一个已被使用过的存储块之前，它必须先擦除该块，而它的擦除-写入周期时间慢得可怕。」

这就是全部机制。当硬盘手里握着充足的、已经擦除好的块时，一次写入就是一个简单的编程操作，能以硬盘的标称速度完成。当它一个都没有时，每一次写入都会变成一连串的工作：找到一个含有部分失效页的块，读出那些仍然有效的页，把这些有效页写到别处，擦除整个块，最后才写入你的新数据。这条链路叫做「读-改-写」，它耗费的时间可能比一次干净的写入高出一个数量级。

为什么硬盘自己搞不定这件事

接下来这部分会让很多人意外。当你删除一个文件时，硬盘并不知道。文件系统更新了自己的元数据，把那些逻辑块标记为空闲，但从硬盘控制器的视角看，它曾经被要求写入过的每一个逻辑块，里面都仍然是有效数据。它没有办法分辨哪个块装的是你上个月删掉的视频，哪个块装的是你正在用的项目文件。它必须把两者都保留下来。

Trim 就是弥合这道鸿沟的那条消息。当文件系统释放空间时，它可以发送一条 Trim 命令，列出那些不再存有任何操作系统关心的内容的逻辑块地址。硬盘会把它们标记为无效，随后它的后台垃圾回收就可以自由地整理并擦除它们，从而建立起那个让写入保持高速的预擦除块池。

没有 Trim，这个池子会随着硬盘被填满而不断缩小直至归零，然后永远停在零。硬盘并没有坏，闪存也没有磨损殆尽。它只是把大部分时间花在了本可以几小时前就在后台完成的擦除周期上。

为什么读取始终飞快

读取从不需要擦除。一次读取就是在闪存转换层里做一次查表，然后对某一页执行一次感应操作。硬盘里装的是一百 GB 货真价实的有效数据，还是一百 GB 六个月前就已在逻辑上被删除的数据，对它把你要的那一页交回来的速度毫无影响。

这就是为什么这个症状如此鲜明，也是为什么它值得信赖。一块有 Trim 问题的硬盘并没有生病。你能在它身上做的其他任何测量看起来都很正常：S.M.A.R.T. 状态良好，卷宗瞬间挂载，Disk Utility 的「急救」能通过，顺序读取还是第一天的那个数字。只有写入路径退化了，因为只有写入路径依赖手头是否有擦除好的块。

一块从未被 Trim 过的硬盘随时间如何变化

这种退化既不是线性的，也不是立刻发生的，这正是人们要花上几个月才注意到它的原因。

一块全新的或刚刚抹掉的 SSD，每一个块都处于擦除状态，所以写入可以直接通过。这个状态会一直持续，直到整块硬盘的全部容量至少被写过一遍。累计写入的总字节数比它此刻在 Finder 里看起来占用了多少更重要：一块 2 TB 的硬盘，即使任何时刻装的数据都没超过 400 GB，只要你把 400 GB 的素材来回倒腾过二十次，它的每一个物理块也都可能已经被碰过了。

过了这个点之后，能收到 Trim 的硬盘每次删除后都会干净地恢复。收不到的则永远不会恢复。它的控制器把自己写过的每一个块都当作有效数据保留着，制造商预留的那点超额配置余量（通常是个位数百分比）成了仅剩的空闲区域，于是它只能为每一次写入死磕「读-改-写」。

所以这块硬盘会有六到十八个月看起来一切正常，然后在短短几周内变得难以忍受。那几周里什么都没发生。你只是越过了一道门槛。

症状特征：把 Trim 问题和四种相似故障区分开

Mac 上的外置硬盘变慢有好几种原因，而在硬盘寿命的第一年里，其中三种比 Trim 常见得多。在你抹掉任何东西之前，先确认你面对的确实是这个故障。

这个症状常见到 Apple 官方支持论坛上都有反复出现的讨论帖，包括讨论 254727504「Why is my external SSD so slow at writing?」和讨论 255040461「Slow external SSD」。如果你想在动手测试前先看看别人是怎么描述同一个问题的，那里是个合理的去处。

比例测试

在两个方向上各拷贝一个大文件，至少 8 GB，并给两次都计时。不要用装满小文件的文件夹，那测的是文件系统开销而不是原始吞吐量。就用一个大文件。

然后做对比。如果读和写都慢，而且两者慢得差不多，问题出在连接上，不在闪存里。如果读取正常而写入只有它的一个零头，你就进入 Trim 的地界了。Oakley 的阈值值得记住：降到读取速度的 20% 或更低，就可以确信了。

症状对照表

你观察到的现象	最可能的原因	如何确认
写入慢、读取正常，而去年两者都好好的	Trim 没有到达硬盘	先做比例测试，再做下文的挂载时刻日志检查
读和写都慢，慢的倍数相近	线材、接口，或链路协商到了低于标称的速度	换线、换接口，在「系统信息」中查看协商速度
一开始快，20 到 60 秒后大幅下降，暂停一下又恢复	SLC 写入缓存耗尽或过热降频	跑一次 3 分钟以上的单次传输并观察曲线；摸一摸硬盘盒
只有拷贝大量小文件的文件夹时才慢	文件系统和元数据开销、Spotlight 索引、安全软件	换成单个大文件重试；如果那样很快，问题就不在硬盘
随机断连、弹出「磁盘未正常推出」、拷贝中途硬盘消失	总线供电或硬盘盒电源管理	先解决断连；在此之前所有速度测量都不可靠
硬盘在 Disk Utility 里能看到但 Finder 里没有，或者出现两次	挂载层的 bug，不是性能问题	这根本不是速度故障，抹盘也解决不了
在一台 Mac 上慢、在另一台上快，用的是同一根线	那台 Mac 的接口、集线器或扩展坞	把硬盘直接接到两台机器上测，中间不要接任何集线器
从第一天起就一直这么慢	不是 Trim。检查它到底是不是 SSD，以及链路协商到了什么速度	全新硬盘的所有块都是擦除状态，不可能已经有 Trim 问题

最后一行值得强调，因为它能让人免于无谓地抹掉一块硬盘。一块从来就慢的硬盘不可能存在 Trim 问题。 Trim 退化需要历史积累。如果硬盘开箱就慢，去查硬盘盒、线材，以及链路是否跑到了你付钱买的那个速度。

先排除连接问题

在这里花两分钟，可以省下一次不必要的抹盘。

打开「系统信息」（按住 Option 键点击苹果菜单，然后选「系统信息」），在 USB 或 Thunderbolt/USB4 下找到这块硬盘。查看链路实际协商到的速度，而不是盒子上印的速度。一块本可以跑 10 Gb/s 的硬盘，因为用了充电线而只协商到 480 Mb/s，双向都会慢得惨不忍睹。

system_profiler SPUSBHostDataType

这条命令以文本形式输出同样的 USB 树，包括每个已连接设备的链路速度。如果你用的是 Thunderbolt，改用 SPThunderboltDataType。这两个数据类型在 Apple 芯片上都存在——而正如下一节要讲的，所有人叫你用的那一个可就不一定了。

在下结论之前也换一根线试试。USB-C 线材实际支持什么能力差别巨大，一根充电完美的线可能只能跑 USB 2.0 的数据速率。排除这个变量不花一分钱，却能解释大量「我的 SSD 变慢了」的报告。

为什么互联网上那两个标准检查在现代 Mac 上会失效

这是最关键的一节，因为这里的错误建议不只是没用。它会主动误导人，因为它产出的是一个静默的、空的、不报错的结果，而人们会把它当成答案。

trimforce 做的事和几乎所有人说的都不一样

在你自己的 Mac 上运行 man trimforce。在 Apple 芯片的 macOS 26.5.2 上，这个手册页依然存在，这也是这条建议死不了的部分原因。下面是它逐字写的内容。

NAME 一行写着：「trimforce – enable TRIM commands on third-party drives.」

DESCRIPTION 写着：「trimforce enables sending TRIM commands to third-party drives attached to an AHCI controller. By default, TRIM commands are not sent to third-party drives. Use extreme caution when enabling TRIM, as some drives may not correctly handle the commands. trimforce must be run by the system administrator.」

enable 这个动作的文档说明是：「Start sending TRIM commands to AHCI-attached third-party drives. Requires a reboot to take effect.」

而 HISTORY 部分写着：「The trimforce utility first appeared in OS X 10.10.4.」

再读一遍 DESCRIPTION，停在这四个词上：attached to an AHCI controller。AHCI，即高级主机控制器接口，是 SATA 存储的标准主机接口。它不是 USB。不是 NVMe。也不是 Thunderbolt。

trimforce 在 2015 年的 OS X 10.10.4 里被造出来，是为了应对一个具体且如今基本已成历史的场景：有人拆开一台出厂配机械硬盘或 Apple SATA SSD 的 Mac，在里面装上第三方 SATA SSD，然后发现 macOS 默认拒绝向未经 Apple 认证的硬盘发送 Trim。trimforce 覆盖的就是这个拒绝。这就是它的全部用途，而那句关于某些硬盘「可能无法正确处理这些命令」的警告之所以存在，是因为在 2015 年确实有一些 SATA SSD 的固件存在 bug，被 Trim 后可能丢数据。

对于放在 USB 硬盘盒里的外置 SSD，trimforce 毫不相干。路径上根本没有 AHCI 控制器。硬盘位于一颗 USB 大容量存储或 UASP 桥接芯片后面，Trim 能否抵达闪存是由那颗桥接芯片决定的，而不是由 macOS 里的某个开关决定。对于 NVMe 硬盘，无论是内置的还是装在 Thunderbolt 硬盘盒里的，它同样毫不相干，因为 NVMe 也不是 AHCI。

我们自己也曾经搞错。 我们早先的macOS 外置 SSD 故障排查指南在一个关于外置硬盘性能的章节里，把 sudo trimforce enable 列在了「为第三方 SSD 启用 TRIM」下面。那条建议对外置硬盘而言是错的，本文取代它。手册页从 2015 年起就一直是那么写的，是我们读得不够仔细。如果你依据那条建议运行过这条命令，没发生什么坏事，但也没发生任何好事。

还有一个理由让你别下意识地伸手去用它。手册页自己那句「使用时务必极其谨慎」指向的是一个真实存在的故障模式，而且这条命令需要重启才能生效。为了一个它明确不覆盖的硬盘，去执行一次带有明文数据丢失警告的系统级存储设置变更，无论从哪个角度算都是笔亏本买卖。

system_profiler SPSerialATADataType 返回空结果

另一条被普遍复制的检查是这个：

system_profiler SPSerialATADataType | grep TRIM

在 Apple 芯片 Mac 上，它什么都不输出。不是「TRIM Support: No」，是一个字都没有。而原因并不是 Trim 被禁用了，而是这个数据类型在这台机器上根本不存在。

你可以用一条命令自己确认：

system_profiler -listDataTypes | grep -i sata

在 Apple 芯片 Mac 上，它没有任何匹配结果。不加过滤直接运行 system_profiler -listDataTypes 可以看到这台机器实际有什么，在我们实测的这台 Mac 上（macOS 26.5.2，版本号 25F84），与存储相关的条目包括 SPNVMeDataType、SPStorageDataType、SPThunderboltDataType 和 SPUSBHostDataType 等等。SPSerialATADataType 不在其中，因为 Apple 芯片 Mac 压根没有 SATA 控制器。内置 SSD 是通过 NVMe 挂在 SoC 上的，机器里任何地方都没有用户可以访问的 SATA 总线。

于是，互联网上被抄得最多的这条 Trim 检查，向一台现代 Mac 询问它并不具备的硬件，得到一个空答案，再把这个空答案通过管道交给 grep，而 grep 尽职地在里面什么也没找到。没有报错，没有警告，也没有任何东西会注意到的退出码。人们运行它，看到空白输出，然后得出他们本来就倾向于相信的那个结论。

在一台确实有 SATA 总线的 Intel Mac 上，这条命令是能用的，也确实会报告 SATA 设备的 Trim 状态。如果你还在用这样的机器，它对内置硬盘仍然有价值。但在任何一台 Mac 上，它都从未告诉过你关于 USB 外置硬盘的任何事情。

diskutil 同样不报告 Trim 状态

你还会看到第三种变体的建议：在 Disk Utility 或 diskutil 里查看 Trim 状态。那里没有这个信息。

diskutil info -all | grep -i trim

在我们实测的 Mac 上，它没有任何输出。diskutil info -all 会把 diskutil 所知道的、关于系统上每一块磁盘和每一个卷宗的全部属性都打印出来，而 Trim 不在其中。Disk Utility 的图形化信息面板里也没有。这不是找错了面板的问题。diskutil 确实不暴露 Trim 状态，所以任何暗示你能在那里读到它的指南，描述的都是一件不存在的事。

真正管用的检查方法

两种方法，用哪一种取决于硬盘是怎么连接的。

内置硬盘和 NVMe 硬盘用 system_profiler SPNVMeDataType

对于 Mac 的内置 SSD，以及那些通过 Thunderbolt 或 USB4 连接、macOS 直接以 NVMe 协议而非经由 SCSI 转换层与之通信的 NVMe 硬盘，macOS 确实会报告 Trim 支持情况，而且读起来很简单：

system_profiler SPNVMeDataType

输出是一棵小小的缩进树。开头是 NVMExpress:，然后是一个控制器条目（在 Apple 芯片上是 Apple SSD Controller:），再往下是作为标题的硬盘型号。在我们实测的这台 Mac 上，型号标题下报告的键按以下顺序出现：Capacity、TRIM Support、Model、Revision、Serial Number、Detachable Drive、BSD Name、Partition Map Type、Removable Media、S.M.A.R.T. status，以及 Volumes。

你要看的是第二行，TRIM Support。在我们实测的这台 Mac 的内置硬盘上，它显示为 Yes。这就是健康答案的样子，而且它与 Oakley 对现状的总结吻合：「所有 Apple 内置 SSD 都享有完整的 Trim 支持，采用 NVMe 接口的第三方外置硬盘理应也是如此。」

只想抓出那一行的话：

system_profiler SPNVMeDataType | grep -A1 -i "capacity"

或者干脆把整棵树读完，它短到几乎不值得过滤。如果一个外置 NVMe 硬盘盒能出现在这份输出里，那你的处境不错，因为出现在这里意味着 macOS 是在和它讲 NVMe，而不是通过 USB 大容量存储做隧道传输。

一个重要的限制：绝大多数 USB 外置 SSD 根本不会出现在 SPNVMeDataType 里。 即便硬盘盒里装的是 NVMe 模块，USB 桥接芯片也会把它作为 USB 上的一个 SCSI 设备呈现给 Mac，于是它落到了 SPUSBHostDataType 和 SPStorageDataType 里。它不在 NVMe 列表中，并不代表它有没有被 Trim。那只说明这个方法回答不了这个问题，你需要第二种方法。

挂载时刻日志法

这是对所有格式化为 APFS 的存储都适用的检查方法，无论它是怎么连接的，而这正是 Howard Oakley 的方法。它之所以奏效，是因为 APFS 会在一个特定、可观测的时刻执行它的 Trim。

当一个 APFS 卷宗挂载时，APFS 空间管理器会扫描容器中的空闲块，并为它们发出 Trim。它会把自己做过的事记录到统一日志中，条目以 spaceman_scan_free_blocks 开头。一个被 Trim 过的容器会显示扫描记录以及 trim 活动。一个没有被 Trim 的容器，则会在扫描记录之后显示标记 (no trims)。

这一个字符串就是你的答案。一块刚刚挂载、且有空闲空间的硬盘出现 (no trims)，就意味着 Trim 没有到达这块硬盘。

操作步骤：

1. 正确推出硬盘。在 Finder 中右键选择「推出」，或使用 diskutil eject /dev/diskN。不要直接拔线。
2. 物理断开它。等几秒钟。
3. 记下准确时间。精确到秒，用 Mac 使用的同一个时钟。在终端里输入 date 就能精确拿到。
4. 重新连接硬盘，等待卷宗出现在 Finder 中并完成挂载。给它十到二十秒。
5. 读取连接前后那个时间窗口的日志。

log show --last 2m --predicate 'senderImagePath CONTAINS[c] "apfs"'

Oakley 的谓词是 senderImagePath CONTAINS[c] "apfs"，它能捕获 APFS 代码发出的一切内容，不受子系统命名影响。如果你记下了时间并想要一个更窄的窗口，log show 也接受显式的时间边界：

log show --start "2026-08-15 14:30:00" --end "2026-08-15 14:30:40" --predicate 'senderImagePath CONTAINS[c] "apfs"'

如果这什么都没返回，加上 --info 以包含信息级别的条目，如果还是空的，再加上 --debug。这些参数拓宽的是级别过滤器，而不是改变匹配的内容。

然后在结果中搜索 spaceman_scan_free_blocks，找到指名你这块硬盘设备（disk5、disk6，或者 diskutil list 为它显示的任何编号）的条目，寻找 (no trims) 标记。务必确认磁盘编号与你正在测试的硬盘一致，因为你的启动容器和其他任何已挂载的 APFS 卷宗都会输出它们自己的条目，很容易看错。

为什么开机时长会毁掉这个检查

这里有个陷阱，也是为什么这么多人试过之后得出「日志法没用」这个结论的原因。

APFS 的 Trim 消息只在挂载时输出。 它们不是周期性的。没有每小时的心跳。如果一个卷宗是三周前挂载的且一直保持挂载状态，那它的 Trim 条目就是三周前写的，早就超出日志的保留窗口了。

我们对此做了实测。在一台已开机 21 天的 Mac 上运行：

log show --last 7d --predicate 'senderImagePath CONTAINS[c] "apfs"'

返回了零行。在整整一周的日志里，一条都没有——而这是一台状态完美的机器，内置 SSD 也完全健康，报告的是 TRIM Support: Yes。启动卷宗是在三周前开机时挂载的，落在保留窗口之外，而此后再没有任何东西挂载过。

因此，--last 7d 查询返回空白毫无意义。它既不能证明 Trim 坏了，也不能证明它在工作。它只能证明最近没有任何东西挂载过。只有当你在读取日志之前亲手制造出那个挂载事件，这个检查才会给出答案。拔掉、记时间、插回去，然后读日志。按这个顺序，中间不要拖延。

如果你不想用终端，可以用 Oakley 的工具

Howard Oakley 提供了两个免费工具来封装这套流程。Mints 内置了一个 Disk Mount 功能，可以捕获挂载前后那段时间窗口的日志；LogUI 则是一个通用的统一日志浏览器，让你能通过界面应用同样的谓词。两者都可以从 The Eclectic Light Company 获取。如果你不想手工拼装 log show 调用，它们能做同样的事，而且更不容易把谓词打错。

如何诚实地对读写速度做基准测试

比例测试的价值取决于测量的质量，而大多数随手做的 SSD 跑分产出的数字看起来很让人安心，实际上毫无意义。

为什么刚抹过的硬盘总是看起来很好

如果你抹掉一块硬盘然后立刻跑分，你会得到它的标称速度。每个块都是擦除状态，每次写入都是干净的编程操作，而且在跑分的这点时长里，维持这个状态根本不需要 Trim。这就是为什么「我格式化完立刻跑了个速度测试，一切正常」这句话，对 Trim 是否工作没有任何说明力。你测的恰恰是那个 Trim 无关紧要的状态。

这也是为什么本文后面描述的治疗手段看起来立竿见影，然后在一块仍然没被 Trim 的硬盘上，几个月后又悄悄失效。

要测出有意义的东西，硬盘必须处于 Trim 真正起作用的状态：被大量使用过，背后有真实的写入和删除历史。

构建一个反映真实使用的测试

四个条件让基准测试在这件事上是诚实的。

用大文件。 至少 8 GB，最好超过硬盘的 SLC 缓存容量，在消费级硬盘上这个缓存通常是容量的百分之几。小文件测试测的是元数据处理，会掩盖你真正想看到的闪存行为。

让硬盘装到一半以上。 一块几乎空着的硬盘，无论 Trim 状态如何都有可用的空闲空间。你要找的那个问题，只有在控制器缺少擦除好的块时才会显现。

在一轮大量删除之后测试。 删掉一些大文件，清空废纸篓，然后写入。这正是 Trim 存在的意义所在：文件系统认为已经空闲、而硬盘可能知道也可能不知道已经空闲的那部分空间。

测持续吞吐量，而不是最初那几秒。 每一块现代 SSD 都会把最初的突发写入吸收进快速缓存。观察一次传输三分钟，看它最终稳定在什么水平。

一个粗糙但诚实的命令行测量方法

dd 不用装任何东西就能给你一个数字。先测写入：

dd if=/dev/zero of=/Volumes/YourDrive/speedtest.bin bs=1m count=8192

这会写入 8 GB 的零。完成后，dd 会打印一行汇总，包含传输的字节数、耗时和以字节每秒计的吞吐量。记下这个吞吐量。

然后清空 Mac 的磁盘缓存，好让读取测试真的从硬盘读而不是从内存读，再把文件读回来：

sudo purge
dd if=/Volumes/YourDrive/speedtest.bin of=/dev/null bs=1m

对比这两个吞吐量数字。然后删掉测试文件。

有一点要注意：某些 SSD 控制器会对高度重复的输入做压缩或去重，而全是零的文件是最容易被优化的情况，所以从 /dev/zero 走 dd 可能会美化硬盘的成绩。要避开这一点，改成拷贝一个真实的大文件（比如一段视频）并计时。图形化工具也完全可以。Blackmagic Disk Speed Test 会给出一个连续读数，你可以看着它在几分钟内稳定下来，这让缓存耗尽导致的速度断崖变得一目了然。

解读结果

把写入速度算成同一块硬盘、同一根线、同一个接口、同一次会话下读取速度的百分比。

在 80% 及以上，没什么问题。闪存上写入通常本来就比读取略慢，一直如此。

在 40% 到 80% 之间，你处在模糊地带。这可能是早期的 Trim 问题，可能是缓存耗尽的硬盘，可能是热行为，也可能只是这个型号本来的表现。做一轮大量删除后重测，然后去跑挂载时刻日志检查。

低于 20%，就照 Oakley 说的办，把它当成 Trim 问题。他的措辞是刻意的：在这个比例下「你可以确信存在 Trim 问题」。

文件系统的选择：APFS、HFS+ 和 exFAT 陷阱

你把硬盘格式化成什么文件系统，在任何关于硬件的问题出现之前，就已经决定了 Trim 会不会被尝试。

exFAT 不做 Trim

这是整个问题里最容易避免的那一个原因。Oakley 直截了当地说：「APFS 和 HFS+ 通常会在每次挂载时对 SSD 执行 Trim，而一块格式化成 ExFAT 这类老式 PC 文件系统的硬盘，极不可能被 Trim。」

exFAT 是硬盘出厂预格式化的格式，因为它是 macOS 和 Windows 都能不装额外软件就读写的唯一格式。它也是人们在需要让硬盘在 Mac 和 PC 之间流转时刻意选择的格式。而这意味着这块硬盘永远不会从 macOS 收到一条 Trim 命令，无论它装在什么硬盘盒里，无论它怎么连接，无论任何检查报告了什么。

如果你那块变慢的外置 SSD 是 exFAT，你已经找到答案了，不需要再跑日志检查。它根本不会有任何 APFS 挂载条目，因为没有 APFS 容器可供扫描。

跨平台的取舍

这个取舍是真实存在的，没有免费的答案，所以要明确你在选哪一边。

格式	macOS 上的 Trim	Windows 兼容性	最适合
APFS	是，每次挂载都执行	不原生支持；需要第三方软件	只在 Mac 上用的硬盘、较新 macOS 上的 Time Machine、任何对性能敏感的场景
HFS+（Mac OS 扩展）	是，每次挂载都执行	不原生支持；需要第三方软件	老款 Mac、遗留工作流、必须兼容非常老旧系统的硬盘
exFAT	否	是，原生支持	真正需要跨平台共享、并且你接受性能代价的场景

如果你确实需要一块既能插 Mac 又能插 Windows 电脑的硬盘，exFAT 是务实的选择，而你应该接受它的写入性能会随时间退化这个事实。缓解办法是让硬盘的占用率保持在远低于满容量的水平，并且偶尔重新格式化，而不是从不格式化。但如果跨平台访问只是你「哪天可能想要」而不是「每周都在做」的事，那就格式化成 APFS。文件总可以通过网络传，而一块能保持多年高速的硬盘，胜过一个假想中的便利。

HFS+ 会被 Trim，但已进入倒计时

HFS+ 仍然会被 Trim，也仍然能用。不过在 Mac 上它并不是一个好的长期选择，尤其加密的 HFS+ 已经走在被弃用的路上。如果你正在用一块 HFS+ 外置硬盘，而且本来就在考虑重新格式化，那这是转向 APFS 的好时机。我们那篇关于将加密 HFS+ 宗卷转换为 APFS 的指南涵盖了迁移过程以及对 Time Machine 的影响。

连接方式的选择：USB 桥接芯片 vs Thunderbolt 与 NVMe

文件系统是必要条件但不是充分条件。一块 APFS 硬盘仍然需要让 Trim 命令在物理上抵达闪存控制器，而这就轮到硬盘盒登场了。

桥接芯片必须完成的工作

USB 外置 SSD 并不是一块直接与你的 Mac 对话的硬盘。硬盘盒里有一颗桥接芯片，负责在 USB 与存储模块所讲的协议（SATA 或 NVMe）之间做翻译。macOS 把存储命令以 SCSI 形式通过 USB 发出，通常使用 UASP（USB 附加 SCSI 协议），而 Trim 在 SCSI 中的等价命令是 UNMAP。

所以这条命令必须活着走完一整条链路：APFS 决定执行 Trim，macOS 通过 USB 发出 UNMAP，桥接芯片收到它，桥接芯片把它翻译成 SATA TRIM 或 NVMe Deallocate，存储模块执行它。如果桥接芯片没有实现这层翻译，命令就被丢弃。悄无声息地丢弃。任何地方都不会浮现出一条错误，而这恰恰是它难以诊断的原因，也是为什么日志检查是唯一可靠的判读方式。

普遍被报告的情况——这一点在厂商文档和社区测试中是一致的——是 Trim 在 USB 桥接芯片上的透传并不稳定：有些桥接芯片会把 UNMAP 传过去，很多不会，而且这取决于芯片型号和固件版本，而不是硬盘品牌。Thunderbolt 和原生 NVMe 路径才是可靠的路线，因为中间没有会把命令弄丢的翻译层。再引一次 Oakley 的总结：「所有 Apple 内置 SSD 都享有完整的 Trim 支持，采用 NVMe 接口的第三方外置硬盘理应也是如此。」注意那个「理应」，那是他的原话，而且它承担着诚实的分量。

老式 SATA 硬盘是风险最高的。用 Oakley 的话说：「采用 SATA 接口的较慢硬盘，是最有可能不支持 Trim 的。」如果你的外置盘是塞在 USB 硬盘盒里的 SATA SSD——很多用闲置 2.5 英寸 SSD 攒出来的硬盘都是这样——那它就是风险最高的配置。

Apple 没有发布任何兼容性列表

这一点要说得明明白白，因为它会改变你的选购方式：Apple 没有发布任何关于哪些外置硬盘盒在 macOS 上支持 Trim 的列表。 没有支持文档，没有认证硬件页面，没有任何 API 会为 USB 连接的硬盘报告这一点，「系统信息」里也没有任何标记。Apple 从未对外置存储的 Trim 行为做过任何文档说明。

这意味着，在你购买之前，没有任何权威途径能知道某个硬盘盒是否会透传 Trim。厂商的营销宣传也不是可靠依据，因为大多数硬盘盒厂商在两个方向上都不会提 Trim。唯一的办法就是买回来，格式化成 APFS，然后跑挂载时刻日志检查。

这确实很不令人满意，而任何告诉你某个特定主控芯片在 macOS 上「确定支持」或「确定不支持」Trim 的人，都在主张超出现有证据所能支撑的结论。芯片固件版本各不相同，硬盘盒厂商会在不改型号的情况下更换内部元件，而 macOS 自身的行为也在不同版本间发生过变化。测你自己手上的那块硬盘。

这对选购意味着什么

既然没有兼容性列表，那就优先选择那些不存在翻译问题的配置。Thunderbolt 或 USB4 的 NVMe 硬盘盒把桥接芯片从等式里拿掉了，顺带还能提供高得多的吞吐量。如果你本来就在关注整套配置的连接部分，我们的Thunderbolt 5 扩展坞选购指南介绍了当前这一代硬件的实际表现。

买一块大厂的一体式移动固态硬盘，而不是用硬盘盒加闲置硬盘自己攒，通常风险更低，因为厂商为那个特定的存储模块挑选并验证过桥接芯片。这不是保证，但少了一个变量。

而无论你买了什么，都要在第一周内测试它，趁着退货还容易。格式化成 APFS，拷一些数据进去，删掉一些，推出，重新连接，读日志。两分钟，你就知道了。

治本之法：抹掉并重新格式化

没有任何命令可以按需对硬盘执行 Trim

人们会去找一条「立刻 trim 我的硬盘」的命令，但这条命令并不存在。macOS 没有提供任何面向用户的方式，让你按需向某个卷宗发出 Trim。如前所述，trimforce 切换的是针对 AHCI 连接的第三方硬盘的一项系统策略，在这里不适用。Disk Utility 没有这个功能。diskutil 也没有这个子命令。

你可能会看到有人建议用一个巨大的文件把硬盘填满然后删掉。那没有帮助，而且在一块收不到 Trim 的硬盘上，这么做只会让情况更糟，因为你又写入了更多控制器会认为有效的数据。

Oakley 对于剩下的选项毫不含糊：「唯一的治本手段是彻底重新格式化这块 SSD，看看写入速度是否恢复正常。」

抹掉一块硬盘会从零重建分区图和文件系统。在控制器尊重这个操作的硬盘上，抹除本身就等效于把块归还到空闲状态，硬盘会以满速回来。这就是为什么这个修复是真实有效的。这也是为什么，如果底层的 Trim 通路仍然不通，它就只是临时的——你只是把时钟归了零，并没有修好机制。

先把数据妥善转移出来

抹盘会摧毁硬盘上的一切，所以在你碰 Disk Utility 之前，把所有东西拷出来并验证。不是「拷贝完成了」就算，而是真的从拷贝出来的副本里打开几个文件，包括大文件，确认它们完好无损。这块硬盘的读取仍然很快，所以这一步会进行得很顺利，这算是这个故障模式给你的一点小小的慈悲。

如果这块硬盘上有任何东西是你的唯一副本，先在别处再做一份。有 Trim 问题的硬盘并没有在损坏，也不太可能在抹盘过程中死掉，但你在乎的任何东西都不该只有一份副本。另外，如果这块硬盘是 Time Machine 的备份目标，你即将丢弃你的备份历史：在做决定之前，先读下面的 Time Machine 一节。

执行抹除

用 Disk Utility，并且先改一个默认设置。

打开 Disk Utility，然后选择「显示」→「显示所有设备」。这一步很关键。不这么做的话，Disk Utility 只会显示卷宗，而抹掉一个卷宗会保留容器和分区方案原样。你要抹的是物理设备，也就是侧边栏中带有硬盘型号名称的最顶层条目。

选中那个最顶层的设备，点击「抹掉」，然后设置：

• 方案： GUID 分区图
• 格式： APFS，除非你有明确的理由选 exFAT

不要使用那个对硬盘做多次覆写的安全选项滑块。在 SSD 上它很慢，会毫无益处地写入海量数据，而且它恰恰在对抗你正试图恢复的那个块状态。

如果你更喜欢命令行，等价的做法是：

diskutil list
diskutil eraseDisk APFS DriveName GPT /dev/diskN

先运行 diskutil list 并仔细阅读输出来确认正确的设备。对错误的 diskN 执行 eraseDisk 会毁掉错误的硬盘，而且没有任何确认提示。

之后该期待什么

立刻跑分，它会很快。这只能证明闪存是健康的，别的什么都证明不了。

真正的考验在接下来的几个月。把数据拷回去，正常使用，六到八周之后再跑一次比例测试——那时硬盘已经经历了真实的删除与重写周期。如果写入速度稳得住，Trim 大概率是能到达这块硬盘的，那这次只是个偶发事件。如果它沿着同样的曲线再次退化，那就是硬盘盒没有透传 Trim，而重新格式化就成了你要周期性执行的维护，而不是一次修复。

到那个时候，决策就变成了经济问题。对一块能在一小时内重建的临时盘来说，周期性重新格式化是可以忍受的。对一个正在使用的资料库来说则不然。如果这块硬盘很重要，把硬盘盒换成 Thunderbolt 或 NVMe 型号并测试那条路径，才是持久的答案。

预防：让硬盘不要陷入这种状态

留出余量

这是最有效的一个习惯。一块占用保持在 70% 以下的硬盘，即使没有 Trim，控制器手里也还有可用的空闲逻辑空间，因为那些从未被写过的块仍然处于擦除状态。而一块被塞到 98% 满的硬盘，基本上每一个块都被碰过了，一点余量都没有。

这对内置存储也同样适用，启动 SSD 受同样的物理规律支配，只不过在那里 Trim 是确定在工作的。我们的存储管理指南介绍了如何在一台快被塞满的 Mac 上查找并回收空间。

避免「填满到底」的工作流

有些习惯对硬盘的伤害远大于其他习惯。用摄像素材把硬盘填满、全部导出、再重新填满，是最糟糕的情况：被碰过的块最多、对 Trim 的依赖最重、还无限重复。影视从业者遇到这种故障模式的时间远早于普通用户，而且常常以为硬盘在磨损老化，其实并没有。

如果这描述的正是你的工作，那就要么用一块你已经验证过能透传 Trim 的硬盘，要么在项目之间安排一次重新格式化。轮换使用两块硬盘、每次导出后各自重新格式化，是一种合理的工作模式，代价不过是每个项目一次抹盘。

有意识地选择硬盘盒

作为预防措施而不是诊断手段，这一点值得重申：决定这件事的是硬盘盒，不是里面的 SSD 模块，也不是盒子上的品牌。在工作量值得的地方选择 Thunderbolt 或原生 NVMe，并且无论选了什么都在第一周内测试它。

偶尔重测

挂载时刻日志检查只需要两分钟。每年对你重要的外置硬盘跑一次，或者在每次 macOS 大版本升级之后跑一次，能在行为变化让你付出一个月的慢速传输代价之前把它抓出来。把结果记在什么地方。知道某块硬盘在三月份测下来是干净的，到了十二月就是有用的背景信息。

Time Machine 备份目标与可引导克隆盘

为什么 Time Machine 是最糟糕的情况

Time Machine 的备份目标几乎就是 Trim 的最大压力场景。它按设计会不断填向满容量，然后开始删除最旧的快照来腾地方，然后又向腾出来的空间里写入，如此循环，永不停歇。那是一个大量删除紧接着大量写入的持续循环，而这恰恰是最依赖 Trim 来保持速度的模式。

在一块收不到 Trim 的 SSD 备份盘上，备份会在几个月内变得越来越慢。人们报告的症状是，Time Machine 备份过去几分钟就能完成，现在要跑几个小时，或者在「正在准备备份」阶段或写入过程中像是卡住了。这很容易被归咎于 Time Machine，而 Time Machine 本身也确实有大量值得单独排除的真实问题，我们的Time Machine 故障排查指南对此有详细介绍。但如果备份目标是一块 SSD，而且从它读取仍然很快、写入却像爬一样，那就先考虑 Trim，再去花一个下午折腾 Time Machine 自己的设置。

麻烦之处在于，抹掉一个 Time Machine 备份目标会摧毁你的备份历史。没有办法既重新格式化硬盘又保留它的快照。你的选择要么是接受历史的丢失并开始一份全新的备份，要么是在另一块硬盘上建立新的备份目标，等新备份稳定之后再把旧盘退役。对大多数人来说，第二种方案值得一块硬盘的钱，因为没有历史的备份，其价值远低于一份带有数月版本记录的备份。

关于备份硬件选择的一点补充：这是机械硬盘并不算坏答案的少数场景之一。机械盘没有擦除块问题，也完全不需要 Trim。它们纸面上更慢，但对于一次通宵的增量备份来说这往往无关紧要，而且它们的表现不会因为多年的填满-删除循环而退化。

可引导克隆盘与外置启动宗卷

可引导克隆盘的行为类似。克隆软件每次运行都会重写大量数据，所以如果目标盘没有被 Trim，克隆时间会稳步攀升。这里有一个好处：克隆目标盘会被频繁地挂载和卸载，这让挂载时刻的日志条目极其容易生成——推出、重新连接、读日志，一分钟不到就能搞定。

如果你是把 macOS 从外置硬盘启动作为日常工作环境，而不是只作为恢复工具，那风险就更高了，因为每一次系统写入都要走那条退化的路径。这是一个强有力的理由，说明启动盘尤其应该选 Thunderbolt NVMe 硬盘盒而不是 USB 硬盘盒。

常见问题排查

日志检查什么都没返回

问题： 你用 APFS 谓词运行 log show，得到零行，尽管硬盘是连着的。

解决方案： 你几乎可以肯定是在没有先制造挂载事件的情况下读了日志，或者读得太晚了。这些条目只在卷宗挂载时写入。推出硬盘，物理断开它，用 date 记下时间，重新连接，等十五秒让卷宗出现在 Finder 中，然后才运行 log show --last 2m。如果还是空的，加上 --info，然后再加 --debug 来拓宽级别过滤器。如果依然是空的而硬盘确实挂载了，检查这块硬盘是不是真的是 APFS：exFAT 硬盘不会产生任何 APFS 条目，因为没有 APFS 容器可供扫描。

system_profiler SPSerialATADataType 什么都不打印

问题： 每个网站都推荐的这条 Trim 检查没有任何输出，而你无法判断这是否意味着 Trim 关闭了。

解决方案： 两者都不意味着。在 Apple 芯片 Mac 上，这个数据类型根本不存在。用 system_profiler -listDataTypes | grep -i sata 确认，它同样什么都不会返回。内置硬盘和 NVMe 硬盘用 system_profiler SPNVMeDataType，其他一切用挂载时刻日志法。在这些机器上，对那个空的 SATA 结果做任何解读都是没有意义的。

你运行了 sudo trimforce enable，但什么都没变

问题： 你启用了 trimforce，按指示重启了，外置硬盘和之前一样慢。

解决方案： 这就是预期结果。按照它自己的手册页所说，trimforce 影响的是连接到 AHCI（SATA）控制器的第三方硬盘，而你的 USB 或 NVMe 外置盘不属于这一类。运行它既没破坏什么，也没修好什么。如果你想要确认，自己运行 man trimforce 读一遍 DESCRIPTION。接下来去做挂载时刻日志检查，找出真正在发生什么。

硬盘显示 TRIM Support: Yes，但写入仍然很慢

问题： system_profiler SPNVMeDataType 报告这块硬盘支持 Trim，可写入性能依旧糟糕。

解决方案： 报告支持 Trim，意味着硬盘和这条通路宣称具备这项能力。它并不能确认这个卷宗上真的在发生 trim，而后者正是挂载时刻日志检查所测量的东西。接下来去跑那个检查。同时也排除非 Trim 的原因：在「系统信息」中核实协商到的链路速度、换线、换个接口测试，并跑一次持续三分钟的传输，看看你面对的是缓存耗尽或过热降频，而不是块饥饿。

前三十秒速度正常，然后崩塌

问题： 大文件拷贝以满速开始，然后在中途每次都下降 70% 以上。

解决方案： 这通常是 SLC 写入缓存被填满，而不是 Trim 问题，在消费级硬盘上这是正常行为——不过一块 Trim 饥饿的硬盘在下降之后的地板值会更低。区分方法是在硬盘通电空闲一段时间后再测试：缓存导致的减速会在硬盘有时间刷盘之后恢复，Trim 饥饿则不会。另外也检查一下硬盘盒的温度，因为过热的桥接芯片或 NVMe 模块会大幅降频，从外部感受起来和前者一模一样。

小文件慢，大文件快

问题： 拷贝一个装着上千个小文件的文件夹，比拷贝一个同样总大小的单个文件慢得多。

解决方案： 这不是 Trim 问题。小文件传输中每个文件的固定开销占主导，而 Spotlight 索引或安全软件对每个落盘文件的扫描会让情况急剧恶化。用单个大文件测试以获得干净的吞吐量数字。如果大文件写入是正常的，那闪存没问题。要降低小文件的开销，可以考虑在「系统设置」→「Siri 与 Spotlight」→「Spotlight 隐私」中把这块硬盘排除在 Spotlight 之外，或者把文件夹打包成单个归档文件再传输。

抹盘修好了，但只管用了几个月

问题： 重新格式化恢复了满速，而几个月后的现在，写入又沿着同样的曲线退化了。

解决方案： 重新格式化治的是症状。复发说明 Trim 确实没有到达这块硬盘，所以只要你重新积累起写入和删除的历史，块池就会再次饥饿。在重新格式化后的硬盘上用挂载时刻日志检查确认，寻找 (no trims)。如果确认了，你现实的选择是把周期性重新格式化当作维护接受下来，或者把 SSD 模块移到 Thunderbolt 或 NVMe 硬盘盒里并测试那条路径。没有任何软件设置能改变这个结果。

硬盘还会随机断连

问题： 除了写入慢之外，硬盘还会自己弹出，或者你反复收到「磁盘未正常推出」的通知。

解决方案： 把它们当作两个独立的故障，并且先解决断连，因为不稳定的连接会让每一次测量都不可靠，还可能在写入中途损坏宗卷。断连通常是供电或总线问题而不是闪存问题：接在集线器上的总线供电硬盘、过于激进的硬盘盒休眠策略，或者一根勉强能用的线。我们的「磁盘未正常推出」错误与 USB 供电指南介绍了具体原因。等硬盘能稳定连接之后，再回来重做比例测试。

常见问答

sudo trimforce enable 对外置 USB SSD 有帮助吗？

没有。它的手册页写明，它为连接到 AHCI 控制器的第三方硬盘启用 Trim，也就是 SATA 接口。USB 外置硬盘通过一颗 USB 桥接芯片接入 Mac，而 NVMe 硬盘也不是 AHCI。这条命令适用于装在老款 Mac 内部的第三方 SATA SSD，仅此而已。

为什么 system_profiler SPSerialATADataType 在我的 Mac 上什么都不返回？

因为 Apple 芯片 Mac 没有 SATA 控制器，所以这个数据类型在它们上面不存在。你可以自己用 system_profiler -listDataTypes | grep -i sata 确认，它没有任何匹配。空输出并不是「Trim 已禁用」的报告，而是整个硬件类别的缺席。

我能在 Disk Utility 里或用 diskutil 检查 Trim 状态吗？

不能。diskutil info -all | grep -i trim 什么都不返回，因为 diskutil 在它报告的属性中不暴露 Trim 状态，Disk Utility 的信息面板里也没有。任何暗示可以这么做的指南，描述的都是 macOS 并不提供的东西。改用 system_profiler SPNVMeDataType 或挂载时刻日志检查。

我怎么区分 Trim 问题和一根坏线？

在同一次会话中，用一个至少 8 GB 的文件，对比同一块硬盘的读取速度和写入速度。线材或接口问题会以相近的倍数拖慢两个方向。Trim 问题则让读取保持满速，而写入崩塌。Howard Oakley 的阈值是写入为读取的 20% 或更低。

抹掉硬盘能永久解决写入慢的问题吗？

它会立刻恢复满速，因为抹除让闪存回到了写入无需先擦除的状态。能维持多久，取决于日常使用中 Trim 是否能到达这块硬盘。如果能，问题应该不会再出现。如果不能，几个月内就会重现同样的退化。

exFAT 对 Mac 上的外置 SSD 真的那么糟糕吗？

就长期性能而言，是的。exFAT 不会对硬盘执行 Trim，所以一块 exFAT 的 SSD 必然会随着写入历史的积累而退化，无论用什么硬盘盒、什么连接方式。只在你确实需要原生 Windows 访问时才选 exFAT，如果选了，就让硬盘的占用率保持在远低于满容量的水平，并周期性地重新格式化。

结论

一块读取满速、写入却很慢的外置 SSD，在你运行任何命令之前就已经告诉你哪里出了问题。那种不对称，就是一块耗尽了预擦除块、又没人告诉它哪些块可以回收的硬盘留下的指纹。

这件事难以诊断，原因并不在于机制有多微妙，而在于互联网达成共识的那两个检查在现代 Mac 上都会静默失效。system_profiler SPSerialATADataType 查询的是 Apple 芯片并不具备的一个硬件类别，返回空结果。sudo trimforce enable 切换的是针对 AHCI 连接的 SATA 硬盘的一项策略，碰不到 USB 外置盘——它自己的手册页在第一段就是这么写的。两者都不报错。正是这份沉默让错误建议一直流传，也是我们自己在早先的一篇指南里重复了它的原因。

真正管用的方法要窄得多。对于内置硬盘和 NVMe 外置盘，system_profiler SPNVMeDataType 会直接报告 TRIM Support。对于任何格式化为 APFS 的存储，推出硬盘、记下时间、重新连接、等它挂载，然后在统一日志中读取 spaceman_scan_free_blocks 条目，寻找 (no trims) 标记。要按这个顺序做，中间不要拖延，因为那些条目只在挂载时写入，别处都没有。在我们实测的那台已开机三周的机器上，整整一周的日志里一条都没有。

如果检查结果不妙，治本之法就是彻底抹掉并重新格式化，没有任何面向用户的命令可以替代它。这个修复能不能持久，取决于硬盘盒，而既然 Apple 没有为外置硬盘盒的 Trim 支持发布任何兼容性列表，唯一的验证办法就是重新格式化、正常使用两个月，然后再测一次。如果它沿着同样的曲线退化，那就是硬盘盒在丢弃这条命令，而持久的答案是换到 Thunderbolt 或原生 NVMe 的通路上，而不是你能在软件里做的任何改动。

这一周做三件事。用一个大文件在两个方向上，对你的主力外置硬盘做一次比例测试。如果比例看起来不对，趁硬盘还处在退化状态时跑一次挂载时刻日志检查，这样你才能学到东西，而不只是把它修好。以及，把你只在 Mac 上用的外置硬盘格式化成 APFS 而不是 exFAT，因为这一个决定就决定了 Trim 会不会被尝试。

延伸阅读：macOS 外置 SSD 故障排查指南 · Time Machine 完整故障排查指南