MemoryMappedFile 不能直接解析 XML，因 MemoryMappedViewStream 默认不支持 Seek；正确做法是分块映射+ByteArrayStream+XmlReader 流式处理，并确保 x64 进程与真实编码匹配。
MemoryMappedFile 不能直接解析 XML
直接用 MemoryMappedFile 加载超大 XML 文件后调用 XDocument.Load() 或 XmlReader.Create() 会失败——因为这些 API 要求流支持 Seek，而内存映射视图（MemoryMappedViewStream）默认不支持随机读写（尤其只读映射时 CanSeek 为 false）。这不是权限或路径问题，是设计限制。
正确思路是：用 MemoryMappedFile 做底层数据承载，再配合流式 XML 解析器手动切片读取。
- 只映射文件的一部分（如前 64MB），避免一次性占用过多虚拟内存
- 用
MemoryMappedViewAccessor定位到某个起始标签位置（例如Seek的子流（需自行封装） - 更稳妥的做法是：把映射区域复制进
ByteArrayStream，再喂给XmlReader——虽有拷贝开销，但稳定可控
分块读取 + XmlReader 流式处理是可行路径
适用于 GB 级、结构清晰的 XML（如日志列表、批量订单），前提是根元素下是同构子节点（
关键步骤：
- 先用
FileStream快速扫描文件，记录每个Span查找 ASCII 字节序列.IndexOf ） - 用
MemoryMappedFile.CreateFromFile(path, FileMode.Read, null, 0, MemoryMappedFileAccess.Read)打开全文件（不指定大小，系统自动按需分页） - 对每个偏移，调用
map.CreateViewAccessor(offset, length)得到局部视图，再用view.ReadArray(0, buffer, 0, buffer.Length)拷出一段字节 - 将
buffer包装为new MemoryStream(buffer)，传给XmlReader.Create(stream, new XmlReaderSettings { DtdProcessing = DtdProcessing.Ignore })
var offsets = new List(); using (var fs = File.OpenRead("huge.xml")) { Span buf = stackalloc byte[8192]; long pos = 0; while (fs.Read(buf) > 0) { int idx = buf.IndexOf(stackalloc byte[] { (byte)'<', (byte)'e', (byte)'n', (byte)'t', (byte)'r', (byte)'y', (byte)'>' }); if (idx != -1) offsets.Add(pos + idx); pos += buf.Length; } }
注意 Encoding 和 BOM 导致的解析失败
XML 声明如 中的 encoding 属性必须与实际字节编码一致，否则 XmlReader 会抛 XmlException：“Data at the root level is invalid”。内存映射本身不处理编码转换，所有字节原样暴露。
- 务必先读取文件开头若干字节，检测 BOM：
EF BB BF→ UTF-8，FF FE→ UTF-16 LE，FE FF→ UTF-16 BE - 如果 XML 声明里写的是
encoding="UTF-8"，但实际含 BOM 或是 UTF-16 编码，XmlReader会按声明硬解，必然乱码或报错 - 安全做法：忽略 XML 声明，强制用检测出的真实编码创建
StreamReader，再包装成XmlReader
64 位进程 + LargeAddressAware 是硬性前提
32 位 .NET 进程用户空间仅 2GB（开启 /LARGEADDRESSAWARE 最多 3GB），而 4GB XML 文件映射后至少需要等量虚拟地址空间。即使物理内存充足，也会在 CreateFromFile 时抛 IOException：“Not enough storage is available to process this command”。
- 确认项目属性中
PlatformTarget设为x64（不是AnyCPU） - 检查生成的 exe 是否带
LARGEADDRESSAWARE标志：dumpbin /headers YourApp.exe | findstr "large" - Windows Server 上可启用
4GT，但不如直接切 x64 彻底
真正卡住多数人的不是代码逻辑，而是进程位数和地址空间这层透明屏障。
