企业官网建设流程全解析

简介：本资源是一个面向C#中高级开发者与.NET架构实践者的WebApi服务自托管Demo，解决传统WebApi依赖IIS导致的跨平台受限、容器部署困难及生命周期控制弱等实际问题。项目采用C#实现完全脱离IIS的轻量级WebApi服务，基于.NET Core（或兼容框架）结合Kestrel/HttpListener进行自我托管，支持Windows/Linux多平台部署，适用于微服务拆分、边缘计算场景及CI/CD环境下的快速验证。压缩包共188个文件，含20个核心C#源码（如WebAPIServer.cs）、58个运行时DLL、48个XML文档说明、14个NuGet包及配置类文件（config、exe、csproj等），结构完整，可直接编译运行；包体大小为5.92MB，精简实用。已有750人学习下载，读者可获得一套可运行的解耦式WebApi工程模板、清晰的自托管启动逻辑、RESTful接口设计范例及配套调试配置（含vshost、cache、pdb等开发辅助文件），便于快速理解服务生命周期管理与HTTP通信底层集成。

1. 为什么这个 Demo 不该跑在 IIS 上：一个被低估的解耦刚需

很多同学做毕设或课设时，一上来就建 ASP.NET Web API 项目，点“运行”——好，IIS Express 启动了，浏览器弹出https://localhost:5001/api/values，返回[1,2,3]，心里一松：“成了！” 结果答辩前两天，导师问：“如果客户服务器没装 IIS，或者只允许开指定端口、禁用 Windows 服务管理器，你这服务还能部署吗？”——当场卡壳。
这不是刁难，而是真实交付场景：某高校实验室的嵌入式设备管理平台，后端必须以普通 Windows 用户权限启动、不依赖系统级服务、能和 Python 数据采集脚本共存于同一台工控机；某公司内部工具链要求所有微服务统一用dotnet run启动、日志格式对齐、健康检查走/healthz端点——而 IIS 的管道模型、应用池生命周期、hosting.json 配置隔离，全在制造摩擦。
这个 Demo 就是为这类“非典型部署”准备的：它用 C# 原生Microsoft.AspNetCore.Hosting构建自托管 WebApi，彻底绕过 IIS（包括 IIS Express），支持dotnet publish后单文件发布、无安装包静默部署、命令行参数控制端口与环境，同时保留完整中间件链、Swagger 文档、JWT 认证扩展点。适合做课程设计基础框架、毕设后端骨架，或作为插件通信中枢——比如你的 C# 主程序需要暴露 HTTP 接口供外部 Python 脚本调用设备状态，又不想拉起整个 IIS。

2. 总体架构设计：三层宿主模型与五个核心通信契约

这个 Demo 不是“去掉 IIS 的 WebApi”，而是重新定义宿主边界：把“谁启动进程”“谁监听端口”“谁路由请求”拆成可替换的三层。上层是业务逻辑（Controller），中层是通信契约（HTTP 协议适配层），底层是宿主引擎（Kestrel + 自定义 HostBuilder）。这种分层让插件化成为可能——比如后期想接入 WebSocket 实时指令通道，只需新增一个IHostedService实现，不碰现有 Controller。

2.1 宿主层：从 IWebHostBuilder 到 IHostBuilder 的范式迁移

ASP.NET Core 3.0+ 已全面转向通用主机（Generic Host），它把 Web 宿主（IWebHostBuilder）和后台服务宿主（IHostBuilder）统一。本 Demo 强制使用IHostBuilder，原因很实际：

• IIS 模式下，IWebHostBuilder会自动注入IISIntegration中间件，接管进程生命周期；而IHostBuilder默认不加载任何 Web 相关组件，完全由你决定何时、如何挂载 Kestrel；
• IHostBuilder支持ConfigureServices和ConfigureContainer<TContainerBuilder>双注册入口，方便后期集成 Autofac 或其他容器；
• 最关键的是，它原生支持IHostedService，这是实现“插件热加载”的基石——比如一个硬件监控插件，可以注册为后台服务，在StartAsync()里初始化串口，在StopAsync()里安全关闭。

