Teams Toolkit搜索型消息扩展选结果未返回Adaptive Card问题

这个问题属于Teams Toolkit开发上线阶段的高频坑，本地调试正常、搜索阶段正常仅选中结果空白，核心故障范围全部集中在卡片渲染环节的生产环境校验逻辑，和搜索接口本身无关，本地调试时Toolkit内置的隧道和模拟器会跳过大量生产环境强校验规则，所以不会复现问题。

已验证的高频诱因与修复方案 #

• 诱因1：卡片引用资源域名未加入合规列表
  生产环境下Teams会强制校验Adaptive Card内所有引用资源（图片、图标、跳转链接域名）是否在应用manifest的validDomains配置内，只要有一个域名不在列表中，整个卡片会被直接拦截渲染，且不会弹出显性错误提示，表现为输入框完全空白。
  修复步骤：
  1. 导出选中结果接口返回的完整Adaptive Card JSON，梳理所有外链资源对应的根域名
  2. 将所有根域名加入manifest的validDomains数组，不要使用*通配符配置域名，生产环境下带通配符的域名规则会被判定为无效直接忽略
  3. 重新打包manifest上传更新Teams应用，等待10-15分钟客户端缓存失效后重试
• 诱因2：选中结果的响应格式不符合生产环境Schema要求
  本地调试模拟器对响应格式的容错率远高于线上Teams服务，常见格式问题包括：
  • 响应体中composeExtension字段层级错误，attachments、attachmentLayout字段未放置在正确层级
  • Adaptive Card的$schema字段指向了本地调试地址、不可公网访问的内网地址
  • 卡片的contentType字段取值错误，选中结果返回的卡片必须使用application/vnd.microsoft.card.adaptive作为contentType，不能使用通用JSON类型
  • Adaptive Card版本设置过高，线上客户端不兼容，建议固定使用1.4版本的Adaptive Card schema保证跨端兼容性
    排查方式：直接在Azure应用的日志中抓取composeExtension/selectItem请求的完整响应，和官方要求的响应结构逐字段对比即可定位问题
• 诱因3：Azure侧服务响应头配置错误
  如果部署时前置了API Management、CDN或者反向代理，以下配置问题会直接导致卡片加载失败：
  • 接口响应未携带Content-Type: application/json; charset=utf-8头
  • 响应头配置了X-Frame-Options: DENY或者限制性过强的内容安全策略（CSP），拦截了Teams客户端的卡片加载请求
  • 接口响应耗时超过3秒，超过Teams invoke请求的超时阈值，客户端会直接丢弃响应展示空白
• 诱因4：后端逻辑因环境变量缺失返回空卡片
  很多开发者在本地调试时硬编码了卡片模板路径、卡片内容配置，部署到Azure后没有配置对应的应用设置，导致选中结果时后端返回了空的attachments数组，直接检查对应接口的返回值即可确认。

快速排查技巧：将接口返回的完整Adaptive Card JSON复制到Teams开发者后台自带的卡片编辑器中渲染，如果可以正常展示，即可排除卡片内容本身的问题，直接排查域名配置、响应头、manifest配置三类问题即可。

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