File.Exists在Windows不区分大小写而Linux严格区分，非bug而是文件系统差异；应统一小写命名或用Directory.GetFiles+OrdinalIgnoreCase比对，避免跨平台问题。
Windows 和 Linux 下 File.Exists 行为不一致怎么办
直接结论：C# 的 File.Exists 在 Windows 上不区分大小写，在 Linux/macOS 上严格区分大小写——这不是 bug，是底层文件系统行为透出的结果。
常见错误现象：File.Exists("config.json") 在 Windows 调试通过，部署到 Docker（Linux）后返回 false，但文件明明存在，只是实际名为 Config.json 或 CONFIG.JSON。
- 不要依赖
File.Exists做“存在性兜底”，它不是跨平台的“文件查找”工具 - 若需兼容大小写，先用
Directory.GetFiles获取目录下所有文件名，再用StringComparer.OrdinalIgnoreCase手动比对 - 更稳妥的做法是：在写入文件时就统一小写命名（如
path.ToLowerInvariant()），读取时也走同样逻辑，避免运行时判断 - 注意：NTFS 卷可配置为区分大小写（Windows 10/11 支持），此时
File.Exists也会变严格——不能假设 Windows 永远宽松
路径中含空格、中文、emoji 时 FileStream 报错 ArgumentException
根本原因不是 C# 限制，而是你传入了非法字符或未正确转义的路径字符串。.NET Core 3.0+ 和 .NET 5+ 已支持完整 Unicode 路径（包括 emoji、中文、空格），但前提是路径本身合法且编码无损。
常见错误现象：new FileStream("我的?/test.txt", FileMode.Open) 在某些旧版 Mono 或未启用长路径支持的 Windows 上抛出 ArgumentException: Illegal characters in path。
- 检查是否启用了长路径支持：Windows 需开启组策略「启用 Win32 长路径」，或确保应用清单中设置了
longPathAware=true - 避免手动拼接路径，一律用
Path.Combine（它会自动处理斜杠、重复分隔符和编码边界） - 不要对路径做
.Replace(" ", "%20")这类 URL 编码——文件系统不需要，反而导致路径不存在 - 如果路径来自用户输入，用
Path.GetInvalidFileNameChars()过滤非法字符（注意：该方法返回的是 Windows 规则，Linux 不检查这些，但跨平台应以最严为准）
Path.GetFullPath 在不同平台返回格式差异大
Path.GetFullPath 会把相对路径转成绝对路径，但它输出的格式受运行时平台和当前工作目录影响，容易在日志、配置序列化或跨服务传递时出问题。
使用场景：你想记录某个配置文件的真实位置，或把路径存进 JSON 配置供其他进程读取。
- Windows 返回类似
C:\app\data\config.json，Linux 返回/home/user/app/data/config.json——二者无法直接互换 - 如果目标是“可移植路径”，优先用相对路径 + 固定基准目录（如
AppContext.BaseDirectory），而不是依赖GetFullPath结果 - 需要绝对路径时，统一用
Path.GetRelativePath(baseDir, fullPath)反向转回相对路径，再结合 baseDir 重建，能规避平台差异 - 注意：
GetFullPath会解析..和.，但不会验证文件是否存在；若路径含不存在的父目录，它仍会返回一个“逻辑上合法”的绝对路径
跨平台写文件时，File.WriteAllText 中文乱码怎么破
默认情况下 File.WriteAllText 使用 UTF-8 无 BOM 编码，大多数现代编辑器能正确识别，但 Windows 记事本（Notepad）会把它当 ANSI（即系统本地编码，如 GBK），导致中文显示为乱码——这不是 C# 的错，是 Notepad 的历史包袱。
性能与兼容性影响：加 BOM 会让 UTF-8 文件开头多 3 字节，对文本解析几乎无影响，但能强制 Notepad 正确识别；不过某些 Unix 工具（如 grep -P）可能因 BOM 报错。
- 明确指定编码：用
File.WriteAllText(path, content, Encoding.UTF8)——显式优于默认 - 若必须兼容 Notepad，改用
Encoding.UTF8.WithBom()（需自己封装，.NET 6+ 可用new UTF8Encoding(true)） - 更推荐方案：让下游工具适配 UTF-8（如 VS Code、Notepad++ 默认支持），而非迁就老旧工具的编码猜测逻辑
- 特别注意：Linux/macOS 终端、
cat、jq等工具默认按 UTF-8 解释字节流，加 BOM 反而可能引发解析异常
真正麻烦的从来不是“怎么写对”，而是“谁在读、用什么读、有没有缓存旧路径”。跨平台文件操作里，最易被忽略的是工作目录的隐式依赖——Directory.GetCurrentDirectory() 在容器、service、GUI 应用里可能完全不可控，别让它成为路径逻辑的起点。
