appSettings 中 key 重复会导致 ConfigurationErrorsException 而非静默覆盖；value 含特殊字符须加双引号；应使用 ConfigurationManager.AppSettings["key"] 安全读取并判空；IIS 可能自动删除或移动 appSettings 节，需部署前后 diff 校验。
appSettings 里 key 重复会导致读不到值
Web.config 的 <appSettings> 不支持重复 key，后出现的同名项会覆盖前面的——但更糟的是，.NET Framework 4.0+ 默认直接抛 ConfigurationErrorsException，提示“配置系统未能初始化”，而不是报具体哪一行重复。
常见于多人协作合并配置、或复制粘贴时没删旧项。实际运行时可能只在某些环境（如 IIS 集成模式）才暴露，本地开发却正常，容易误判为部署问题。
- 检查所有
<add key="xxx" value="..." />，确保key全局唯一（包括<configSections>和其他 configSource 引入的文件） - 用 Visual Studio 的“配置编辑器”工具比手动查更可靠，它会高亮重复项
- 如果必须动态叠加配置，改用
<appSettings file="external.config">外挂方式，主文件只留基础项
value 值含空格或特殊字符必须加引号
value 里有空格、&、<、> 等 XML 特殊字符时，不加引号会导致解析失败，错误信息通常是“无法识别的实体引用”或“XML 文档中有错误”。
比如 <add key="ApiUrl" value="https://api.example.com/v1/" /> 看似没问题，但若实际是 value="https://api.example.com/v1/ & timeout=30"，就必报错。
- 所有
value建议统一用双引号包裹：<add key="LogPath" value="C:\Logs\MyApp\" /> - XML 实体转义仅用于
&（写成&）、<（）、<code>>（>），但引号更省心 - 路径末尾反斜杠
\在 .NET 中会被自动处理，不用额外转义
读取 appSettings 用 ConfigurationManager.AppSettings["key"] 最稳妥
别用 ConfigurationManager.GetSection("appSettings") 手动强转，也别依赖 WebConfigurationManager（它在非 Web 项目中不可用）。标准做法就是 ConfigurationManager.AppSettings["key"]，返回 string 或 null。
注意：这个 API 在 .NET Core/.NET 5+ 已废弃，但只要项目还是 .NET Framework（哪怕 4.8），它就是唯一推荐方式；混用 IConfiguration 反而增加复杂度且不兼容旧扩展点（如自定义配置节处理器）。
- 访问前务必判空：
var val = ConfigurationManager.AppSettings["Timeout"]; if (val == null) throw new InvalidOperationException("Missing appSettings key: Timeout"); - 不要用
TryGetValue——AppSettings是NameValueCollection，没有这个方法 - 值为空字符串
""和null含义不同，业务逻辑里要区分
部署时 web.config 被 IIS 自动修改导致 key 丢失
IIS 管理器里点“ASP.NET 设置”或“配置编辑器”改过设置后，IIS 会重写 web.config，把未声明的 <appSettings> 整个删掉，或者把 key 归并进 <system.web> 下的 <compilation> 等节——不是 bug，是 IIS 的“配置规范化”行为。
典型现象：开发机一切正常，发布到测试服务器后 ConfigurationManager.AppSettings["ApiKey"] 返回 null，打开服务器上的 web.config 发现 <appSettings> 消失了。
- 上线前用
diff对比部署包和服务器上实际文件，重点盯<configuration>根节点下是否少了<appSettings> - 禁止在 IIS 管理器里点“编辑”任何配置，所有变更必须走源码 + 部署流程
- CI/CD 中加入校验步骤：用 PowerShell 读取远程
web.config并确认关键key存在
key 是否存在、是否被覆盖、是否被转义、是否被 IIS 动手脚——每个环节都可能静默失效。最保险的做法是：每次改完立刻在目标环境跑一句 ConfigurationManager.AppSettings["xxx"] 输出日志，别等出问题再回溯。 
