不建议在运行时动态修改 web.config 文件，因其会触发 AppDomain 重启，导致会话丢失、缓存清空、静态变量重置及并发异常；推荐改用外部 JSON、数据库、环境变量或自定义配置管理器等热更新方案。
不建议在运行时动态修改 web.config 文件，因为这会触发应用程序域（AppDomain）重启，导致所有用户会话丢失、缓存清空、静态变量重置，甚至可能引发并发写入异常。但如果你确实有强需求（如部署后首次配置、内部工具场景），可以按以下方式谨慎操作。
理解后果：修改 web.config 会重启应用
ASP.NET（包括 .NET Framework 和旧版 .NET Core 兼容模式）将 web.config 视为关键配置文件。只要它被写入（哪怕只改一个空格），IIS 或 Kestrel（在某些托管模式下）都会检测到变更并自动回收当前 AppDomain 或重新加载应用 —— 这不是 bug，是设计行为。
所以：
• 用户正在提交的表单可能失败
• Session、Application、Cache 全部丢失
• 长连接（如 SignalR）断开
• 日志或监控可能记录多次“启动”事件
如果仍需修改：用 XmlDocument 安全写入
确保以独占方式打开、完整保存、保留格式，并捕获异常。不要用字符串替换或 StreamWriter 直接写。
- 引用
System.Xml和System.IO - 先备份原文件（例如加
.bak后缀） - 用
XmlDocument.Load()加载，定位节点（如<appsettings></appsettings>或<connectionstrings></connectionstrings>） - 增删改节点后，调用
Save()写回（注意路径要用HttpContext.Current.Server.MapPath("~/web.config")） - 写完后可手动调用
HttpRuntime.UnloadAppDomain()显式重启（非必需，系统通常自动触发）
更推荐的替代方案
绝大多数“需要动态改配置”的场景，其实更适合用其他方式实现：
-
用外部 JSON 配置文件：如
appsettings.custom.json，用IConfigurationBuilder.AddJsonFile(..., reloadOnChange: true)，支持热重载且不重启 - 数据库配置表：把可变参数（如邮件服务器、开关项）存在 DB，定期轮询或用 SignalR 推送变更
- 环境变量或 Azure App Settings / AWS Parameter Store：云环境首选，天然支持运行时更新
-
自定义配置管理器：封装一个线程安全的
ConcurrentDictionary<string string></string>，提供 API 更新 + 内存刷新，绕过 web.config
基本上就这些。真要改 web.config，务必做好重启预期和用户提示；95% 的情况，换种思路更稳。
