web.config用于asp.net应用，app.config用于.net framework桌面/控制台应用，二者均为xml配置文件但宿主不同；.net core/.net 5+已弃用，改用appsettings.json。
Web.config 是 ASP.NET 应用的配置文件，App.config 是 .NET Framework 桌面/控制台应用的配置文件
两者本质都是 XML 配置文件，但绑定的宿主进程不同：IIS 或 Kestrel（ASP.NET）用 Web.config，dotnet run 或 exe 启动的控制台、WinForms、WPF 项目默认用 App.config。.NET Core / .NET 5+ 已弃用这两个文件，改用 appsettings.json —— 如果你还在用它们，大概率是在维护老项目。
App.config 编译后会重命名为 {exe名称}.config 并复制到输出目录
这是最容易被忽略的机制：你改了 App.config，但运行时没生效？先确认输出目录下有没有 MyApp.exe.config。没有的话，检查项目属性里的“生成操作”是否为 Content，“复制到输出目录”是否为 始终复制 或 如果较新则复制。VS 默认会做，但手动添加或迁入旧文件时容易漏掉。
-
App.config不会被直接读取，运行时只认{assembly-name}.config - 若程序集是类库（.dll），它不会自动加载自己的
App.config—— 配置由宿主进程（如调用它的 exe）决定 - 多项目引用时，只有启动项目的配置文件生效；类库里的
App.config只是占位或用于设计时提示
Web.config 的 <system.webserver></system.webserver> 和 <system.web></system.web> 块只在 IIS 集成模式下有效
如果你把 ASP.NET 应用部署到 IIS，这些节才起作用；换成自托管（如 WebHostBuilder + Kestrel），Web.config 里大部分内容会被忽略（除了 <aspnetcore></aspnetcore> 节）。常见坑是：本地 IIS Express 能跑，上线 IIS 报错，结果发现 <system.webserver></system.webserver> 里写了不支持的模块，或路径写死了 bin\roslyn\csc.exe 却没部署 Roslyn 编译器。
-
<system.web></system.web>控制 ASP.NET 运行时行为（如 session、compilation），但 .NET Core 中已无对应概念 -
<system.webserver></system.webserver>是 IIS 模块配置，和 .NET 版本无关，但依赖 IIS 版本支持（比如httpProtocol的customHeaders在 IIS 7+ 才可用） - IIS 下
Web.config支持“位置继承”，子目录可放另一个Web.config覆盖上级配置 —— 但权限受限（如不能在子目录开<system.web></system.web>）
读取配置时，ConfigurationManager 行为在不同场景下不一致
用 ConfigurationManager.AppSettings["key"] 看似简单，但它背后依赖的是当前 AppDomain 的配置源。桌面应用读 App.config，ASP.NET 应用读 Web.config，但若你在类库中硬编码调用，就可能拿错上下文 —— 尤其是单元测试项目或插件架构中。
- ASP.NET Core 中
ConfigurationManager已废弃，必须用IConfiguration注入 - .NET Framework 下，
ConfigurationManager.OpenMappedExeConfiguration可显式指定路径，但要注意权限：IIS 进程对Web.config是只读的，强行写会抛ConfigurationErrorsException - 加密配置节（如
connectionStrings）用aspnet_regiis.exe，但该工具只支持Web.config和 exe config，且必须匹配 .NET Framework 版本（v4.0 工具不能加密 v2.0 配置）
