RandomAccess.WriteAsync不是真正的异步，因其依赖操作系统异步I/O支持：Windows需FILE_FLAG_OVERLAPPED（即FileOptions.Asynchronous），否则回退线程池同步；Linux需io_uring（内核≥5.1）；不满足则阻塞线程池。
RandomAccess.WriteAsync 为什么不是真正的异步？
RandomAccess.WriteAsync 和 RandomAccess.ReadAsync 在 .NET 6+ 中名义上是异步方法，但底层依赖操作系统是否支持真正的异步文件 I/O（即 I/O Completion Ports on Windows，或 io_uring on Linux）。Windows 上对普通 NTFS 文件句柄调用这些方法时，仍可能回退到线程池同步模拟——尤其是当文件未以 FILE_FLAG_OVERLAPPED 打开时。
这意味着：即使你写了 await RandomAccess.WriteAsync(...)，它仍可能阻塞线程池线程，无法实现高吞吐低延迟的异步语义。
- 必须用
FileOptions.Asynchronous打开文件（否则 Windows 内核不启用重叠 I/O） - Linux 上需确认内核 >= 5.1 并启用
io_uring（.NET 6+ 默认尝试使用，但失败会静默降级） - 不能对
Console.OpenStandardOutput()或内存映射文件视图调用它——会抛NotSupportedException
如何正确打开支持异步 RandomAccess 的文件句柄？
关键不在 RandomAccess 本身，而在文件句柄的创建方式。.NET 没有公开 CreateFile 的完整参数封装，所以得绕过 FileStream，直接用 SafeFileHandle 构造：
var handle = File.OpenHandle(
"data.bin",
FileMode.OpenOrCreate,
FileAccess.ReadWrite,
FileShare.None,
FileOptions.Asynchronous // ← 必须！否则 RandomAccess.*Async 无意义
);
注意：FileOptions.Asynchronous 是唯一能触发 Windows 重叠 I/O 的开关；漏掉它，后续所有 RandomAccess 调用都会同步执行。
-
File.Create("...")或new FileStream(...)默认不带该 flag，不能直接传给RandomAccess - 如果要用
MemoryMappedFile配合随机访问，需确保映射时用MemoryMappedFileOptions.DelayAllocatePages，且底层句柄已启用异步 - 关闭时务必调用
handle.Dispose()，否则句柄泄漏（RandomAccess不持有所有权）
RandomAccess.ReadAsync 实际读取时要注意什么偏移和长度？
RandomAccess.ReadAsync 不维护文件指针，每次都要显式指定 offset，且 offset 必须对齐到磁盘扇区边界（通常是 512 字节），否则在某些文件系统或硬件上会失败或性能骤降。
常见错误是把 offset 当成数组下标随意设为任意整数——比如从 100 字节处开始读 1024 字节，可能触发同步回退甚至 IOException。
- 建议始终用
offset % 512 == 0校验（NTFS / exFAT 下安全） -
buffer必须是ArrayPool<byte>.Shared.Rent()</byte>或 pinnedMemory<byte>，不能是普通托管数组（否则 GC 可能移动内存导致 I/O 错误） - 返回值是实际读取字节数，可能小于请求长度（如到达 EOF），需检查返回值而非假设填满
比 RandomAccess 更可控的异步替代方案是什么？
如果你发现 RandomAccess 行为不稳定、难调试，或者需要跨平台一致表现，更推荐组合使用 FileStream + MemoryMappedFile + ValueTask 封装：
using var fs = new FileStream("data.bin", FileMode.Open, FileAccess.Read, FileShare.None, 4096, FileOptions.Asynchronous);
await fs.ReadAsync(buffer, offset, cancellationToken); // ← 这个 offset 是流内偏移，不是文件绝对偏移
虽然 FileStream.ReadAsync 看似“不够底层”，但它内部做了缓冲、对齐、异常归一化，并且在 .NET 6+ 中已深度优化——实测吞吐常优于裸 RandomAccess，尤其在小块、随机跳读场景。
真正需要 RandomAccess 的场合其实很窄：比如实现自定义日志索引跳转、零拷贝数据库页加载、或与 native code 共享同一句柄做异步协作。其他情况，先用 FileStream，再测瓶颈，别过早优化。
