EF Core+SQL Server下使用JSON Patch的限制及适配方案咨询

咱们先聊聊你遇到的问题——其实JSON Patch本身并不是不适用于SQL Server后端的EF Core，只是默认的实现和EF Core的变更追踪机制之间存在一些衔接上的坑，尤其是集合导航属性的处理。下面我分几个部分给你梳理清楚：

一、EF Core 中使用标准 JSON Patch 的核心局限性 #

• 集合导航属性的删除操作不触发实体删除：这正是你碰到的问题。标准的JSON Patch remove操作只是把对象从内存中的数组/集合里移除，但EF Core的变更追踪并不会自动把这些被移除的实体标记为Deleted状态——因为它没法区分你是要彻底删除实体，还是只是取消关联（比如多对多关系里的中间表记录）。所以SaveChanges的时候，数据库里的实体依然存在。
• 复杂对象图的变更识别有限：如果你的对象层级很深（比如嵌套了多层导航属性），JSON Patch的操作路径会变得非常复杂，而且EF Core的变更追踪在处理深层嵌套实体时，可能无法正确识别所有变更，尤其是当嵌套实体没有明确主键或者关联关系配置不完整时，很容易出现变更不生效的情况。
• 缺乏内置的并发冲突处理：标准JSON Patch没有集成EF Core的并发令牌（比如[Timestamp]属性）支持，你得手动在Patch操作前检查实体的并发状态，否则很容易出现覆盖更新的问题，导致数据冲突。
• 大数据量集合操作性能差：默认的JSON Patch依赖EF Core的内存变更追踪，对于大量集合元素的增删改，需要先把所有实体加载到内存中，再应用Patch，最后批量保存，性能远不如EF Core原生的ExecuteUpdate/ExecuteDelete这类直接操作数据库的命令。

二、针对你遇到的集合删除问题的解决思路 #

原因拆解 #

fast-json-patch生成的是标准JSON Patch的remove指令，而ASP.NET Core自带的JsonPatchDocument应用到实体时，只修改内存集合，不会主动通知EF Core去删除实体。要解决这个问题，得让EF Core知道哪些实体需要被标记为删除状态。

可行方案 #

• 手动对比集合差异：在应用Patch之前，先获取原始集合的快照（比如从DbContext里加载原始实体的集合），应用Patch之后，对比两个集合找出被移除的实体，然后调用context.Set<YourEntity>().RemoveRange(removedEntities)来标记这些实体为删除，最后再SaveChanges。
• 使用EF Core专属的JSON Patch库：有专门针对EF Core优化的第三方实现，比如EntityFrameworkCore.JsonPatch，它会自动识别集合中被移除的实体，并将其标记为Deleted状态，让EF Core在SaveChanges时同步删除数据库里的记录，完美解决你现在的问题。
• 自定义Patch操作：扩展JsonPatchDocument，添加一个自定义的delete操作（区别于标准的remove），在处理这个操作时，直接操作DbContext来标记实体为删除状态。这种方式灵活性高，但需要自己实现操作解析逻辑。

三、其他可用的JSON Patch实现 #

除了上面提到的EntityFrameworkCore.JsonPatch，还有几个选项可以考虑：

• JsonPatchPlus：扩展了标准JSON Patch的功能，支持更多针对实体框架的操作，比如关联实体的自动处理、并发令牌验证等，适配EF Core的场景更友好。
• 手动解析Patch操作：如果你的业务需求比较特殊，可以直接解析JSON Patch的操作数组，然后手动操作DbContext来标记实体的状态（Added/Modified/Deleted）。这种方式完全可控，但开发量相对较大，适合定制化需求强的场景。

总的来说，JSON Patch在EF Core + SQL Server的场景下是完全可用的，只是默认实现没有处理EF Core特有的实体状态追踪逻辑，通过合适的工具或者自定义逻辑，就能解决你遇到的集合删除问题。

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