关于Dataverse插件实例缓存机制的疑问：每次执行生成不同GUID，执行模型是否已变更？

首先得说，你的这个观察真的很细致，我完全理解你看到和文档描述不符的结果时的困惑——毕竟依赖实例缓存的设计模式在过去确实是不少开发者会用到的，现在突然不生效了肯定会慌。

咱们一步步拆解这个问题：

• 先澄清文档的真实含义：微软文档里说的"平台会缓存插件类实例，构造函数不会在每次调用时执行"，重点是「不会在每一次调用时执行」，而不是「第一次执行后永远不会再执行」。缓存是平台的一种性能优化策略，不是强制的、有保障的行为。平台完全有权根据资源负载、沙盒进程状态等因素决定是否复用实例，而不是必须复用。

• 沙盒模式的影响是关键：你用的是沙盒模式的插件，这类插件运行在Dataverse的隔离沙盒进程中。在开发环境这种低负载场景下，平台通常不会长时间保留空闲的沙盒进程——如果每次执行请求过来时，没有可用的空闲沙盒进程，就会启动一个新的进程，而每个沙盒进程都会创建新的插件实例，自然每次的GUID都不一样。要是你在高负载的生产环境测试，短时间内多次触发插件，大概率能看到实例复用的情况（同一个GUID出现多次）。

• 关于2025年的执行模型变更：目前没有官方宣布插件缓存机制的重大变更，但平台的资源调度逻辑是会持续微调的。比如为了提升隔离性或者优化资源利用率，可能调整了沙盒进程的回收策略，导致实例复用的场景比以前少了，但核心的插件执行模型（要求无状态）并没有变。

• 给你设计上的建议：不管现在缓存是否生效，都应该彻底摒弃依赖实例级字段保存状态的设计——这也是Dataverse插件开发的核心原则。所有需要的上下文数据都要从IServiceProvider获取，跨步骤的状态用ExecutionContext的SharedVariables来传递。依赖实例缓存本来就是不可靠的，因为平台的缓存策略是黑盒，随时可能变化。

总结一下：文档没有完全过时，只是描述的是平台的最优缓存行为，不是绝对保证；你看到的情况是沙盒进程调度逻辑导致的，不是执行模型的根本性变更；插件设计一定要坚持无状态原则，不要依赖实例缓存。

内容来源于stack exchange