敏感。.net framework 和 .net core/.net 5+ 的 configurationmanager.appsettings 和 iconfiguration 均区分大小写，键名必须完全匹配；web.config 中大小写不同的键被视为独立项，但易引发错误，推荐统一命名规范。
appSettings 里键名大小写敏感吗？
敏感。.NET Framework 和 .NET Core/.NET 5+ 的 ConfigurationManager.AppSettings 和 IConfiguration 都按原样匹配键名，不自动转小写或忽略大小写。
- 写成
<add key="ApiUrl" value="https://api.example.com"></add>，读取时必须用ConfigurationManager.AppSettings["ApiUrl"]，用["apiurl"]或["APIURL"]得到null - Web.config 中多个键名仅大小写不同（如
"Timeout"和"timeout"）会被视为两个独立项，但容易引发逻辑错误，建议统一命名规范（推荐 PascalCase 或全小写加连字符） - ASP.NET Core 已弃用 Web.config 的
appSettings节点，改用appsettings.json，那里是标准 JSON 解析，同样区分大小写
Web.config appSettings 能放复杂值（JSON、XML）吗？
能放，但不推荐——解析和维护成本高，且容易被 XML 特殊字符破坏。
- 如果硬要存 JSON，必须手动转义双引号和反斜杠，比如：
<add key="Features" value="{" darkmode></add>；否则 XML 解析会失败 - 嵌入 XML 更危险：
value属性值里不能出现未转义的、<code>>、&，否则配置加载直接抛XmlException - 真正需要结构化配置时，应拆分为多个扁平键（如
Feature.DarkMode、Feature.Beta），或迁移到appsettings.json+ 强类型绑定
为什么 ConfigurationManager.AppSettings 返回 null，但键明明存在？
常见原因不是拼错键名，而是配置节没正确定义或加载时机不对。
- 确认 Web.config 根节点下有
<configuration></configuration>，且<appsettings></appsettings>在<configuration></configuration>直接子级（不在<system.web></system.web>或其他节内） - 检查是否遗漏了
<configsections></configsections>声明（老项目有时会自定义 section handler，干扰默认行为） - 在
Application_Start以外的地方首次访问ConfigurationManager.AppSettings，可能触发延迟加载失败；若配置文件被并发修改，也可能临时返回空集合（极少见，但 IIS 应用程序池回收后首次请求易发生） - 发布时 Web.config 被转换（
web.release.config覆盖失败），导致生产环境实际没有该键——用 IIS 管理器“配置编辑器”或直接查看部署后的文件验证
.NET Core 迁移后还能读 Web.config 的 appSettings 吗？
不能。.NET Core 及以后版本完全移除了对 Web.config 的运行时解析支持，ConfigurationManager 类型甚至不存在。
- 旧项目升级到 .NET 5/6+ 时，
ConfigurationManager.AppSettings编译直接报错：类型未找到 - 等效替代是
IConfiguration，默认从appsettings.json、环境变量、命令行参数等源读取，Web.config 中的appSettings被彻底忽略 - 如果必须兼容旧配置格式，需手动解析 Web.config 文件（用
XDocument.Load），提取appSettings节点并注入IConfigurationBuilder，但这样做绕过了框架设计意图，增加维护负担
最常被忽略的一点：Web.config 的 appSettings 不支持配置变更热重载。修改后必须重启应用程序池或等待 IIS 自动回收，否则新值不会生效——这点和 appsettings.json 的 reloadOnChange: true 完全不同。
