IIS默认滚动更新不等于零停机，因旧进程拒新请求且长连接可能中断，新版本启动失败无自动回滚；Kestrel+nginx方案通过健康检查、优雅退出、符号链接和数据库兼容变更实现真正零停机。
为什么 IIS 默认滚动更新不等于零停机
很多团队以为只要用了 IIS 的“应用程序池回收 + 重叠回收”就实现了零停机，实际并非如此。关键问题在于：旧工作进程在收到 shutdown 信号后，仍会拒绝新请求，但已排队的请求（尤其是长连接、WebSocket、未完成的 async 方法）可能被强制中断。更严重的是，如果新版本启动失败，IIS 不会自动回滚，而是让整个站点不可用。
Kestrel + nginx 反向代理下的平滑重启流程
真正可控的零停机部署，推荐绕过 IIS，改用 Kestrel 自托管 + nginx 做负载分发。核心是利用 nginx 的 upstream 和 health_check，配合 dotnet 进程的优雅退出机制。
- 新版本发布前，先启动新
dotnet进程，监听不同端口（如5001），并在/healthz返回200 -
nginx配置中启用health_check，仅将流量切到健康实例；旧实例返回503后，nginx自动摘除 - 旧
Kestrel进程需响应SIGTERM，调用WebHostApplicationLifetime.StopApplication()，等待正在处理的HttpRequest完成（建议设置ShutdownTimeout≤ 30s） - 避免在
Startup.Configure中做阻塞初始化——它发生在nginx开始转发前，会导致新实例迟迟无法进入健康状态
dotnet publish 后如何避免文件锁导致启动失败
Windows 上直接覆盖正在运行的 .dll 文件，常引发 System.IO.IOException: The process cannot access the file。这不是并发问题，而是 .NET 运行时对已加载程序集的独占锁。
- 不要原地覆盖
publish目录；改为每次发布到带时间戳的子目录（如app-20240520-1423） - 用符号链接（
mklink /D current app-20240520-1423）指向当前生效版本，nginx或服务脚本只读取current - 若用
Windows Service托管，服务配置中的WorkingDirectory必须指向current，而非固定路径 -
dotnet进程启动时读取的是运行时路径下的文件，符号链接切换后无需重启进程本身——但必须确保新进程启动后再切链接，否则旧进程仍读旧 DLL
数据库迁移与 API 版本兼容性怎么一起考虑
零停机不只是进程不挂，更是请求不报错。如果新版本代码依赖新增字段，而旧版本还在处理请求，就会出现 NullReferenceException 或 SqlException。
- 所有数据库变更必须向前兼容：新增列加
DEFAULT或允许NULL；删除列必须等两轮部署后（旧版下线后再删） - API 接口不直接删字段，而是用
[Obsolete]标记 + 文档说明，并在响应体中保留字段（值为null） - 使用
Entity Framework Core时，避免在OnModelCreating中硬编码约束；改用HasDefaultValueSql("GETDATE()")等可迁移方式 - 灰度期间，可在中间件里按
User-Agent或 Header 注入版本路由逻辑，把新老流量导向不同 Controller 分支（临时方案，勿长期依赖）
app.Use(async (context, next) =>
{
var userAgent = context.Request.Headers["User-Agent"].ToString();
if (userAgent.Contains("v2-client"))
context.Items["ApiVersion"] = "v2";
await next();
});
真正的难点不在工具链，而在部署窗口里那几十秒——你得同时控制进程生命周期、文件系统可见性、反向代理状态、数据库 schema 演进和客户端行为。少一个环节，用户就可能看到 502 或超时。 
