Zipkin Server 启动时创建 armeriaServer 失败，不能只盯最外层 BeanCreationException。2019 年一次自建 Spring Boot 集成中，异常链最终落在 Zipkin UI 自动配置的空指针；依赖组合比复制整段反射堆栈更有定位价值。
把异常链压到关键位置
原记录的核心部分是：
BeanCreationException: Error creating bean with name 'armeriaServer'
BeanInstantiationException: Factory method 'armeriaServer' threw exception
Caused by: java.lang.NullPointerException
at zipkin2.autoconfigure.ui.ZipkinUiAutoConfiguration
.lambda$uiServerConfigurator$0(ZipkinUiAutoConfiguration.java:179)Bean 名称说明哪一步创建失败；最内层异常与所在方法才帮助缩小范围。仅凭 lambda 的行号不能确定哪个值为 null，还需要精确匹配当时源码、构建和配置。
当次日志能确认哪些版本
| 组件 | 原日志版本 |
|---|---|
| Spring Boot | 2.1.7.RELEASE |
| Spring Framework | 5.1.9.RELEASE |
| zipkin-autoconfigure-ui | 2.12.9 |
| armeria-spring-boot-autoconfigure | 0.83.0 |
| Java | 1.8.0_181 |
旧记录随后把 Zipkin 版本降到 2.12.3，启动恢复。这是一次历史处理结果，不是当前版本选择建议，也没有完整依赖树能确认所有传递依赖变化。
引擎迁移是事实，全版本冲突不是
上游 Zipkin 2.12.6 发布说明确实记录了迁移到 Armeria HTTP 引擎。但它并没有说所有新版都不能与 Spring Boot 配合，因此不能从这次故障推出统一的版本禁用分界。
2.12.9 UI 配置源码提供 uiServerConfigurator 的相关处理。源码阅读可以帮助建立候选原因，不能代替缺失的原配置与运行对照。
比持续降级更有用的检查
保留完整 POM、有效依赖树、启动参数和配置，再对比失败与成功制品。优先确认是否需要自建嵌入式 Server，还是使用官方独立 Server 更符合部署方式；独立运行的历史示例见Zipkin RabbitMQ 接收链路。
验证除了进程启动，还应覆盖 UI、链路接收和查询。退回某个旧版本只是缩小差异或临时绕过，不足以证明根因已找到，更不能忽略维护与安全更新。