.NET开发中全局数据存储的常见方式：一文搞懂实用方法

这篇文章就把.NET开发中全局数据存储的常见方式扒得明明白白——从基础的静态类、Session/Application对象，到常用的MemoryCache内存缓存、Redis分布式缓存，再到appsettings.json配置文件的正确使用，每一种方法都讲清楚具体用法、适用场景和避坑要点。不管你是做Web项目还是桌面应用，不管是存用户信息、系统配置还是临时共享数据，读完就能快速找到适合自己项目的方案，再也不用在“全局数据存哪”这件事上纠结半天。

做.NET开发的你，有没有过这种崩溃时刻？想存个全局共享的用户配置，用静态类怕并发串数据，用Session又嫌用户态隔离太麻烦，甚至试过把数据塞到数据库里，结果每次查都慢得让人着急？其实.NET生态里早就有一套成熟的全局数据存储方案，今天我把自己踩过的坑、用过的有效方法全告诉你，不管是小项目还是大系统，都能找到适合的方式。

最常用的基础方案：静态类与Web原生对象

先从大家最熟悉的“基础款”说起——静态类和Web项目里的Session、Application对象。这些方案不用额外引入包，开箱即用，但藏着不少容易踩的坑。

比如静态类，几乎每个开发者刚学.NET时都会用它存全局数据。我去年帮朋友改一个社区论坛项目，他用public static class GlobalData { public static User CurrentUser { get; set; } }存用户登录状态，结果上线后发现，用户A登录后居然能看到用户B的个人信息！查了半天才搞明白：静态类是进程级共享的，多个线程同时修改CurrentUser时，会把数据覆盖掉。后来我给他加了个静态锁对象：private static readonly object _lock = new object();，修改时用lock(_lock) { CurrentUser = user; }，才算解决并发问题。

所以如果你要用静态类，记住两点：要么确保没有并发修改，要么加锁——但锁会影响性能，低并发场景用用没问题，高并发就别凑活了。

再说说Web项目里的“原生选手”：Session和Application。 Session是用户级全局存储，每个用户有独立的Session容器，适合存用户购物车、登录Token这类“只属于当前用户”的数据。比如我之前做的电商项目，用Session存用户的临时收货地址，用户没登录也能选地址，结账时再绑定到账号——这比写Cookie安全多了。但Session依赖浏览器Cookie（默认用ASP.NET_SessionId标识用户），如果用户禁用Cookie，Session就失效了，这时候可以用URL重写，但体验会打折扣。

Application则是应用级全局存储，整个项目就一个Application实例，所有用户共享。比如电商网站的“今日热门商品”列表、全局配置的活动标语，用Application存再合适不过。我之前做的企业官网，用Application["SiteNotice"] = "国庆活动满200减50";存公告，修改时只要调用Application.Lock();加锁，改完再Application.UnLock();——但要注意，Application也是线程不安全的，并发修改会丢数据，一定要加锁！

性能优先的选择：内存缓存与分布式缓存

如果你的数据需要高频访问（比如文章分类、商品标签），或者不想每次查数据库，那缓存绝对是首选——毕竟内存的速度比硬盘快好几个数量级。

先讲内存缓存MemoryCache，这是.NET Core里的“内置缓存神器”。我之前做的CMS系统，文章分类有100多个，每次请求都查数据库，响应时间要1.2秒。后来用MemoryCache存分类数据，设置绝对过期时间30分钟（也就是30分钟后自动刷新），响应时间直接降到0.3秒，服务器压力也小了很多。用法很简单：先在Startup里加services.AddMemoryCache();，然后在服务里注入IMemoryCache，存数据用cache.Set("CategoryList", categoryList, TimeSpan.FromMinutes(30));，取数据用cache.TryGetValue("CategoryList", out List categories);就行。

但MemoryCache有个致命缺点：进程内存储——如果重启服务器或者应用池回收，缓存就没了。所以它适合存“丢了也能重新加载”的非关键数据，比如商品分类、热门文章列表，千万别存用户订单这种核心数据。

如果你的项目是多实例部署（比如微服务、负载均衡），MemoryCache就不够用了——每个实例的缓存是独立的，用户在不同实例间切换会导致缓存不一致。这时候得用分布式缓存，最常用的就是Redis。我去年做的微服务项目，有5个服务实例，用户登录后的Token存在Redis里，每个实例都能读取，避免了“用户换实例就要重新登录”的问题。Redis的优点太多：高可用（能做集群）、支持持久化（数据不会丢）、跨实例共享——微软文档里明确说，分布式系统推荐用Redis作为缓存解决方案。

配置Redis也很简单：安装Microsoft.Extensions.Caching.StackExchangeRedis包，然后在Startup里加services.AddStackExchangeRedisCache(options => { options.Configuration = "localhost:6379"; });——这里的Configuration是Redis的连接字符串。存数据和MemoryCache差不多，只是换成IDistributedCache接口，比如cache.SetString("UserToken:123", token, new DistributedCacheEntryOptions { AbsoluteExpirationRelativeToNow = TimeSpan.FromHours(1) });。

