安全替换运行中C#程序需由独立updater进程完成：旧进程退出前移交控制权，下载新版本至临时文件并校验哈希，原子移动替换+备份，延迟后重启；须禁用调试证书验证、防篡改签名、加密配置更新地址。
怎么安全替换正在运行的 C# 程序自身 exe 文件
不能直接覆盖——Windows 会锁住正在执行的 .exe，强行写入会报错 System.IO.IOException: The process cannot access the file because it is being used by another process。核心思路是：让旧进程主动退出，由外部临时程序完成替换，再拉起新版本。
- 最稳妥的做法是启动一个独立的 updater 进程（比如
updater.exe），把控制权交出去后立即调用Environment.Exit(0) - 不要用
Process.Start("new.exe")后自己退出——新进程可能还没起来，旧进程就关了，用户看到“闪退” - updater 程序必须和主程序同目录或固定路径，且具备写权限；若安装在
Program Files下，需以管理员权限启动 updater（否则替换失败） - 替换前建议先备份原
app.exe到app.exe.bak，出问题可快速回滚
用 WebClient 或 HttpClient 下载新版本时要注意什么
别用 WebClient.DownloadFile 直接往 app.exe 写——下载中途崩溃会导致主程序损坏无法启动。必须先下到临时位置，校验成功后再原子替换。
- 下载目标路径用
Path.GetTempFileName()生成唯一临时文件，比如tmpA1B2.exe - 务必验证下载完整性：服务端提供 SHA256 值，客户端用
SHA256.HashData计算并比对，不匹配就删掉临时文件、报错退出 -
HttpClient比WebClient更可控（支持超时、取消、进度回调），但注意复用实例，别每次新建 - 如果更新包是 zip，解压后要检查内部
app.exe时间戳或哈希，防止 zip 被篡改
如何让 updater.exe 可靠地执行替换+重启
替换不是简单 File.Copy + Process.Start 就完事。Windows 对正在加载的模块很敏感，必须确保旧进程完全退出、文件句柄释放干净。
- updater 启动时加命令行参数，如
updater.exe "C:\MyApp\app.exe" "C:\Temp\tmpA1B2.exe"，避免路径硬编码 - 替换前用
File.Move(oldPath, backupPath)（不是Copy），再File.Move(newPath, oldPath)——Move在同卷下是原子操作，不会出现“半新半旧”状态 - 重启主程序前，用
Task.Delay(100)等一下，确保文件系统缓存刷新、句柄真正释放（尤其 NTFS 卷） - 重启用
Process.Start(oldPath)，不要带参数；若原程序有启动参数，需从父进程传入或从配置读取
自签名证书 / HTTPS / 防篡改容易被忽略的点
本地测试时用 HTTP + 自签名证书很常见，但上线后不处理证书校验会埋雷：中间人攻击可替换下载内容，用户毫无感知。
- 开发阶段禁用证书验证（
ServicePointManager.ServerCertificateValidationCallback = (a,b,c,d) => true）仅限调试，发布前必须删掉 - 生产环境推荐用正规 CA 签发的 HTTPS 域名，或内置公钥做签名验证：服务端用私钥签
app.exe的哈希，客户端用硬编码公钥验签 - 别把更新服务器地址写死在代码里，至少放配置文件中，并加密存储（如用
ProtectedData类加密） - 如果程序有插件或外置 DLL，更新逻辑也要覆盖它们，否则新版 exe 加载旧 DLL 可能引发
FileNotFoundException或类型冲突
自动更新真正的难点不在下载或替换，而在于“旧进程彻底收尾”和“新进程稳稳接棒”之间的那几百毫秒——那里藏着闪退、卡死、文件损坏所有可能性。多加日志，尤其是 Process.GetCurrentProcess().Id 和文件操作前后的时间戳，出问题才好定位。
