迁移至自定义BotState服务：需排查哪些隐式调用遗漏步骤？

看起来你已经完成了核心的迁移步骤，但还有几个容易被忽略的点可能导致SDK仍在调用默认状态服务，我帮你梳理一下：

• 清理残留的StateClient引用：除了停用依赖注入的StateClient类型，还要全局搜索代码库，看看有没有手动实例化StateClient的地方（比如直接new StateClient(credentials)），或者有没有调用StateClient的方法（比如GetBotState()、SetUserDataAsync()这类），这些旧代码片段很容易被漏掉。

• 检查第三方组件/中间件的依赖：如果你的bot使用了第三方对话框、中间件或者自定义组件，有些旧组件可能内部硬编码了对默认状态服务的调用。需要检查这些组件的实现逻辑，比如某些旧的表单对话框可能会直接用StateClient存取数据，得把它们改成用IDialogContext的ConversationData/PrivateConversationData/UserData。

• 确认SDK版本与配置清理：

  • 如果你用的是Bot Framework v3，确保升级到支持自定义状态存储的最新稳定版，旧版本可能存在默认 fallback 逻辑。同时清理配置文件（比如Web.config）里的StateEndpoint相关配置项，这些配置会触发SDK指向默认状态服务。
  • 如果是v4，检查启动代码里是否还在使用默认的UseState()中间件，要替换成绑定Cosmos DB状态存储的配置（比如AddBotState()搭配CosmosDbPartitionedStorage），避免默认中间件偷偷调用旧服务。

• 排查对话栈与序列化逻辑：如果你的bot使用了自定义对话序列化，或者某些对话框的ResumeAsync方法里有遗留的状态存取逻辑，可能也会间接调用默认服务。要确保所有状态操作都通过IDialogContext的属性来完成，而不是绕开自定义存储。

• 清理测试/调试残留代码：有时候测试用例或者调试代码里会保留旧的状态调用逻辑，比如单元测试中手动模拟StateClient，这些在生产环境运行时也可能触发调用，记得清理这类代码。

按照这些点逐一排查，应该就能彻底切断对state.botframework.com的调用了。

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