我知道这是一个非常普遍的问题，但请耐心等待我：
我刚刚在实体框架缓存（又称ChangeTracker）上绊倒。
我们所拥有的是一个使用带有实体核心的网络核心的小型微服务。这个微服务是IIS背后的负载均衡（RoundRobin）（到目前为止，我猜不到任何事情）。让我们称它们为Instance1和Instance2。
现在发生了什么：
我在数据库中有一个条目，例如（为简单起见，此处表示为JSON）：
{ Name: "Test", FirstName: "T." }
现在我将它加载到一个表单中（从Instance1回答）并将FirstName修改为Thomas并通过PUT保存它，这由Instance2完成。现在我再做一个请求来获取该条目。 Instance1会回答此请求，它将从缓存中加载此请求（因为更改跟踪器表示它未更改）。因此我得到了
{Name: "Test", FirstName: "T."}
似乎有很多人遇到了更改跟踪器的问题，一个常见的答案是每次请求都重建dbcontext，这对我来说似乎完全错误，因为这是一个非常“昂贵”的操作。
此外，我注意到新数据的插入随着时间的推移变得越来越慢，因为更改跟踪器正在填满，所以我必须每隔一段时间回收一次微服务。
所以我的问题是： 如何在不重新初始化每个请求的dbcontext的情况下解决此问题？ 我还发现了一些允许禁用缓存的答案，但仅限于单个数据库操作，这意味着我必须将此选项添加到每个数据库操作中，这对我来说几乎与每次请求重新初始化db上下文一样错误。 我忽略了什么，必须有一个简单的解决方案！
答案 0 :(得分：0)
确保使用Entity Framework的任何注入类与DbContext具有相同的生命周期。默认值为Scoped。容易犯错误，不要出汗！
请参阅本节以及底部附近的大红色警告： https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection#registering-your-own-services