// Program.cs 入口：纯手工构建 Host，不调用 CreateDefaultBuilder() public static IHostBuilder CreateHostBuilder(string[] args) => Host.CreateDefaultBuilder(args) .ConfigureAppConfiguration((hostingContext, config) => { // 优先加载 appsettings.{Environment}.json，再被命令行参数覆盖 config.AddJsonFile("appsettings.json", optional: false, reloadOnChange: true) .AddJsonFile($"appsettings.{hostingContext.HostingEnvironment.EnvironmentName}.json", optional: true, reloadOnChange: true) .AddCommandLine(args); // ← 关键！支持 dotnet MyApp.dll --urls http://*:5002 }) .ConfigureServices((hostContext, services) => { // 注册业务服务：这里注入的是“通信能力”，不是具体业务 services.AddSingleton<ICommunicationChannel, HttpChannel>(); services.AddSingleton<IRawDataProcessor, JsonDataProcessor>(); // Web 层显式注册：不依赖 IIS 集成包 services.AddControllers(); services.AddEndpointsApiExplorer(); services.AddSwaggerGen(c => { c.SwaggerDoc("v1", new OpenApiInfo { Title = "Demo API", Version = "v1" }); // 启用 XML 注释（需在 csproj 中设置 <GenerateDocumentationFile>true</GenerateDocumentationFile>） var xmlFile = $"{Assembly.GetExecutingAssembly().GetName().Name}.xml"; var xmlPath = Path.Combine(AppContext.BaseDirectory, xmlFile); if (File.Exists(xmlPath)) c.IncludeXmlComments(xmlPath); }); }) .ConfigureWebHostDefaults(webBuilder => { webBuilder.UseStartup<Startup>(); // Startup.cs 仅负责 Configure()，不碰 BuildWebHost() });

提示：CreateDefaultBuilder()已内置日志、配置、依赖注入，但不自动启用 Web 功能。UseStartup<Startup>()是唯一触发 Web 管道的开关，而Startup.Configure()里只写app.UseRouting()、app.UseEndpoints()，绝不调用app.UseIISIntegration()——这是解耦的第一道防线。

2.2 通信契约层：定义插件可复用的 HTTP 交互协议

“C# 插件通信”不是指 DLL 动态加载，而是指跨进程、跨语言的标准化数据交换。本 Demo 设计了五个最小可行契约（Contract），全部通过 HTTP API 暴露，确保 Python/Node.js/Java 客户端能零成本对接：

这些契约不是硬编码在 Controller 里，而是通过策略模式注入：

// Controllers/CommunicationController.cs [ApiController] [Route("api/v1")] public class CommunicationController : ControllerBase { private readonly ICommunicationChannel _channel; private readonly ICommandRegistry _commandRegistry; public CommunicationController(ICommunicationChannel channel, ICommandRegistry commandRegistry) { _channel = channel; _commandRegistry = commandRegistry; } [HttpPost("raw")] public async Task<IActionResult> PostRawData([FromBody] JsonElement data) { // 交由通道统一处理：序列化、校验、转发给处理器 var result = await _channel.ProcessRawDataAsync(data); return Ok(result); } [HttpPost("command")] public async Task<IActionResult> InvokeCommand([FromBody] CommandRequest request) { // 指令分发：不关心具体实现，只查注册表 if (!_commandRegistry.TryGetCommand(request.Name, out var command)) return BadRequest($"Unknown command: {request.Name}"); var response = await command.ExecuteAsync(request.Parameters); return Ok(response); } }

ICommunicationChannel是抽象层，当前默认实现HttpChannel负责 HTTP 协议编解码，但未来可轻松替换为TcpChannel或NamedPipeChannel——这就是“解耦”的真正价值：当客户说“改成局域网 TCP 通信”，你只需写一个新类，改一行 DI 注册，不用动 Controller。

2.3 业务层：Controller 仅作协议翻译器，不做业务判断

很多初学者把 Controller 写成“万能胶水”，在里面连数据库、调第三方 SDK、做复杂计算。这会导致测试困难、无法插件化、且与宿主强耦合。本 Demo 的 Controller 坚守单一职责：接收 HTTP 请求 → 转换为领域对象 → 调用服务接口 → 将结果序列化为 HTTP 响应。所有业务逻辑下沉到Services/目录下的独立类库。

例如设备状态查询：

