FastAPI 0.142.0 因平台 OTEL 环境变量启动失败

FastAPI 从 0.141.0 升到 0.142.0，业务代码没变，应用却在启动阶段退出，日志提示 Automatic OpenTelemetry export requires fastapi[opentelemetry] or fastapi[standard]。如果部署平台统一注入了 OTEL_EXPORTER_OTLP_ENDPOINT，先核对 FastAPI 的自动遥测配置，不要先改监听端口或健康检查。

这条回归有 Python 3.11、Pydantic 2.13.5 的触发记录。0.142.0 会根据进程里的 OpenTelemetry 环境变量尝试自动配置；缺少对应可选依赖，或变量指定了该自动配置路径不支持的导出方式，都可能让启动失败。平台为所有工作负载设置一个变量，并不等于每个应用都已准备好这套导出组件。

0.142.2 已允许自动配置失败后继续启动

FastAPI 0.142.2 的正式修复改变了这项失败处理。保留当前依赖锁文件，在兼容项目的正式版本中采用包含该修复的版本，再重建实际部署环境。只在开发机升级、服务镜像仍带着 0.142.0，不会改变故障进程。

核对平台传入的变量名称及协议即可，日志或工单不应公开带凭据的导出地址。应用已经自行配置 tracer、meter 或 logger provider 时，也要确认是否又触发了一次自动配置。不要为了让服务起来，直接删除整个平台共用的 OTEL 环境变量；同一进程的其他组件可能需要它们。

升级解决的是“自动配置失败导致应用无法启动”。它不保证数据已经送到采集器。应用恢复提供接口后，如果遥测本来是必需能力，还要检查导出错误、采集器收到的数据和原有告警。

由应用自行管理遥测时，明确关闭自动配置

项目有自己的 provider 初始化，或者本来就不需要 FastAPI 自动创建导出器，可以在原有应用构造位置明确指定：

from fastapi import FastAPI

app = FastAPI(telemetry={"auto_configure": False})

这是构造参数片段。已有 lifespan、中间件、依赖和路由配置应保留在同一个应用实例上，不能为了加一个参数重新建实例，把原初始化覆盖掉。这个选项关闭自动配置，不等于删除应用自行管理的 provider，也不应被当成满足遥测交付要求的证明。

确实希望使用自动导出时，应按项目的包管理方式安装相应 extra，并让协议和导出器配置与所选版本支持范围一致。只看到缺包提示就安装依赖，仍可能遇到不支持的协议；反过来，故意不采集的应用也没有必要仅为启动安装整套导出组件。

把启动与采集分开验收

在保留相同平台环境变量的受控部署中，检查启动完成、业务路由和正常停止。若项目需要遥测，再确认一次真实业务请求能够产生预期数据。若仍在启动退出，按新的完整异常定位；不能把数据库初始化失败也归到 OTEL。

保留原镜像和锁文件，便于恢复整套依赖。配置改为自行管理后，应在项目原来的生命周期中创建和关闭 provider，避免服务能启动却遗留导出线程或重复注册。