为何Apple SSD读取吞吐量基准测试结果偏高？如何优化准确性？

一、Apple SSD AP1024N的真实性能与通道规格 #

2019款16英寸MacBook Pro搭载的AP1024N确实是PCIe 3.0 x4通道。厂商标称的2.8GB/s是持续读取的保守典型值，但实际测试中，SSD在空盘、文件连续分布的情况下，瞬时读取速度完全可能超过标称值——因为厂商标称通常留有余量，而且SSD的SLC缓存未耗尽前，读取速度会远高于持续写入后的稳态速度。哪怕你用了32GB的测试文件，如果文件是连续写入的，前一段数据大概率还在SLC缓存覆盖范围内，这部分的读取速度会远超标称值。

二、你的基准测试可能高估吞吐量的原因 #

• 系统缓存没完全绕开：虽然文件大小32GB超过了16GB内存，但macOS的缓存机制会搞“部分缓存”或者预读取——系统会提前把后续要读的部分数据载入内存，甚至通过置换其他内存页来缓存文件片段，导致实际测试时不少数据是从内存读的，而非磁盘。
• 同步Read的系统优化干扰：你用的FileStream.Read是同步方法，在macOS上，.NET的文件IO会利用内核级预读取优化，统计出来的吞吐量可能包含了预读取的缓存数据，不是纯磁盘读取的真实速度。
• 吞吐量计算可能有误：得确认你统计时间的范围对不对——是不是从开始读取到最后一个字节读完的总时长，有没有排除文件打开、缓冲区分配这些前置耗时？如果时间统计错了，吞吐量肯定算不准。
• 多线程测试的缓存放大效应：多线程读同一个文件时，系统会更高效地把文件数据缓存到内存，甚至合并多个线程的IO请求，实际磁盘的并发IO量没你想的那么高，大部分吞吐量其实是内存缓存贡献的，不是SSD本身的并发能力。

三、提升测试准确性的具体办法 #

• 强制绕过系统缓存：创建FileStream时，加上FileOptions.NoBuffering和FileOptions.SequentialScan参数（注意：NoBuffering要求缓冲区大小是磁盘扇区的整数倍，一般是4KB），直接读取磁盘数据，示例代码：

using var stream = new FileStream("testfile.bin", FileMode.Open, FileAccess.Read, FileShare.None, 4096, FileOptions.SequentialScan | FileOptions.NoBuffering);

• 让测试文件非连续：可以通过多次写入小文件再合并，或者用工具生成碎片化的大文件，避免SSD的连续块读取优化和SLC缓存影响结果。
• 清空缓存后重复测试：先跑一次完整读取让系统缓存加载数据，然后用macOS命令sync && sudo purge清空缓存，再做正式测试，重复多次取平均值。
• 用异步IO并精准计时：换成FileStream.ReadAsync做异步读取，确保时间统计从第一个IO请求发起开始，到最后一个IO完成结束，排除其他操作的干扰。
• 用系统工具验证真实IO：测试时打开macOS的Activity Monitor（磁盘标签）或者用iostat命令，实时看磁盘的实际读取速度，和你的测试结果对比，就能确认是不是缓存搞的鬼。

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