// Controllers/DeviceController.cs [ApiController] [Route("api/v1/devices")] public class DeviceController : ControllerBase { private readonly IDeviceService _deviceService; // ← 业务服务，非数据访问层 public DeviceController(IDeviceService deviceService) { _deviceService = deviceService; } [HttpGet("{id}")] public async Task<ActionResult<DeviceDto>> GetDevice(string id) { // 1. 参数校验（ID 格式） if (!Guid.TryParse(id, out _)) return BadRequest("Invalid device ID format"); // 2. 调用业务服务（可能涉及缓存、重试、熔断） var device = await _deviceService.GetDeviceByIdAsync(id); if (device == null) return NotFound(); // 3. DTO 转换（避免暴露 Entity） var dto = new DeviceDto { Id = device.Id, Name = device.Name, Status = device.Status.ToString(), LastActive = device.LastActiveUtc }; return Ok(dto); } } // Services/DeviceService.cs —— 真正的业务逻辑 public class DeviceService : IDeviceService { private readonly IDeviceRepository _repository; // 仓储接口，可被 EF Core / Dapper / Mock 替换 private readonly ILogger<DeviceService> _logger; public DeviceService(IDeviceRepository repository, ILogger<DeviceService> logger) { _repository = repository; _logger = logger; } public async Task<DeviceEntity> GetDeviceByIdAsync(string id) { _logger.LogInformation("Querying device {Id}", id); // 这里可加缓存装饰器、重试策略等横切关注点 return await _repository.GetByIdAsync(id); } }

注意：DeviceEntity是领域实体，DeviceDto是数据传输对象，二者严格分离。DTO 类放在Models/Dto/下，Entity 放在Models/Entities/下，目录即契约——这是团队协作时最省心的约定。

3. 关键模块实现：从 Kestrel 配置到插件热加载实战

解耦不是口号，是每个模块的精准控制。本章聚焦三个最易翻车的核心模块：Kestrel 网络栈配置、Swagger 文档与认证集成、插件热加载机制。它们共同决定了服务能否在生产环境稳定运行。

3.1 Kestrel 配置：超越UseUrls()的端口与 TLS 精细控制

dotnet run --urls http://*:5000很方便，但生产环境需要更细粒度控制：绑定特定 IP、限制并发连接数、配置 HTTPS 证书、设置请求超时。这些都在ConfigureWebHostDefaults的webBuilder阶段完成，绝不能在Startup.ConfigureServices()里用services.Configure<KestrelServerOptions>——那只是配置快照，不生效。

// Program.cs 中 ConfigureWebHostDefaults 内部 webBuilder.ConfigureKestrel(serverOptions => { // 1. 绑定到所有 IPv4 地址（不绑 IPv6，避免某些工控机网络异常） serverOptions.ListenAnyIP(5001, listenOptions => { listenOptions.UseHttps("cert.pfx", "password123"); // 生产环境务必用 PFX，非 PEM listenOptions.Protocols = HttpProtocols.Http1AndHttp2; }); // 2. 为管理端口单独配置（如 /healthz 专用端口，不走 HTTPS） serverOptions.Listen(IPAddress.Loopback, 5002, listenOptions => { listenOptions.UseConnectionLogging(); // 仅管理端口开启连接日志 listenOptions.Protocols = HttpProtocols.Http1; }); // 3. 全局连接限制（防 DoS） serverOptions.Limits.MaxConcurrentConnections = 100; serverOptions.Limits.MaxRequestBodySize = 10 * 1024 * 1024; // 10MB serverOptions.Limits.KeepAliveTimeout = TimeSpan.FromMinutes(2); });

关键参数说明：

• ListenAnyIP()：比ListenLocalhost()更可靠，尤其在 Docker 或虚拟机中；IPAddress.Any会同时监听 IPv4/IPv6，某些老旧设备驱动不兼容 IPv6，故显式用IPAddress.IPv4Loopback或IPAddress.Any（需测试）；
• UseHttps()：必须提供.pfx文件路径和密码，.pem需先转换（openssl pkcs12 -export -out cert.pfx -inkey key.pem -in cert.pem）；
• MaxConcurrentConnections：设为null表示不限制，但工控机内存有限，建议设为 50~200；
• KeepAliveTimeout：默认 2 分钟，若客户端是 Pythonrequests库，其默认连接池 keep-alive 是 5 秒，此处设短些可更快释放资源。

3.2 Swagger 与 JWT 认证：文档即契约，认证即插件

API 文档不是“锦上添花”，而是插件开发者的“接口说明书”。本 Demo 的 Swagger 集成强制要求：

• 所有 Controller 必须用<summary>XML 注释，否则生成文档时字段名显示为value；
• JWT 认证不写死密钥，而是从配置读取，并支持多签发者（适配未来对接不同身份中心）；
• 认证失败时，Swagger UI 能直接输入 Token 测试，而非返回 401 后让用户自己拼 Header。

