Gradle依赖解析中constraint的作用是什么？和自动版本仲裁有什么区别？

你举的两个示例只是在特定场景下最终解析结果一致，两者的底层逻辑和适用场景有本质差异，核心区别如下：

• 是否会主动引入依赖
  直接声明implementation('io.github.elye:simplekotlinlibrary:3.0.0')属于显式依赖声明，无论项目其他依赖是否用到该库，它都会被强制加入项目的构建classpath中。
  而constraints约束仅对已经存在的依赖生效：如果后续你移除了easyandroidlibrary和simpleandroidlibrary这两个依赖，没有其他地方引入simplekotlinlibrary的话，约束不会主动把该库加入项目，你未声明版本的implementation('io.github.elye:simplekotlinlibrary')还会因为缺少版本号报错。
• 作用范围覆盖传递依赖
  如果你的项目不需要直接调用simplekotlinlibrary的代码，只是要统一它的传递依赖版本：用constraints不需要显式声明该库的直接依赖就能锁版本，不会在项目里引入多余的直接依赖；而不用constraints的话，你只能手动加一个高版本的直接依赖来覆盖传递依赖，平白增加了不必要的直接依赖声明。
• 支持更灵活的版本控制规则
  constraints支持严格版本锁定、版本区间限制等规则：比如你可以配置严格锁定simplekotlinlibrary为3.0.0，哪怕后续有其他传递依赖引入了更高的4.0.0版本，Gradle也会强制使用3.0.0，甚至会直接报错提示版本冲突；而直接声明依赖的话，Gradle默认还是会遵循「取最高版本」的规则，会被更高的传递依赖版本覆盖。
• 便于依赖管理与问题排查
  constraints支持通过because字段标注版本锁定的原因，后续执行./gradlew dependencies排查依赖问题时，可以直接看到版本被调整的原因，方便团队协作维护；而直接声明高版本依赖的话，其他开发者无法判断这是业务需要的直接依赖，还是为了解决冲突加的覆盖依赖。

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