Gradle扩展：简单值属性能否用普通Kotlin类型替代Property<T>？

问题背景 #

Gradle懒配置文档明确指出：在扩展/DSL类中，类似var someProperty = "default value"的普通类型属性，应当使用val someProperty: Property<String> = objectFactory.property(String::class.java).convention("default value")的方式定义，以此避免配置阶段的不必要计算。

但在实际使用中存在疑问：

• 对于简单值属性，使用普通类型似乎能减少配置阶段的少量资源消耗（少创建一个对象及方法调用），且Kotlin DSL中写法更简洁（直接用someProperty = "foo"赋值，而非命令式的someProperty.set("foo")）。
• 当前采用普通类型定义扩展属性，再在任务中通过someProperty.set(extension.someProperty)初始化对应Property<T>的方式能正常工作，但文档未提及这种用法，想知道是否存在未考虑到的弊端。

核心弊端分析 #

尽管简单值用普通类型暂时能运行，但存在以下隐性问题：

• 失去扩展与懒加载能力：当前是简单值，但后续如果需要将属性改为依赖其他动态值（比如基于项目版本、另一个扩展属性生成），普通类型无法直接适配，必须重构属性定义。而Property可以无缝切换为延迟计算模式，比如someProperty.set(project.provider { project.version.toString() })，无需修改属性的对外接口。

• 破坏DSL一致性：Gradle官方扩展、任务的属性均基于Property/Provider体系设计，自定义扩展混用普通类型会打破统一的编码规范，增加团队维护时的理解成本，其他开发者容易混淆属性的行为模式。

• 无法利用Gradle属性绑定机制：普通类型无法直接对接Gradle的系统属性、环境变量、命令行参数。比如Property可以通过someProperty.convention(project.provider { project.findProperty("my.custom.prop") as String? ?: "default" })自动读取外部配置，而普通类型需要手动编写逻辑处理，重复造轮子。

• 配置阶段的隐性风险：如果后续有人修改该属性的默认值，加入了计算或I/O逻辑，普通类型会立即在配置阶段执行，违背懒配置的初衷，可能引发构建性能问题。而Property的convention是延迟求值的，只有在任务执行或真正需要取值时才会计算。

关于简洁性的误区 #

你提到的Kotlin DSL写法简洁性问题其实已经被Gradle的语法糖解决：Property在Kotlin中支持赋值运算符重载，你完全可以用someProperty = "foo"替代someProperty.set("foo")，写法和普通类型一样简洁：

// 扩展类中定义Property<T>
val someProperty: Property<String> = objectFactory.property(String::class.java).convention("default")

// 在构建脚本中使用时，直接赋值
someProperty = "foo"

这种方式既保留了简洁的声明式风格，又能享受Property的所有优势。

总结 #

虽然简单值用普通类型暂时能工作，但从可维护性、扩展性、遵循Gradle设计理念的角度出发，推荐始终使用Property定义扩展/DSL属性。Kotlin DSL的语法糖已经解决了简洁性问题，没必要为了一时的微小性能收益（实际可忽略），放弃长期的代码健壮性与扩展性。

内容的提问来源于stack exchange，提问作者Rolf W.