IWebHostEnvironment.ContentRootPath 是应用运行时的根目录路径，如发布到 D:myapp 则为该路径，本地调试时为 bin/Debug/net8.0；必须通过依赖注入获取，不可用 Directory.GetCurrentDirectory() 或静态创建。
ASP.NET Core 里 IWebHostEnvironment.ContentRootPath 是什么路径
它就是项目编译后实际运行时的“根目录”，不是源码目录，也不是 bin/Debug 下某个子文件夹。比如你发布到 D:myapp，那 ContentRootPath 就是 D:myapp；本地调试时通常是 你的项目路径inDebug
et8.0 这类路径。
常见错误：直接用 Directory.GetCurrentDirectory() 替代 —— 它返回的是进程启动目录（可能是 VS 安装目录、dotnet.exe 所在目录），完全不可靠。
- 必须通过依赖注入获取
IWebHostEnvironment实例，不能 new 或静态调用 - 在
Program.cs里可用builder.Environment.ContentRootPath - 在 Controller 或 Service 中，需构造函数注入
IWebHostEnvironment
非 ASP.NET Core 项目怎么拿到类似“项目根目录”
纯控制台或类库没有 ContentRootPath 概念，得自己推导。最稳妥的方式是基于当前程序集位置反推：
AppContext.BaseDirectory 是最接近的替代——它指向 exe 或 dll 所在目录（即 bin/Debug 级别），但不是源码根目录。
- 想回到源码根？不行，运行时根本没这个信息。只能靠约定，比如假设配置文件在
../config/appsettings.json - 用
typeof(Program).Assembly.Location+Path.GetDirectoryName得到的是程序集所在目录，和AppContext.BaseDirectory通常一致 - 不要用
Environment.CurrentDirectory，它会被Directory.SetCurrentDirectory随意修改
ContentRootPath 和 WebRootPath 别混了
ContentRootPath 是整个应用的根（含 wwwroot、Controllers、appsettings.json）；WebRootPath 默认是 ContentRootPath/wwwroot，只管静态文件（CSS/JS/图片）。
- 读取
appsettings.json必须用ContentRootPath - 写入日志文件到
logs/error.log，路径应拼接Path.Combine(env.ContentRootPath, "logs", "error.log") - 如果改过
webBuilder.UseWebRoot("public")，WebRootPath就变成ContentRootPath/public，但ContentRootPath不变
发布后路径突然不对？检查这几个点
本地跑得好好的，一发布就报 FileNotFoundException 找不到配置文件或模板，大概率是路径逻辑没适配发布结构。
- 确认是否硬编码了
../../这种相对路径——发布后目录层级可能变化，绝对路径才可靠 - 检查是否误把
IWebHostEnvironment注入到了静态类或单例中，且在 Host 创建前就访问了ContentRootPath（会是 null 或空字符串） - Linux 上路径分隔符用
Path.Combine，别手拼"/"或"\" - 容器部署时，若挂载了外部卷，
ContentRootPath仍是容器内路径，不是宿主机路径
真正麻烦的从来不是怎么取路径，而是路径背后隐含的假设：你默认它可写、默认它存在、默认它没被 Docker 卷覆盖——这些都得自己验证，框架不替你担责。
