ASP.NET Core 3.1静态变量持久化难题求解决方案（对接ATM-API）

针对你遇到的「ASP.NET Core应用对接ATM API时，无法序列化的静态变量在IIS应用池回收后丢失」的问题，以下是几个更优的可行方案：

1. 将ASP.NET Core应用部署为Windows Service（优先推荐） #

直接把应用注册为Windows Service，脱离IIS托管，彻底避免应用池回收带来的状态丢失问题：

• 无需额外开发独立服务，只需要修改项目配置：
  1. 安装NuGet包 Microsoft.Extensions.Hosting.WindowsServices
  2. 在Program.cs中添加Windows Service支持：

     public static IHostBuilder CreateHostBuilder(string[] args) =>
         Host.CreateDefaultBuilder(args)
             .ConfigureWebHostDefaults(webBuilder =>
             {
                 webBuilder.UseStartup<Startup>();
             })
             .UseWindowsService(); // 启用Windows Service托管
     

• 部署时，用dotnet publish生成可执行文件，再通过sc create命令注册为服务，或者用NSSM工具将exe包装成Windows Service。应用进程独立运行，静态变量（或Singleton服务）的状态会持续保留，直到服务被主动重启。

2. 精准配置IIS应用池回收策略（适配必须用IIS托管的场景） #

通过调整IIS回收规则，确保业务时段（7:30-18:00）不会触发回收：

• 打开IIS管理器，找到目标应用池 → 高级设置：
  • 取消勾选「固定时间间隔（分钟）」，避免定时回收干扰业务
  • 启用「特定时间」，设置在非业务时段（比如凌晨2:00）执行回收
  • 调大「私有内存限制（KB）」和「虚拟内存限制（KB）」的阈值，避免业务高峰期因内存占用触发意外回收
• 配合定时脚本（PowerShell）强化控制：
  • 业务时段禁用回收：appcmd set apppool "你的应用池名称" /recycling.periodicRestart.time:00:00:00
  • 非业务时段恢复回收：appcmd set apppool "你的应用池名称" /recycling.periodicRestart.time:24:00:00（或指定特定回收时间）
    用Windows任务计划分别在7:25和18:05自动执行这两个脚本。

3. 独立进程状态容器（替代Windows Service的轻量方案） #

如果需要多个Web应用共享状态，或者Web应用需频繁重启，可写一个轻量的控制台程序作为状态容器，通过命名管道实现进程间通信：

• 控制台程序作为状态持有者，存储无法序列化的对象，对外暴露简单的调用接口（比如获取、更新状态）
• ASP.NET Core应用通过NamedPipeClientStream调用控制台程序的接口，获取或修改状态
• 将控制台程序设置为开机自启，用Windows任务计划或NSSM注册为服务，确保状态持续存在。

4. 状态重构方案（适配可拆解的对象） #

如果目标对象虽然无法直接序列化，但可以拆解为可序列化的属性：

• 用IDistributedCache（比如Redis）或本地文件存储这些可序列化的属性
• 定义一个Singleton服务，在应用启动时从缓存/文件加载属性，重新构建目标对象
• 每次更新对象状态时，同步更新缓存/文件中的属性。这样即使IIS回收，应用重启后可快速重构状态。

内容的提问来源于stack exchange，提问作者Roman