首选 AppContext.BaseDirectory——它稳定返回带末尾反斜杠的程序根目录，跨平台、不随工作目录变化，.NET Core/.NET 5+ 单文件发布下仍可靠；Environment.CurrentDirectory 易受启动方式和代码修改影响，不适合读取同级配置文件。
绝大多数情况下，直接用 AppContext.BaseDirectory 就够了——它返回带末尾反斜杠的程序根目录，稳定、跨平台、不随工作目录变化，.NET Core / .NET 5+ 及以后版本的首选。
为什么不能用 Environment.CurrentDirectory 读配置文件
这个值是进程启动时的“当前工作目录”，不是程序文件所在位置。命令行里先 cd D:\data 再运行 myapp.exe，Environment.CurrentDirectory 就变成 D:\data\；VS 调试时默认设为项目目录，但发布后完全不可控。
- 它可能被代码中途调用
Directory.SetCurrentDirectory()修改 - Web 应用中它常指向 IIS 或 Kestrel 的工作目录，跟你的
.exe毫无关系 - 想读同级的
config.json？90% 的路径错误都出在这里
AppContext.BaseDirectory 和 AppDomain.CurrentDomain.BaseDirectory 选哪个
两者在 .NET Framework 下行为基本一致，都指向可执行文件所在目录（末尾带 \）。但在 .NET 5+ 单文件发布（single-file publish）场景下差异明显：
-
AppContext.BaseDirectory始终返回实际运行时的程序根目录（即解压/加载后的临时或原路径），单文件部署也可靠 -
AppDomain.CurrentDomain.BaseDirectory在某些单文件场景下可能返回空或临时目录，已不推荐新项目使用 - 类库中若需兼容旧框架，可加运行时判断：
AppContext.BaseDirectory ?? AppDomain.CurrentDomain.BaseDirectory
WinForms/WPF 项目里 Application.StartupPath 真的更方便吗
它确实简洁：Application.StartupPath 直接返回不含文件名的目录路径，不用再套 Path.GetDirectoryName()。但它有硬性前提：
- 仅限 Windows Forms 或 WPF（需引用
System.Windows.Forms或PresentationFramework） - 在非 UI 线程（如后台任务）中调用会抛
InvalidOperationException：“线程上未启用消息泵” - 跨平台（比如用 Avalonia）或将来迁移到 MAUI 时，这行代码直接失效
- 如果只是读个配置，不如统一用
AppContext.BaseDirectory，少一层依赖
读写同级资源文件时，拼路径的细节容易翻车
别用字符串拼接：AppContext.BaseDirectory + "config.json" 在 Linux/macOS 上会崩（路径分隔符是 /）；也别漏掉末尾反斜杠判断——AppContext.BaseDirectory 已自带，但 Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location) 不带。
- 必须用
Path.Combine(AppContext.BaseDirectory, "config.json") - 如果用
Assembly.GetExecutingAssembly().Location，记得先Path.GetDirectoryName()，否则可能拿到xxx.dll所在路径而非主程序目录 - 单文件发布时，
Assembly.Location可能为空或指向临时提取路径，此时AppContext.BaseDirectory是唯一可信源