// Startup.cs -> ConfigureServices() services.AddAuthentication(options => { options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme; options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme; }) .AddJwtBearer(options => { // 从配置读取：appsettings.json 中 "JwtSettings:Issuer", "JwtSettings:Audience", "JwtSettings:Key" var jwtSettings = Configuration.GetSection("JwtSettings"); options.TokenValidationParameters = new TokenValidationParameters { ValidateIssuer = true, ValidateAudience = true, ValidateLifetime = true, ValidateIssuerSigningKey = true, ValidIssuer = jwtSettings["Issuer"], ValidAudience = jwtSettings["Audience"], IssuerSigningKey = new SymmetricSecurityKey( Encoding.UTF8.GetBytes(jwtSettings["Key"])) }; }); // 同时注入 Swagger 认证支持 services.AddSwaggerGen(c => { c.SwaggerDoc("v1", new OpenApiInfo { Title = "Demo API", Version = "v1" }); // 添加 JWT Bearer 认证按钮 c.AddSecurityDefinition("Bearer", new OpenApiSecurityScheme { Description = "JWT Authorization header using the Bearer scheme. Example: \"Authorization: Bearer {token}\"", Name = "Authorization", In = ParameterLocation.Header, Type = SecuritySchemeType.ApiKey, Scheme = "Bearer" }); c.AddSecurityRequirement(new OpenApiSecurityRequirement { { new OpenApiSecurityScheme { Reference = new OpenApiReference { Type = ReferenceType.SecurityScheme, Id = "Bearer" } }, new string[] {} } }); });

玄学经验：Swagger UI 的Authorize按钮有时不显示，90% 是因为AddSecurityRequirement的new string[] {}写成了new string[0]或漏掉——必须是空字符串数组new string[] {}，且Reference.Id必须与AddSecurityDefinition的第一个参数完全一致（大小写敏感）。

3.3 插件热加载：基于 AssemblyLoadContext 的安全隔离

真正的插件化不是Assembly.LoadFrom()，那是全局域污染。本 Demo 使用AssemblyLoadContext（ALC）实现沙箱加载：每个插件在独立 ALC 中运行，卸载时可回收内存，且插件间的类型不会冲突。

// Plugins/PluginLoader.cs public class PluginLoader { private readonly Dictionary<string, AssemblyLoadContext> _pluginContexts = new(); public async Task<T> LoadPluginAsync<T>(string pluginPath) where T : class { var context = new AssemblyLoadContext(isCollectible: true); // 关键：isCollectible = true _pluginContexts[pluginPath] = context; try { var assembly = context.LoadFromAssemblyPath(pluginPath); var pluginType = assembly.GetTypes() .FirstOrDefault(t => typeof(T).IsAssignableFrom(t) && !t.IsAbstract); if (pluginType == null) throw new InvalidOperationException($"Plugin {pluginPath} does not implement {typeof(T).Name}"); // 创建实例，传入服务提供者（可访问主程序的 DI 容器） var instance = ActivatorUtilities.CreateInstance<T>(ServiceProvider, pluginType); return instance; } catch (Exception ex) { context.Unload(); // 加载失败，立即卸载上下文 _pluginContexts.Remove(pluginPath); throw; } } public void UnloadPlugin(string pluginPath) { if (_pluginContexts.TryGetValue(pluginPath, out var context)) { context.Unload(); _pluginContexts.Remove(pluginPath); } } }

使用示例（在IHostedService中）：

// Services/PluginHostedService.cs public class PluginHostedService : IHostedService { private readonly PluginLoader _loader; private readonly ILogger<PluginHostedService> _logger; public PluginHostedService(PluginLoader loader, ILogger<PluginHostedService> logger) { _loader = loader; _logger = logger; } public async Task StartAsync(CancellationToken cancellationToken) { var pluginDir = Path.Combine(AppContext.BaseDirectory, "Plugins"); if (!Directory.Exists(pluginDir)) return; foreach (var dll in Directory.GetFiles(pluginDir, "*.dll")) { try { // 加载实现了 IDeviceDriver 的插件 var driver = await _loader.LoadPluginAsync<IDeviceDriver>(dll); _logger.LogInformation("Loaded plugin: {Plugin}", Path.GetFileName(dll)); } catch (Exception ex) { _logger.LogError(ex, "Failed to load plugin {Plugin}", dll); } } } public async Task StopAsync(CancellationToken cancellationToken) { // 卸载所有插件 foreach (var path in _loader.GetAllLoadedPaths()) { _loader.UnloadPlugin(path); } } }

