为何Swagger服务未条件限定仅在开发环境注册到DI容器

这是ASP.NET Core默认模板刻意选择的设计，核心原因有三点：

• 首先要明确服务注册和中间件生效是完全独立的两个逻辑：AddEndpointsApiExplorer()、AddSwaggerGen()的作用仅仅是向DI容器注册依赖、完成Swagger生成相关的基础配置，这两个方法本身不会对外暴露任何HTTP端点，也不会在请求处理流程中插入逻辑。只要后续管道中没有调用UseSwagger()、UseSwaggerUI()去消费这些服务，注册的服务就不会被解析执行，既不会带来额外的运行时性能开销，也不存在Swagger文档泄露的安全风险。
• 其次是为了保留使用灵活性：很多场景下我们并不是只在开发环境需要Swagger相关能力——比如预发布环境联调需要临时开Swagger、集成测试需要依赖ApiExplorer探测端点元数据、内部部署的生产API需要给内网开发团队开放文档访问。如果把这两个服务注册逻辑限制在开发环境，后续要在其他环境启用Swagger时会直接抛出依赖缺失的异常，必须回头修改服务注册段的代码，反而增加不必要的改动成本。
• 最后是为了降低新手使用门槛：默认模板的设计优先规避常见使用错误。如果把服务注册也加环境判断，很多开发者第一次在非开发环境尝试开启Swagger时，很容易只记得加中间件配置、忘了补服务注册，直接遇到运行时错误，把服务注册放在环境判断外就完全避免了这个问题。

补充说明：这不是强制要求，如果你的业务场景确定永远不会在开发环境外使用Swagger，完全可以把这两个服务注册也包裹在if (app.Environment.IsDevelopment())判断块中，不会有任何功能问题，只是这种写法能节省的启动阶段开销几乎可以忽略不计。

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