file.readallbytes 会劣化 cpu 缓存表现，因其一次性将整个文件加载至托管堆，导致大量缓存行被挤出；它无缓冲控制、引发 loh 压力，且访问局部性差。
File.ReadAllBytes 为什么会让 CPU 缓存表现变差
它会一次性把整个文件加载进托管堆，不管文件多大。CPU 缓存（尤其是 L1/L2）根本装不下几 MB 的连续数据，结果就是大量缓存行被挤出，后续对同一块内存的访问反而频繁 miss。
- 典型场景：读取 50MB 日志后立刻解析前 1KB——实际只用到开头，但整块内存都进了缓存又很快被淘汰
- 参数无缓冲控制：
File.ReadAllBytes没有提供缓冲区大小或流式读取选项，底层调用FileStream.Read时默认使用 0x1000（4KB）内部缓冲，但用户无法干预 - 更糟的是 GC 压力：大 byte[] 分配在 LOH（大对象堆），不参与常规 GC，长期驻留会间接污染 CPU 缓存局部性
FileStream 构造时设置 bufferSize=4096 是不是就够了
不够。bufferSize 只影响 FileStream 内部读写缓冲，和 CPU 缓存行（通常是 64 字节）没有直接映射关系。设成 4096 只是减少系统调用次数，不代表缓存友好。
- 真实瓶颈常在「访问模式」：比如用
stream.Seek随机跳转 + 小块读取，会导致 CPU 预取器失效，缓存行反复载入丢弃 - Windows 上默认
FileOptions.None会禁用系统级缓存（FILE_FLAG_NO_BUFFERING不启用），但 .NET 的FileStream仍走内核缓存，和 CPU 缓存是两层事 - 若真想对齐 CPU 缓存行，需手动按 64 字节对齐分配（如
Marshal.AllocHGlobal+MemoryAlignment），但绝大多数文件 IO 场景没必要，反而增加复杂度
MemoryMappedFile 能绕过 CPU 缓存问题吗
不能绕过，但能改变缓存压力来源。内存映射本身不跳过 CPU 缓存，而是把文件页交由 OS 页面调度，CPU 仍按需加载缓存行；但它避免了托管堆拷贝，减少了 LOH 占用和 GC 干扰。
- 适用场景：超大文件（>1GB）且需随机访问——比如数据库索引扫描，此时 CPU 缓存命中率本就不高，重点反而是减少内存拷贝开销
- 注意
CreateFromFile默认用FileOptions.RandomAccess，会提示 OS 使用更适合随机读的预取策略，间接提升缓存效率 - 坑点：映射视图（
MemoryMappedViewAccessor）读写仍受 CPU 缓存一致性协议约束，多线程并发修改同一缓存行会引发 false sharing
BufferedStream 包一层 FileStream 有用吗
基本没用，甚至有害。.NET 6+ 的 FileStream 已内置高效缓冲，再套 BufferedStream 只是多一层托管对象和虚方法调用，还可能破坏底层的异步 I/O 路径优化。
- 错误现象：
new BufferedStream(new FileStream(...))导致吞吐下降 5–10%，尤其在 SSD 上更明显 -
FileStream的缓冲逻辑已针对现代存储优化：小读用内联缓冲，大读走 direct I/O 路径，而BufferedStream强制统一走托管缓冲 - 唯一例外：需要自定义缓冲策略（比如固定复用某段
byte[]避免反复分配），但这时应直接操作FileStream.Read(Span<byte>)</byte>+ 手动管理 buffer
真正影响 CPU 缓存命中的，从来不是「用哪个 API」，而是你每次读多少、隔多久读、是否顺序访问。别迷信某个类名带 Buffer 就缓存友好——64 字节的 CPU 缓存行可不管你是从 FileStream 还是 MemoryMappedFile 里拿的数据。
