上一节我们聊了路由和控制器之后有朋友私下问我Web API 写完了总不能一直放在 Visual Studio 里跑吧它到底怎么部署到服务器上他说自己公司的内网有一台 Windows Server基础设施那边不希望为一个小服务单独开 IIS 站点只想让业务程序作为一个独立进程常驻问我有没有更轻的方案。其实这个场景很典型尤其这些年微服务、后台任务、内部工具类系统越来越多WebApi 的部署方式早就不是“必须扔进 IIS”那一条路了。今天这一节我专门把最灵活的一种讲透自托管Self-Hosting。自托管的意思很简单你的 Web API 不依赖 IIS、不依赖任何外部 Web 服务器而是自己作为宿主进程跑起来。它自己监听端口、自己处理 HTTP 请求、自己控制生命周期。放到 Windows 服务里可以开机自启放到 Linux 上用 systemd 可以守护放到 Docker 里更是天然契合。这篇文章我会从原理讲到实操再讲上线时躲不开的权限、防火墙、进程守护以及我实际部署中踩过的坑适合手头已有 Web API 项目、但不想被应用池回收支配的开发者参考。1. 为什么要把 Web API 从 IIS 里“请”出来1.1 Web API 的前半生出生在 IIS 的屋檐下要说清楚自托管先得知道以前 Web API 是怎么活的。早期的 ASP.NET Web API 是基于 System.Web 构建的System.Web 这套东西和 IIS 深度绑定相当于 API 必须生活在一栋名叫“IIS”的大楼里。大楼提供水电、安保、保洁但楼里的规矩很多应用池要配、回收策略要管、权限要设站点停不停也不是你一个人说了算。这在大公司统一管控的服务器上没什么问题基础设施团队早就把 IIS 玩得很溜。可一旦碰上小项目、内网工具、边缘服务IIS 这套体系就显得太重了。且不说装 IIS 功能需要管理员去服务器上加角色光是给某个服务单独建一个站点、配好应用池、处理冲突端口工作量已经比写接口本身还大。更难受的是应用池回收。IIS 里应用池一旦空闲或者内存超标触发回收进程会直接被杀新。表面上你的 API 还在线实际上第一个请求过来要冷启动慢得能让人怀疑人生。对于一些常驻后台、需要低延迟响应的服务这种“不确定的死亡”是致命的。1.2 自托管真正的价值把命运握在自己手里自托管就是换一种活法不要大楼了自己租一个门面。你的程序本身就是一个独立进程自己监听端口自己接收请求没有人会在半夜把进程回收掉。想常驻就常驻想凌晨三点重启就凌晨三点重启只要操作系统不倒进程就能一直活着。到这一步很多人会问这不就是一个控制台程序里托管了 Web API 吗本质上没错但背后有一个标准化的过程。最初是 OWIN 规范把 Web API 和宿主解耦之后出现了基于 OWIN 的 Katana 实现让 ASP.NET Web API 能跑在控制台、Windows 服务、甚至 Linux 进程里到了 .NET Core 时代Kestrel 直接内置到框架中自托管更是变成了默认姿势。你今天随便新建一个 ASP.NET Core Web API 模板跑起来的时候其实已经在自托管了本地开发环境并没有装 IIS。所以自托管解决的核心问题可以概括成三点第一部署不依赖外部 Web 服务器的安装和配置第二进程生命周期由自己掌控不怕应用池回收第三更容易做自动化部署拷个文件夹就能跑和 Docker 这类技术无缝衔接。后面你会看到这点在真实运维里到底省了多少事。2. 自托管的运行原理宿主进程、HTTP 监听与中间件管道2.1 进程视角看宿主很多人刚接触自托管时会脑补是不是自己写了个 Web 服务器其实不用那么底层。自托管服务并不是从 Socket 开始自己解析 HTTP 协议而是复用现成的 HTTP 监听组件。Windows 上老一代 OWIN 自托管默认走 HttpListener它底层由系统内核驱动 HTTP.sys 提供服务新一代 ASP.NET Core 则内置了 Kestrel这是一个跨平台的 HTTP 服务器实现完全可以理解为“自己带的小型 Web 服务器”。Kestrel 只负责最纯粹的 HTTP 读写不处理进程管理、不处理系统服务注册那些是宿主进程自己的事。你可以这样理解宿主进程是餐厅老板HttpListener 或 Kestrel 是前台迎宾只负责把客人HTTP 请求接进来真正能做出菜来的是厨房里的厨师也就是你的 Controller 和中间件。自托管要做的就是把迎宾、厨师、服务生全放在同一个进程里老板自己当。2.2 一个请求从网线到控制器的完整旅程一个请求打过来完整路径大概是这样的客户端发送 HTTP 请求到操作系统网络栈然后由监听组件接收解析紧接着请求进入中间件管道经过路由、身份认证、异常处理等环节最终路由到对应的 Controller Action 执行业务代码再把结果封装成 HTTP 响应原路返回。在 OWIN 时代这条管道被抽象成“应用委托”中间件一个套一个请求经过所有中间件之后再原路返回就像剥洋葱一样逐层进入再逐层退出。在 ASP.NET Core 里这套管道被保留并发扬光大UseMiddleware、UseCors、UseAuthentication这些大家耳熟能详的方法其实都是在往管道里加环节。管道模型值得你认真理解因为部署自托管遇到很多“疑难杂症”都出自这里有的接口没走到自己写的中间件有的异常在管道里被吞掉有的路由配了但不生效。理解了管道顺序你调试起来会有方向感。2.3 两种自托管写法老一代 OWIN 与新一代 Kestrel老项目如果是基于 .NET Framework 的 Web API自托管通常用 OWIN 自宿主方案入口长这样using System; using System.Web.Http; using Microsoft.Owin.Hosting; using Owin; class Program { static void Main(string[] args) { const string baseAddress http://localhost:9000/; using (WebApp.StartStartup(baseAddress)) { Console.WriteLine($Web API 已启动监听: {baseAddress}); Console.WriteLine(按回车退出...); Console.ReadLine(); } } } public class Startup { public void Configuration(IAppBuilder app) { HttpConfiguration config new HttpConfiguration(); config.MapHttpAttributeRoutes(); app.UseWebApi(config); } }新项目如果是 .NET Core / .NET 6写法已经大大简化入口自带 WebApplication宿主默认就是 Kestrelvar builder WebApplication.CreateBuilder(args); builder.Services.AddControllers(); var app builder.Build(); app.MapControllers(); app.Run(http://*:9000);两代写法的逻辑是一模一样的创建宿主、配置路由/中间件、启动监听。差别只在老版需要手动引用 OWIN 自宿主包新版把这些都内置了。下面是传统 IIS 托管与自托管的核心差异我按自己的部署感受整理了一张表维度IIS 托管自托管宿主进程w3wp.exe由 IIS 管理你自己的 EXE生命周期自己管端口绑定站点绑定IIS 统一处理程序代码或配置文件指定应用池回收有空闲/内存超标/配置变更都可能触发没有除非程序自己退出部署方式需要 IIS 站点、应用池、权限配置拷文件、起进程或者注册成服务系统依赖必须装 IIS不依赖外部 Web 服务器跨平台基本只走 WindowsKestrel 支持 Windows/Linux/容器适合场景大型统一管控的企业站点内部服务、微服务、容器化部署、边缘工具搞清楚了原理下面我们上手搭一个真正能跑的自托管服务。3. 搭一个最小自托管服务从代码到跑通的完整过程3.1 选择合适的工程模板与依赖包如果你是全新项目直接用各 IDE 里的“ASP.NET Core Web API”模板最省事因为模板生成后Program.cs里那一串 builder/app 代码就是自托管的骨架。如果你手上是历史项目比如 .NET Framework 下的 Web API想改造成自托管那就新建一个“控制台应用 (.NET Framework)”然后通过 NuGet 安装这几个包Microsoft.AspNet.WebApi.SelfHost或者更推荐的Microsoft.AspNet.WebApi.OwinSelfHostOwinSelfHost这个名字已经暴露了它的身份它把 OWIN 中间件管道和 Web API 结合在了一起。选择 .NET Framework 4.6.1 以上版本兼容性更好依赖比较全。这里插一句为什么要选控制台应用而不是类库自托管需要一个可执行的入口控制台应用虽然看起来简陋但它是 Windows 服务、计划任务、Docker 容器都能直接拉起来的最小宿主形态。类库只能被调用没法自己跑起来。3.2 写一个能回应问候的接口我在本地建了一个模拟项目结构很简单一个Program.cs负责启动宿主一个Startup.cs负责搭管道和路由一个ValuesController.cs提供接口。完整代码如下using System; using System.Web.Http; using Microsoft.Owin.Hosting; using Owin; namespace SelfHostDemo { class Program { static void Main(string[] args) { const string baseAddress http://localhost:9000/; using (WebApp.StartStartup(baseAddress)) { Console.WriteLine($Web API 已启动监听: {baseAddress}); Console.ReadLine(); } } } public class Startup { public void Configuration(IAppBuilder app) { HttpConfiguration config new HttpConfiguration(); config.MapHttpAttributeRoutes(); app.UseWebApi(config); } } public class ValuesController : ApiController { [HttpGet] [Route(api/values/hello)] public IHttpActionResult Hello(string name) { return Ok($Hello, {name}); } } }注意WebApp.StartStartup()这个方法非常关键它做的三件事是启动宿主进程、加载Startup类里定义的中间件管道、开始监听指定地址。HttpConfiguration则负责把 Web API 的路由和 Controller 纳入管道MapHttpAttributeRoutes()启用基于特性的路由也就是我写在 Action 上的[Route(api/values/hello)]能被识别。3.3 跑起来验证三步走项目建好后按 F5 运行。控制台窗口会打印一行“Web API 已启动”程序进入阻塞状态等待请求。接下来验证接口是否真的响应浏览器直接访问http://localhost:9000/api/values/hello?namezhangsan正常情况下会返回一段 JSON内容大致是{message:Hello, zhangsan}。或者在命令行使用curl验证curl http://localhost:9000/api/values/hello?namezhangsan。看到返回后回到控制台按回车程序会正常退出。到这一步一个最小的自托管 Web API 已经能跑了。但请注意这只是本地开发阶段离“能上服务器”还有很长一段距离。下面这几节才是自托管部署的硬核部分也是我实际项目中踩过最多坑的地方。4. 真正上线前的那一关端口权限、防火墙与开机守护4.1 URLACL为什么普通账户监听报“拒绝访问”自托管服务最常见的现象是本地开发跑得好好的一放到服务器上就想以普通用户身份监听端口结果启动直接抛异常提示“拒绝访问”。很多人以为要换管理员账号跑其实这是对 HTTP.sys 没有理解到位。在 Windows 上Kestrel 可以完全走托管 Socket不太受这个限制但老一代 OWIN 自托管默认使用 HttpListener它是要往系统内核的 HTTP.sys 驱动里注册 URL 的。HTTP.sys 不是谁都能碰的系统里维护了一份访问控制列表叫 URLACL只有被纳入列表的用户或用户组才有权绑定对应的 URL 前缀。不配置 URLACL 的话唯一看似可行的办法就是管理员权限运行。可服务一旦用管理员账户常驻安全风险就上来了而且运维同学大概率不愿意把系统最高权限交给一个业务进程。正确姿势是用netsh命令给指定 URL 前缀添加访问权限netsh http add urlacl urlhttp://:9000/ userEveryone这里的http://:9000/表示监听本机所有 IP 的 9000 端口userEveryone表示所有用户都能绑定。如果只想限制到某个账户可以把Everyone换成实际账户名。配置完可以用netsh http show urlacl检查是否生效。4.2 防火墙放行别让服务只能本机访问端口权限解决之后程序能启动了但你会发现只有服务器本机能访问内网其他机器连不上。八成是 Windows 防火墙没放行端口。自托管服务是独立进程不像 IIS 那样有现成的防火墙规则所以基本上每次部署都要手动加一条。可以用图形界面“高级安全 Windows 防火墙”新建入站规则也可以直接用命令行netsh advfirewall firewall add rule nameMyWebApi dirin actionallow protocolTCP localport9000这条命令的含义是添加一条名为MyWebApi的入站规则允许 TCP 协议访问本机 9000 端口。加完之后再用内网另一台机器的浏览器访问http://服务器IP:9000/api/values/hello?namezhangsan这次应该就能通了。我见过不少项目死在防火墙这一步尤其是有多块网卡或者服务器同时承担多个业务的时候一排查就是半天。所以建议把防火墙规则和端口注册一起写进部署脚本不要每次手动操作。4.3 用进程守护工具把 EXE 变成 Windows 服务自托管服务如果只是裸跑一个控制台窗口那会面临一个致命问题远程桌面一注销会话结束程序直接没了。即使不注销万一进程崩溃也没人把它拉起来。所以上生产环境的第一步是把 EXE 注册成 Windows 服务。注册 Windows 服务可以直接用sc create但sc不支持设置崩溃自动重启也不支持日志重定向。我这边更推荐用 NSSMNon-Sucking Service Manager它是一个能把任意 EXE 变成服务的小工具配置灵活支持失败自动重启、日志重定向、环境变量注入。安装命令大致是这样nssm install MyWebApi nssm set MyWebApi Application C:\services\MyWebApi\MyWebApi.exe nssm set MyWebApi AppDirectory C:\services\MyWebApi nssm set MyWebApi AppStdout C:\services\MyWebApi\logs\stdout.log nssm set MyWebApi AppStderr C:\services\MyWebApi\logs\stderr.log nssm set MyWebApi Start SERVICE_AUTO_START nssm start MyWebApi逐行解释一下第一行创建名为MyWebApi的服务第二行指定要运行的程序路径必须是绝对路径第三行设置工作目录这非常关键后面我会专门讲第四、五行把程序的控制台输出和错误输出分别重定向到日志文件这样即使没有控制台窗口也能看到日志第六行设置服务开机自动启动第七行立即启动服务。这里有个容易被忽略的细节AppDirectory不设置的话服务启动后工作目录默认是C:\Windows\System32。如果程序里的配置文件或日志路径是相对路径它会跑到系统目录里找文件和写文件然后因为权限不足报一堆莫名其妙的错。这个坑我栽过不止一次后面详说。4.4 相对路径陷阱服务模式下工作目录会骗人自托管程序在开发机上明明一切正常放到 Windows 服务里就找不到appsettings.json或者读不到配置文件别怀疑代码问题多半是工作目录变了。Windows 服务启动时系统会把当前目录设置为 System32所以任何相对路径都指向C:\Windows\System32。解决思路是不要用相对路径而是基于程序集所在目录去定位资源string baseDir AppContext.BaseDirectory; string configPath Path.Combine(baseDir, appsettings.json);AppContext.BaseDirectory返回的是程序 EXE 所在的物理目录这个路径在任何启动方式下都是稳定的。日志同理别直接File.WriteAllText(log.txt, ...)要拼接AppContext.BaseDirectory或 NSSM 中配置的日志重定向路径。我现在写自托管项目时会在一开始就封装一个IAppPath之类的辅助类专门负责把任何相对路径转成基于程序目录的绝对路径所有配置加载和日志写入都走它。这个习惯帮我省掉了大量上线后的救火时间。5. 持久化配置与日志让自托管服务“有据可查”5.1 把监听地址和证书从代码里抽出来开发时你可以在代码里直接app.Run(http://*:9000);但上线后端口可能会变甚至同一套程序要在不同环境监听不同端口。把地址写死在代码里每次都要重新编译低效且易错。ASP.NET Core 的配置体系天生支持多种配置源优先级从高到低大概是环境变量、命令行参数、appsettings.json。默认的appsettings.json可以放监听地址{ Urls: http://*:9000;https://*:9443, Logging: { LogLevel: { Default: Information, Microsoft.AspNetCore: Warning } } }然后在Program.cs里不写死 URL交给框架自动读取。也可以用环境变量ASPNETCORE_URLS或命令行参数--urls http://*:9000覆盖配置部署时改起来非常灵活。老一代 OWIN 项目虽然没有这么优雅但同样可以把监听地址放到App.config或自定义 JSON 里启动时读取后传给WebApp.Start。我建议把端口规划放进部署文档里让基础设施团队知道这个服务占用了哪个端口避免后期和其他服务冲突。自托管服务不像 IIS 站点那样有一张清晰的端口清单没人维护的话很容易乱掉。5.2 日志必须离开控制台自托管服务在开发时控制台里的日志看起来很方便。但一旦变成 Windows 服务控制台是不存在的日志全丢。NSSM 虽然能把 stdout/stderr 重定向到文件但那只是最后一道防线程序内部记录的业务日志、请求日志、异常堆栈最好还是交给日志库统一处理。比较常见的方案是使用 NLog 或 Serilog 这类库配置一个文件输出目标让所有日志按日期自动拆分同时保留控制台输出用于本地调试。下面是一个简化版的配置思路{ Serilog: { MinimumLevel: Information, WriteTo: [ { Name: Console }, { Name: File, Args: { path: logs/log-.txt, rollingInterval: Day } } ] } }这里rollingInterval: Day表示每天一个日志文件。上线后真出事时按时间和线程去看日志往往能很快定位问题。日志里记得带上时间戳、请求路径、用户标识、异常堆栈不要只在 catch 里写一句“出错了”。关于日志我可以负责任地说自托管服务比 IIS 托管更依赖日志。IIS 有现成的请求日志、应用程序池状态出事时可以查系统日志自托管服务没有这些配套设施日志就是你唯一的线索。5.3 容器化自托管最自然的归宿自托管服务因为没有外部 Web 服务器依赖特别适合容器化。一个非常小的基础镜像把编译好的发布文件拷进去暴露端口启动命令直接运行 EXE就完事了。以 .NET Core 应用为例发布命令通常长这样dotnet publish -c Release -r win-x64 --self-contained如果目标是 Linux 容器则把运行时换成linux-x64。因为进程本身不依赖 IIS所以容器里不需要额外安装任何 Web 服务器组件。传统 IIS 托管迁移到容器反而麻烦自托管在这里是天然的赢家。我自己在内部项目里用过一套简化发布流程本地编译发布到一个目录打包成压缩包传到服务器解压然后用脚本更新服务。整个过程不碰 IIS不需要管理员界面操作出问题回滚也只是替换文件夹再重启服务。这套流程在传统 IIS 站点上很难做到因为站点配置、应用池、权限散落在 IIS 配置里迁到另一台机器要重新配一遍。6. HTTPS、跨域与静态文件补齐成熟服务的三块短板6.1 HTTPS 还是得上很多人觉得自托管服务是内网工具HTTPS 可要可不要。但我接触过的项目中连接凭证、数据回传这类接口越来越多裸 HTTP 把敏感信息明文跑在网络里接受度越来越低审计也过不去。ASP.NET Core 自托管启用 HTTPS 不算复杂准备好证书文件后可以在Program.cs里按如下方式配置 Kestrelbuilder.WebHost.ConfigureKestrel(options { options.ListenAnyIP(9443, listenOptions { listenOptions.UseHttps(cert.pfx, your-password); }); });这里ListenAnyIP(9443)表示监听所有网卡的 9443 端口UseHttps指定证书文件和密码。内网环境可以先用自签名证书跑通流程但生产环境还是建议使用受信任的证书否则客户端那边要么装信任链要么天天被证书告警骚扰。老一代 OWIN 自托管做 HTTPS 会稍微麻烦一点通常需要配合 HttpListener 的证书绑定使用netsh http add sslcert把证书和端口绑定起来。这里我不展开如果你还在维护这类老项目建议优先考虑迁移到新框架长期看维护成本更低。6.2 跨域策略别让浏览器把服务拒之门外自托管服务一旦要提供给前端页面调用就绕不开 CORS。如果前端跑在另一个端口上比如一个 Vue 或 React 开发服务器默认情况下浏览器的同源策略会拦截跨端口请求。ASP.NET Core 的写法比较直接先注册 CORS 服务再启用中间件。builder.Services.AddCors(options { options.AddDefaultPolicy(policy { policy.WithOrigins(http://localhost:3000) .AllowAnyHeader() .AllowAnyMethod(); }); }); // 在 app.UseRouting() 之后加入 app.UseCors();这里WithOrigins建议明确写清楚允许的来源不要直接AllowAnyOrigin。生产环境如果把跨域放开成星号等于把接口暴露给任意网页调用容易被别有用心的人拿去做恶意请求。老一代 OWIN 自托管则是在HttpConfiguration上启用 CORS安装Microsoft.AspNet.WebApi.Cors包后调用config.EnableCors()。原理差不多不再赘述。6.3 静态文件自托管不等于自带静态文件能力自托管服务默认只处理动态接口不带静态文件托管能力。如果你需要它同时承载一个前端页面或者提供一些静态资源下载得手动启用静态文件中间件。ASP.NET Core 里一行代码就够了app.UseStaticFiles();默认情况下它会把wwwroot目录下的文件作为静态资源对外提供。OWIN 时代则需要安装Microsoft.Owin.StaticFiles然后在 Startup 里调用app.UseStaticFiles()。需要注意文件路径必须放在程序目录下别指望它能像 IIS 那样把站点目录隔离开所有静态文件都在你的进程工作目录里权限问题要自己控制好。一般在真正的生产环境我不会让自托管服务直接面对大流量静态文件。更合理的做法是前面套一层反向代理比如 Nginx由 Nginx 处理静态文件和 HTTPS 终结自托管服务专心处理 API各司其职。6.4 反向代理自托管服务也能躲在后面自托管不是只能“裸奔”常见的架构是 Nginx 监听 80/443做 HTTPS 卸载和反向代理把/api开头的请求转发到自托管服务监听的 9000 端口。这样做的好处非常多对外只暴露一个统一入口证书管理集中静态文件交给 Nginx 处理后端服务重启时 Nginx 不受影响后续要扩展多实例做负载均衡也只需要在 Nginx 配置里加一个 upstream 组把请求轮询到多个自托管实例上。跨平台部署时这个组合几乎成了标准姿势。自托管负责业务Nginx 负责流量进出两边配合得很舒服。7. 我实际部署中反复踩过的雷和对应的处理姿势7.1 监听地址写成 localhost 导致局域网无响应开发时为了图省事我经常写http://localhost:9000/。本地跑没问题一旦把这套程序放到服务器上其他机器怎么访问都不通。原因很简单localhost只监听回路地址也就是本机自己不会监听内网网卡的 IP。解决办法是把监听地址改成http://:9000/或者http://0.0.0.0:9000/表示监听本机所有 IP。所以写代码时建议从一开始就写成或0.0.0.0别等上线了再改。7.2 服务账户没有写权限导致日志乖乖“失踪”自托管服务注册为 Windows 服务后默认可能用的是 LocalSystem 账户权限比较高如果你选择了普通服务账户工作目录和日志目录没有写权限程序会一启动就异常或者看似正常但日志根本写不进去。最坑的是异常被服务管理器吞掉你连错误都看不到。我的习惯是专门为每个服务建一个独立的日志目录并给服务账户授予该目录的读写权限配置文件里日志路径用绝对路径不要用相对路径。真出了问题先看服务是否启动成功再看 NSSM 重定向的 stderr 日志最后看日志库写的运行日志一层层排查。7.3 端口占用与绑定失败自托管服务启动时报“地址已被占用”原因一般是端口被别的进程占用了。先用下面命令查是谁netstat -ano | findstr :9000看到 PID 之后再用tasklist | findstr PID查对应进程。如果是自己旧实例没退干净杀掉即可如果是别的服务占用了端口那就只能换端口了。自托管服务没有 IIS 那种端口冲突自动提示全凭运维纪律。所以我前面强调要把端口清单维护好。7.4 一注销会话程序就没了这是自托管新手最容易犯的错远程登录服务器双击 EXE 启动服务程序在桌面会话里跑着然后锁屏、断开远程桌面再登进去发现进程消失了。Windows 的会话隔离机制会把退出登录时属于该会话的进程一并清理。解决办法前面已经说了用 NSSM 把程序注册成 Windows 服务或者至少用计划任务配置成“不管用户是否登录都运行”。不要贪图方便直接裸跑 EXE除非你打算让它每天“手动复活”。7.5 冷启动慢与并发小知识自托管服务首次请求往往会比后续请求慢因为进程里需要初始化各种组件、加载程序集、建立连接池。在 IIS 托管时代应用池回收后同样有冷启动问题。自托管的好处是没人回收它冷启动只发生在进程重启时。如果你是 Docker 部署重启频繁冷启动问题会被放大可以在容器健康检查里加一个预热请求或者启动时主动访问一次自己的接口。另外自托管服务默认并发能力没有 IIs 里那些模块帮忙Kestrel 的性能上限虽然很高但如果你在程序里同步调用阻塞 I/O、用线程池不当照样会被压垮。部署完建议做一个简单的并发冒烟测试看线程池和连接是否稳定。7.6 自托管不要忘恢复策略最后提醒一件容易被忽略的事自托管应用本身退出以后有没有机制把它拉回来NSSM 能配置失败自动重启但如果程序因为 OOM 被系统杀了NSSM 大概率也会按照 Exit Action 执行重启。我一般设置重启延迟 5 秒避免死循环快速重启把 CPU 打满。在 Linux 上systemd 的Restarton-failure也承担同样职责。这些松散的“小毛病”单看都不致命组合起来却能让一次部署变成灾难。我在实际项目里发现把端口、防火墙、服务注册、日志路径、启动脚本这些整理成一份 checklist每次发布照着做一遍比临时抱佛脚可靠得多。自托管这条路说到底是在拿掉外部 Web 服务器的依赖之后把原本被隐藏的运维细节一一接管过来。它不复杂但需要你把每一个细节都当回事——地址别写错端口别占冲突日志别丢进程别裸奔。如果你也被 IIS 的应用池回收或者繁琐的站点配置折磨过不妨从一个小接口开始把它装进自托管宿主里跑起来再逐步加上 HTTPS、跨域、反向代理。我先踩出来的这些雷你大概率都能绕开。