血泪经验：ALC 卸载不是即时的，GC 需要时间回收。若插件 DLL 被其他进程占用（如 Visual Studio 正在调试），Unload()会抛InvalidOperationException。生产环境应在StopAsync()中加重试逻辑，并记录未卸载成功的插件路径，供运维排查。

4. 避坑指南：五个高频翻车点与根治方案

这个 Demo 在多个课程设计和毕设中被反复验证，以下是最常被问爆的五个问题。它们不是“配置错误”，而是对 ASP.NET Core 生命周期和宿主模型的误解，必须从原理上厘清。

4.1 现象：dotnet publish后双击 exe 闪退，日志无输出

原因：dotnet publish生成的是.dll，不是.exe。双击.dll在 Windows 上会尝试用关联程序打开（通常是记事本），而非 .NET 运行时。学生常误以为“生成成功=可执行”，实则需用dotnet YourApp.dll启动。
解决：

• 方案一（推荐）：发布为单文件可执行文件，在csproj中添加：

  <PropertyGroup> <PublishTrimmed>true</PublishTrimmed> <PublishReadyToRun>true</PublishReadyToRun> <SelfContained>true</SelfContained> <RuntimeIdentifier>win-x64</RuntimeIdentifier> </PropertyGroup>

  然后dotnet publish -c Release -r win-x64 --self-contained，输出目录下会出现YourApp.exe，双击即可；
• 方案二：写一个start.bat：

  @echo off dotnet YourApp.dll --urls http://*:5001 pause

  避免用户直接双击 DLL。

4.2 现象：Swagger UI 显示 404，但/api/v1/devices能正常返回 JSON

原因：Swagger 静态资源（HTML/CSS/JS）未被正确映射。常见于Startup.Configure()中app.UseStaticFiles()位置错误，或app.UseSwaggerUI()未指定RoutePrefix。
解决：