但Redis需要额外部署和维护，如果你是小项目，可能觉得麻烦；但如果是中大型项目，这钱花得值——毕竟分布式系统的一致性问题，靠Redis能解决大半。

最稳的配置管理：appsettings.json与配置绑定

最后说说配置数据的存储——比如数据库连接字符串、第三方API密钥、日志级别，这些数据要“稳”，要“易修改”，还要“安全”，appsettings.json绝对是最优解。

我做的支付系统里，把支付宝的配置写成这样：

"Alipay": {
 "AppId": "2021001123456789",
 "MerchantId": "1900009821",
 "PrivateKey": "MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQ..."
}

然后用配置绑定把它绑到一个AlipayOptions类里：

public class AlipayOptions
{
 public string AppId { get; set; }
 public string MerchantId { get; set; }
 public string PrivateKey { get; set; }
}

在Startup里加services.Configure(Configuration.GetSection("Alipay"));，然后在服务里注入IOptions，就能直接用options.Value.AppId取配置了——比写死在代码里方便一百倍！

更方便的是，如果你想修改配置不用重启应用，可以用IOptionsMonitor——它能实时监控appsettings.json的变化，比如你改了支付宝的AppId，保存后立刻生效，不用重启服务器。我之前做的物流系统，用IOptionsMonitor监控快递接口的配置，运维同事改配置时再也不用找我重启服务了！

但要注意：敏感配置不能明文存！比如数据库密码、API密钥，万一appsettings.json被泄露，后果不堪设想。我通常会用两种方法：一是用Azure Key Vault（云服务，专门存敏感配置），把appsettings.json里的敏感字段换成Key Vault的引用，比如"ConnectionStrings": { "Default": "@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/MyDbConnStr/xxxx)" }；二是用本地加密，比如用DPAPI加密配置文件的敏感部分，或者用微软的Microsoft.Extensions.Configuration.UserSecrets包，把敏感配置存在用户目录里（不会提交到Git）。

以上就是我整理的.NET全局数据存储的常见方式——每个方案都有自己的“舒适区”，没有绝对的“最好”，只有“最适合”。比如你做一个小博客，用静态类存全局设置就够了；如果是电商平台，肯定得用Redis做分布式缓存；如果是企业系统，appsettings.json的配置管理不能少。

如果你按这些方法试了，或者踩了新的坑，欢迎在评论区告诉我——咱们一起把.NET的全局存储玩得更明白！

用静态类存全局数据时，怎么避免多线程并发串数据？

我之前帮朋友改社区论坛项目时就踩过这个坑——静态类是进程级共享的，多个线程同时修改会把数据覆盖掉。后来加了个静态锁对象，比如定义private static readonly object _lock = new object();，修改数据时用lock(_lock)把赋值操作包起来，才算解决了并发问题。不过锁会影响性能，要是项目并发量不高，用这个方法没问题；如果是高并发场景， 换其他更适合的方案。

Web项目里的Session和Application对象，存数据时有啥区别？

最核心的区别是“数据归属范围”：Session是用户级的，每个用户有独立的Session容器，适合存购物车、登录Token这类“只属于当前用户”的临时数据；Application是应用级的，整个项目就一个实例，所有用户共享，像网站的全局公告、今日热门商品列表这类大家都要看的数据适合用它。另外要注意，不管用哪个，并发修改时都得加锁，不然会丢数据——我之前做企业官网时，用Application存公告就因为没加锁，导致修改后的内容没生效。

MemoryCache和Redis都能存缓存，怎么选适合自己项目的？

主要看项目的部署方式和需求：如果是单实例部署的小项目（比如个人博客、小型企业官网），用MemoryCache就够了，不用额外部署Redis，访问速度还快；但如果是多实例或微服务项目（比如负载均衡的电商系统），就得用Redis——它是分布式缓存，多个实例能共享数据，避免出现“用户换实例就看不到缓存内容”的问题。 MemoryCache重启服务器会丢数据，Redis支持持久化，要是怕数据丢，可以选Redis。

用appsettings.json存数据库连接字符串这类敏感数据，怎么保证安全？

直接明文存肯定不行，我通常用两种方法：要么用Azure Key Vault这类云服务，把敏感字段换成Key Vault的引用（比如写@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/MyDbConnStr/xxxx)）；要么用Microsoft.Extensions.Configuration.UserSecrets包，把敏感配置存在用户目录里——这样不会提交到Git仓库，更安全。要是不想用云服务，也可以用DPAPI加密配置文件的敏感部分，总之别让敏感数据“裸奔”。

微服务项目里存全局共享的用户Token，用什么方式最合适？

微服务是多实例部署的，要是用MemoryCache这类进程内缓存，每个实例的缓存是独立的，用户换实例就得重新登录。我去年做微服务项目时，用Redis存用户Token——Redis是分布式缓存，所有实例都能访问同一个Redis集群，不管用户访问哪个实例，都能读到正确的Token。而且Redis支持设置过期时间，比如Token1小时后失效，直接配置AbsoluteExpirationRelativeToNow = TimeSpan.FromHours(1)就行，比自己写过期逻辑方便多了。

YUANLEISVIP

收藏 链接