主要观点：作者前几天在 Go 语言中创建了一个整洁的小模式，通过为不同状态暴露不同 API 来表示系统中的状态变化，且仅在单个底层结构中持有状态，不确定是否为首创，若有相关名称请告知；展示了该模式的代码实例及动机，模式中Resolver和Resolved可由同一结构体实现，还提到了使用该模式的场景及与Builder模式的区别。

关键信息：

• Resolver接口用于收集数据和添加上下文数据，执行后可发送批量查询进行查找；Resolved接口用于获取查找结果；Executor接口用于执行实际的数据查找操作。
• idResolver结构体实现了Resolver和Resolved接口，通过Collect、AddContextualData、Execute和Resolve方法进行数据收集、执行查询和获取结果。
• 为避免逻辑混乱，添加了hasExecuted布尔变量来检查是否在执行前或执行后进行了错误的操作。
• 讨论了何时使用该模式，认为在处理单个对象时该模式很合适，其关键在于对象在不同状态下有不同操作，Go 接口能很好地暴露这种状态变化。
• 有人指出该模式与Builder模式相似，但认为两者有不同，此模式更通用且目的不同。

重要细节：

• DoTheThing方法用于执行实际的数据查找操作，接收上下文、要查找的 ID 映射和上下文数据作为参数，返回查找结果和错误。
• transformResult函数用于将执行结果进行转换。
• 在StatefulIdResolver中，Collect方法在执行后调用会 panic，Execute方法执行后会设置hasExecuted为 true，Resolve方法在未执行前调用会 panic。