• 确保UseSwaggerUI()在UseRouting()和UseEndpoints()之间，且RoutePrefix设为空字符串（否则默认是swagger，需访问/swagger/index.html）：

  app.UseRouting(); app.UseSwagger(); app.UseSwaggerUI(c => { c.SwaggerEndpoint("/swagger/v1/swagger.json", "Demo API v1"); c.RoutePrefix = string.Empty; // ← 关键！让 Swagger UI 在根路径 / }); app.UseEndpoints(endpoints => endpoints.MapControllers());

• 若仍 404，检查appsettings.json中AllowedHosts是否为*（开发环境），生产环境需明确列出域名。

4.3 现象：HTTPS 配置后，HTTP 端口（如 5000）无法访问，全部跳转到 HTTPS

原因：启用了app.UseHttpsRedirection()中间件，它会将所有 HTTP 请求 307 重定向到 HTTPS。这在 IIS 下合理，但在自托管中，若你明确需要 HTTP 和 HTTPS 并存（如内网 HTTP + 外网 HTTPS），必须禁用重定向。
解决：

• 删除Startup.Configure()中的app.UseHttpsRedirection()；
• 或按环境条件启用：

  if (env.IsProduction()) { app.UseHttpsRedirection(); }

• 更安全的做法：在 Kestrel 配置中，为 HTTP 端口单独绑定，且不调用UseHttpsRedirection()。

4.4 现象：插件加载后，调用其方法时报System.IO.FileNotFoundException: Could not load file or assembly 'Newtonsoft.Json'

原因：插件 DLL 编译时引用了特定版本的Newtonsoft.Json，而主程序用的是System.Text.Json，且未将插件依赖的 NuGet 包复制到输出目录。ALC 加载时找不到依赖项。
解决：

• 方案一（治本）：插件项目也引用System.Text.Json，避免混用 JSON 库；
• 方案二（应急）：在主程序csproj中添加<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>，强制将所有 NuGet 依赖复制到publish目录；
• 方案三（推荐）：插件项目使用<PackageReference>引用Newtonsoft.Json，并在Directory.Build.props中统一版本，避免版本碎片。

4.5 现象：IHostedService.StartAsync()中调用await _httpClient.GetAsync()报System.Net.Http.HttpRequestException: Connection refused

原因：StartAsync()执行时，Kestrel 尚未完全启动，HttpClient尝试访问本机http://localhost:5001失败。这是典型的竞态条件（Race Condition）。
解决：

• 不要在StartAsync()中发起对外 HTTP 调用；
• 改用IHostApplicationLifetime.ApplicationStarted事件，在 Kestrel 真正就绪后执行：

  public class MyHostedService : IHostedService { private readonly IHttpClientFactory _httpClientFactory; private readonly IHostApplicationLifetime _lifetime; public MyHostedService(IHttpClientFactory httpClientFactory, IHostApplicationLifetime lifetime) { _httpClientFactory = httpClientFactory; _lifetime = lifetime; } public Task StartAsync(CancellationToken cancellationToken) { // 延迟到 ApplicationStarted 事件 _lifetime.ApplicationStarted.Register(async () => { var client = _httpClientFactory.CreateClient(); var response = await client.GetAsync("http://localhost:5001/healthz"); // ... 处理响应 }); return Task.CompletedTask; } }

5. 验收与答辩：用三张表、一个脚本、一次演示征服评委

答辩不是讲 PPT，是证明“这东西真能跑、真能改、真能交”。我带过的十几个毕设项目，评委最常问的三个问题，都对应一套可量化的验收动作。下面这套流程，A同学去年用它拿了优秀毕设，从代码提交到答辩演示全程 22 分钟。

5.1 验收表一：功能完整性核对表（答辩前 1 小时必填）

这张表不是 checklist，而是证据链。每项必须附截图或命令行输出，证明你亲手验证过。评委扫一眼就知道工作量。

提示：把这张表打印出来，答辩时放在手边。评委问“插件怎么加载的？”，你直接翻到第 4 行，指给他看截图和日志——比讲 3 分钟原理管用。

5.2 验收表二：部署兼容性矩阵（体现工程思维）

学生常忽略“部署”不是“能跑”，而是“能在客户环境跑”。这张表模拟真实交付场景，用 ✅/❌ 标记，强迫你思考边界条件。

注意：这张表不必全绿，但必须有至少两项 ✅，且对 ❌ 项给出可落地的修复路径。评委想看到的是“我知道哪里不行，以及怎么修”。

5.3 验收表三：性能基线对比表（用数据说话）

“高性能”不是形容词，是数字。用wrk（轻量级压测工具）跑三组基准测试，证明你的解耦设计没有性能损耗。

post.lua示例（放在 wrk 目录）：

request = function() local data = '{"sensor":"temp","value":23.5,"ts":1699999999}' return wrk.format("POST", "/api/v1/raw", {["Content-Type"]="application/json"}, data) end

mixed.lua：随机选择 GET 或 POST（略）。重点是：你得跑出来，而不是说“应该差不多”。

5.4 一键验收脚本：verify.bat（答辩现场直接运行）

把所有验证步骤封装成一个批处理，答辩时双击运行，30 秒出报告。评委会觉得你极度专业。

@echo off echo === 开始自动化验收 === echo. REM 1. 检查发布目录是否存在 if not exist ".\publish" ( echo ❌ 错误：未找到 publish 目录，请先运行 dotnet publish pause exit /b 1 ) REM 2. 启动服务（后台） start "" ".\publish\MyApp.exe" --urls http://*:5001 --environment Development > nul 2>&1 timeout /t 3 >nul REM 3. 测试健康检查 curl -s -o nul -w "✅ HTTP 健康检查: %{http_code}\n" http://localhost:5001/healthz curl -s -o nul -w "✅ HTTPS 健康检查: %{http_code}\n" https://localhost:5001/healthz -k REM 4. 测试 Swagger 文档 curl -s -o nul -w "✅ Swagger UI: %{http_code}\n" http://localhost:5001/swagger/v1/swagger.json REM 5. 测试插件加载（复制一个假插件） copy /y ".\Samples\PluginSample.dll" ".\publish\Plugins\" >nul timeout /t 2 >nul echo ✅ 插件加载：检查控制台日志中是否有 "Loaded plugin" REM 6. 清理 taskkill /f /im MyApp.exe >nul 2>&1 echo. echo === 验收完成，请查看上方结果 === pause

运行效果：

✅ HTTP 健康检查: 200 ✅ HTTPS 健康检查: 200 ✅ Swagger UI <p> <a href="https://download.csdn.net/download/lingxiao16888/89726657" style="color:#ec7500;font-size:14px;"> 本文还有配套的精品资源，点击获取 </a> <img alt="menu-r.4af5f7ec.gif" src="https://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif" style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;"> </p>