分块读取大文件时需用fileshare.read共享模式避免冲突，按字节偏移对齐行边界确保完整行读取，cpu密集型用parallel.foreach，io密集型用task.run，超大文件可选memorymappedfile但需注意跨平台和行边界处理。
分块读取大文件时，FileStream 必须用 FileShare.Read
直接用多个线程各自 new FileStream(path, FileMode.Open) 会抛 IOException: The process cannot access the file because it is being used by another process.。根本原因是默认打开模式不允许多个句柄同时读——哪怕只是只读。
正确做法是每个线程都独立打开文件，但显式指定共享模式：
using var fs = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read, 4096, FileOptions.SequentialScan);
注意几点：
-
FileShare.Read是关键，缺了就必然冲突 -
FileOptions.SequentialScan可提升大文件顺序读性能（内核会优化预读） - 缓冲区大小（如
4096）设为页对齐值（4KB/8KB）更稳妥，避免小缓冲导致频繁系统调用
分片不能按行切，得按字节偏移 + 完整行边界对齐
按固定字节数（如每段 10MB）硬切，大概率在行中间断开，后续解析会出错。必须保证每片起始位置是某行开头、结束位置是某行末尾（含 \n 或 \r\n）。
实操步骤：
- 主线程先获取总长度
fs.Length，计算理论分片起始偏移（如start = i * chunkSize） - 每个工作线程打开文件后，先
fs.Seek(start, SeekOrigin.Begin) - 若
start > 0，向后找第一个换行符，把指针移到下一行开头（跳过被截断的半行） - 从新起点开始读，直到达到目标字节数或遇到换行符后超出——此时停止，确保最后一行完整
别依赖 StreamReader.ReadLine() 做边界控制：它内部缓冲不可控，跨线程复用流易错乱。纯 FileStream.Read() + 手动查 \n 更可靠。
并行处理用 Parallel.ForEach 还是 Task.Run？看 IO 密集度
如果分片后要做的主要是 CPU 计算（如解析 JSON、统计词频），用 Parallel.ForEach(partitions, ...) 简洁高效；但如果涉及磁盘写、网络请求等 IO 操作，强行用 Parallel.ForEach 会阻塞线程池线程，拖慢整体吞吐。
更合理的分法：
- CPU 密集型任务 →
Parallel.ForEach，配ParallelOptions.MaxDegreeOfParallelism = Environment.ProcessorCount - 混合型（如读完解析再写 DB）→ 用
Task.Run包裹整个分片逻辑，由 .NET 线程池自动调度，避免死锁风险 - 千万别在
Parallel.ForEach里 await 异步操作——它不支持 async lambda，会卡死或静默失败
内存映射（MemoryMappedFile）适合超大文件但有陷阱
当文件远超物理内存（如 50GB+），FileStream 分块读仍可能触发频繁 GC 和内存抖动。此时可考虑 MemoryMappedFile，让 OS 负责页面调度。
但要注意：
- Windows 上需用
MemoryMappedFile.CreateFromFile(path, FileMode.Open, null, length, MemoryMappedFileAccess.Read)，length必须精确，不能传0（否则映射失败） - 每个线程需调用
mmf.CreateViewAccessor(offset, size)创建独立视图，不能复用同一MemoryMappedViewAccessor - 映射区域仍需手动处理行边界——和流式读一样，不能直接按字节切
- Linux/macOS 对
MemoryMappedFile支持有限，跨平台项目慎用
真正省事的边界处理，还是得靠预扫描 + 偏移校准，无论底层用流还是映射。
