跨框架文件操作最稳方案是：坚持使用File、Directory、Path等基础类，避开Span等新API；路径用Path.Combine；FileStream必须显式指定useAsync；文件存在性校验用try/catch而非File.Exists；目标框架应明确声明net472;net8.0并双环境测试。
用 System.IO 基础类写跨框架代码最稳
只要不碰 Span<byte></byte>、MemoryStream.TryGetBuffer 这类 .NET Core 2.1+ 才有的 API，File、Directory、Path、FileInfo 等老面孔在 .NET Framework 4.6.1+ 和 .NET 8 上行为一致。微软没动过这些类型的公开契约，连异常类型（比如 UnauthorizedAccessException）都保持统一。
实操建议：
- 优先用
File.ReadAllText而非File.ReadAllLines+string.Join拼接——后者在大文件下多一次内存拷贝，且在 .NET Framework 中可能触发更早的 GC 压力 - 避免用
File.Replace：它在 .NET Framework 中不支持ignoreMetadataErrors参数，在 .NET 8 中默认为false，但语义上不完全等价；改用File.Move+File.Delete组合更可控 - 路径拼接一律走
Path.Combine，别用+或string.Format——Path.Combine在不同框架下对空段、斜杠冗余的处理逻辑一致，而字符串拼接在 Linux 容器里跑 .NET 8 时容易漏掉/
异步文件操作必须查清 FileStream 构造参数
.NET Framework 的 FileStream 默认不支持 async，除非显式传入 useAsync: true；而 .NET 8 默认启用异步 I/O（即使你没写这个参数）。混用会导致：在 Framework 下 await fileStream.ReadAsync 实际走同步模拟，线程池被占满；在 .NET 8 下则真异步，但若底层文件系统不支持（如某些网络映射驱动），反而抛 NotSupportedException。
实操建议：
- 所有
new FileStream调用必须显式指定useAsync参数，值设为true（Framework 需要）或false（仅调试时临时禁用） - 别依赖
File.OpenRead的返回值做异步读——它返回的FileStream在 Framework 下CanRead为true，但CanSeek可能为false，导致CopyToAsync失败；直接 new 更透明 - 如果项目目标是 .NET Standard 2.0，就别碰
FileStreamOptions——它是 .NET 5+ 引入的，Framework 完全不认识这个类型
判断文件是否存在别只靠 File.Exists
File.Exists 在 .NET Framework 和 .NET 8 上都返回 bool，看似安全，但背后逻辑不同：Framework 会检查 ACL 权限，遇到无权限目录直接返回 false；.NET 8 则尝试 stat 系统调用，权限不足时抛 UnauthorizedAccessException。结果就是同一段代码，在 Framework 下静默跳过，在 .NET 8 下崩掉。
实操建议：
- 凡涉及路径校验，统一用
try/catch包住new FileInfo(path)或File.GetAttributes，捕获UnauthorizedAccessException和DirectoryNotFoundException，再按需处理 - 不要把
File.Exists当“前置守卫”——它和后续操作之间存在竞态窗口（文件可能被删/重命名），真正安全的做法是直接操作，再捕获FileNotFoundException - 若需区分“不存在”和“无权限”，Framework 下可先
Directory.GetAccessControl检查父目录，.NET 8 下可用FileSystemAclExtensions（需 NuGet 引入Microsoft.Win32.Registry，仅 Windows 有效）
目标框架选 netstandard2.0 不等于万事大吉
netstandard2.0 确实能被 .NET Framework 4.6.1+ 和 .NET 8 同时消费，但它不保证运行时行为一致。比如 File.Copy 的覆盖策略：Framework 默认不允许覆盖只读文件，.NET 8 默认允许——这跟标准无关，是运行时实现差异。
实操建议：
- 在
.csproj中明确写<targetframeworks>net472;net8.0</targetframeworks>，而不是只写netstandard2.0；CI 流水线必须双平台跑单元测试 - 所有涉及文件属性（只读、隐藏）的操作，先用
File.GetAttributes读取，再按需用File.SetAttributes修改，别假设默认状态 - 别用
Environment.GetFolderPath返回路径直接拼文件名——ApplicationData在 Framework 下是%USERPROFILE%AppDataRoaming，在 .NET 8 的 Linux 容器里变成$HOME/.local/share，路径语义已变
跨框架文件操作真正的麻烦点不在语法，而在“同样代码在不同环境触发不同系统调用”。权限模型、符号链接解析、长路径支持（\? 前缀）、甚至时区处理（File.GetLastWriteTime 返回本地时间还是 UTC），每个都可能成为静默差异源。测的时候得真用两套环境跑，不能只信文档。
