Mockito-core与Mockito-all的区别是什么？仅用Mockito-core有何局限？

嘿，这个问题问到点子上了！作为天天跟Mockito打交道的人，我来给你唠清楚mockito-core和mockito-all的区别，以及只用mockito-core会受哪些限制：

1. 本质定位完全不同 #

• mockito-core：这是Mockito的「核心骨架」，只包含最基础、最核心的Mock能力——比如创建Mock对象、设置方法返回值、验证方法调用这些日常最常用的操作。它是轻量级的基础依赖，只专注于核心Mock逻辑，没有多余的附加内容。
• mockito-all：这是个「全家桶合集」，它把mockito-core，再加上Mockito常用的附加模块、第三方依赖（比如ByteBuddy、JUnit集成模块、Hamcrest匹配器支持）全都打包在一起了，相当于给你一个一站式的大礼包，不用自己一个个加依赖。

2. 只用mockito-core的受限场景 #

如果只引入mockito-core，这些操作你没法直接搞定，得额外折腾：

• 测试框架的注解式集成：比如没法直接用@Mock、@InjectMocks这些注解配合JUnit 5（得单独加mockito-junit-jupiter依赖），或者用JUnit 4的MockitoJUnitRunner（需要mockito-junit4）。只用core的话，你得手动调用MockitoAnnotations.openMocks()来初始化注解，或者全程用静态方法创建Mock，麻烦不少。
• 高级参数匹配与部分Mock：没法直接用argThat()这类Hamcrest风格的灵活参数匹配器（得单独加mockito-hamcrest）；虽然core能手动创建Spy（部分Mock），但@Spy注解的自动初始化支持也需要集成模块才行。
• 复杂Mock场景的依赖支持：比如Mock final类、私有方法这类需要字节码增强的场景（Mockito 3+后final类Mock需要额外配置，但mockito-all已经包含了所需的ByteBuddy依赖），只用core的话会因为缺少依赖导致功能失效。
• 编译期错误检查：没法使用Mockito的ErrorProne插件在编译阶段就检查Mock代码的问题，这个插件只在mockito-errorprone里，而mockito-all已经打包了它。

3. 额外提一句：现在的最佳实践 #

其实Mockito官方早就不推荐用mockito-all了，因为它会引入一堆你可能用不上的依赖，导致项目依赖臃肿。现在的正确姿势是：只引入mockito-core，然后根据自己的需求单独加需要的附加模块——比如要JUnit 5集成就加mockito-junit-jupiter，要Hamcrest匹配器就加mockito-hamcrest，既轻量又灵活。

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