Testcontainers的shaded依赖：用内置还是显式添加至pom.xml？

不建议直接使用Shaded依赖的原因 #

• API稳定性无法保证：Testcontainers打包的shaded依赖是供自身内部使用的，官方不会对外承诺这些依赖的版本、包路径或者API会保持兼容。一旦Testcontainers升级，可能直接替换甚至移除这些shaded依赖，你的代码会直接出现编译或运行错误。
• 调试与排查问题更麻烦：shaded后的包名是嵌套的（比如org.testcontainers.shaded.org.awaitility.Awaitility.await），IDE的自动补全、官方文档提示都会失效，排查日志时也容易因为非标准包名增加混淆成本。
• 潜在的依赖冗余与行为差异：如果你的项目同时显式添加了同一依赖（比如Awaitility），但版本和Testcontainers的shaded版本不一致，虽然不会出现直接的包冲突，但项目里会同时存在两个版本的同一库，既增加了包体积，还可能因为两个版本的行为差异导致难以定位的bug。

显式添加依赖的优势 #

• 依赖完全可控：你可以自主选择依赖的版本，掌握更新节奏，不会因为Testcontainers的升级被迫同步变更依赖版本。
• 生态兼容性更好：使用官方标准包名的依赖，能和静态代码检查、测试报告生成等工具完美配合，不会因为非标准路径出现识别问题。
• 项目维护更清晰：团队其他开发者看到pom.xml里显式声明的依赖，能立刻明确项目的依赖结构，而shaded依赖会让人误以为是Testcontainers内部实现，增加理解成本。

结论 #

最佳实践是在pom.xml中显式添加所需的依赖，而非依赖Testcontainers提供的shaded版本。这种方式能避免潜在的兼容性风险、调试障碍，同时让项目的依赖管理更透明可控。

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