IIS启动Swagger UI报Failed to load API，指定类命名空间仍报错原因

• 你在方法签名里显式指定返回值为File1.Data，只解决了C#编译器层面的类型识别问题——编译器能明确匹配到File1下的Data类，保证项目可以正常编译运行，但这个改动完全不会影响Swagger生成接口文档的底层逻辑，因此报错不会消失。
• 本地IIS启动时加载的Swagger能力由Swashbuckle组件提供，它生成接口数据Schema的默认规则，是取类型的短类名（即不带命名空间前缀的类名，File1.Data和File2.Data的短类名都是Data）作为全局唯一的Schema ID。组件通过反射扫描程序集生成文档时，只要碰到两个短类名相同的类型，不管二者分属哪个命名空间、内部属性差异多大，都会尝试向Schema集合中注册两个ID为Data的条目，直接触发ID重复异常，中断整个文档生成流程。Swagger UI拿不到完整的接口定义结构，就会弹出「Failed to load API」报错。
• 你修改其中一个重名类的类名后，两个类型的短类名不再重复，Swagger生成Schema时不会出现ID冲突，文档可以正常渲染，问题就彻底解决了。

如果不想调整原有业务类的命名，也可以通过修改Swagger配置自定义Schema ID生成规则，直接使用类型的全限定名作为ID，从配置层面规避同名类冲突，配置代码如下：

// Program.cs中Swagger服务配置段
builder.Services.AddSwaggerGen(options =>
{
    // 用类型全限定名作为Schema ID，解决不同命名空间下同名类的冲突问题
    options.CustomSchemaIds(type => type.FullName);
});

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