IMemoryCache 在 .NET Core / .NET 5+ 中必须注册才能用
直接 new
MemoryCache实例是错的——它不走依赖注入生命周期管理，且缺少默认过期策略和内存压力响应机制。正确做法是在
Program.cs（.NET 6+）或
Startup.ConfigureServices中调用
AddMemoryCache()：
services.AddMemoryCache(options => { options.SizeLimit = 1024; }); —— 可选设置总大小上限（单位为任意“大小单位”，需配合 ICacheEntry.SetSize()使用 不配置时，默认无硬性大小限制，但会响应 GC 和内存压力自动逐出 注册后，控制器或服务中通过构造函数注入
IMemoryCache即可，无需手动管理实例
缓存读写要处理 null 值和并发竞争
GetOrCreateAsync是最安全的写法，尤其适合数据库查库后缓存的场景；而
Get+
Set组合在高并发下可能重复生成值（缓存击穿）。 推荐用
cache.GetOrCreateAsync("key", async entry => { entry.SlidingExpiration = TimeSpan.FromMinutes(10); return await GetDataFromDb(); })
entry.AbsoluteExpirationRelativeToNow和
SlidingExpiration不能同时设，后者优先级低但更常用 如果缓存的是
null，
Get返回
null无法区分“没命中”和“存了 null”，建议改用
TryGetValue+ 包装类型（如
int?）或约定哨兵值
缓存项过期后不会立即释放内存
IMemoryCache的过期是惰性的：只有在访问时检查是否过期，或后台线程定期扫描（默认 1 分钟间隔）。这意味着： 过期项仍占用内存，直到被访问触发清理或后台线程扫描到 大量短时效缓存（如秒级）可能导致扫描线程压力上升，可通过
options.CompactionPercentage = 0.1调整扫描频率和清理比例 主动清理用
cache.Remove("key") 或 cache.TryGetValue("key", out var v) && cache.Remove("key")，但不要在热路径频繁调用
缓存对象必须是线程安全的，尤其注意引用类型修改
IMemoryCache存的是引用，不是深拷贝。如果缓存了一个
List<string></string>并在外部修改它，所有读取方都会看到变化——这通常不是预期行为。 读取后需要修改，应先
new List<string>(cachedList)</string>或用
ToList()缓存 DTO 或配置类时，确保其属性不可变（
init、
get;only），或返回只读包装（
AsReadOnly()） 避免缓存
DateTime.Now这类动态值；要用就缓存计算结果，或用工厂委托延迟求值 缓存键的设计、对象序列化成本、以及跨请求共享状态的边界，比语法本身更容易出问题。别只盯着
Set和
Get，多看一眼你塞进去的东西到底“活”成什么样。
