-D参数本质是传给JVM的系统属性，而非project属性；需用System.getProperty()读取，不能用hasProperty()检测，且优先级高于gradle.properties中的systemProp.配置。
Gradle -D参数本质是传给JVM的系统属性，不是传给build.gradle脚本的project属性
很多人误以为 -Dkey=value 会自动变成 project.ext.key 或能被 project.hasProperty("key") 检测到，其实不会。它只注入到启动 Gradle 的 JVM 进程里，等价于 Java 启动时的 -D 参数。你得用 System.getProperty("key") 去读取，而不是 project.findProperty("key")。
常见错误现象：
- 在
build.gradle里写if (hasProperty("myflag")) { ... }，但gradlew -Dmyflag=true build不生效 - 期望
-Dhttp.proxyHost=127.0.0.1能让 Gradle 自动走代理，却没配-Dhttps.proxyPort导致 HTTPS 请求失败
哪些场景必须用 -D，不能用 -P
需要影响 JVM 层行为或底层库初始化逻辑时，-D 是唯一可靠方式。典型包括：
- HTTP(S)/SOCKS 代理配置：如
-Dhttp.proxyHost、-Dhttps.proxyPort、-DsocksProxyHost - JVM 内存/垃圾回收参数：虽然不常用在命令行，但
-Dfile.encoding=UTF-8这类会影响字符串处理的行为 - 某些插件或测试框架依赖的系统级开关：比如
-Dorg.gradle.parallel=true（注意：这个其实是 Gradle 自己识别的特殊 key，非通用） - Java 安全策略、SSL 系统属性（如
-Djavax.net.ssl.trustStore）
而 -P 只进 project 对象，对 JVM 本身无感——比如你 -Pdebug=true，再在 build.gradle 里用 if (debug) { ... } 没问题；但想让 Log4j 读到这个值去切日志级别？不行，Log4j 只认 System.getProperty。
容易混淆的 gradle.properties 中 systemProp. 前缀
在 gradle.properties 文件里写 systemProp.http.proxyHost=127.0.0.1，效果等同于命令行加 -Dhttp.proxyHost=127.0.0.1，都是设为 JVM 系统属性。但注意：
- 这个前缀
systemProp.是 Gradle 解析gradle.properties时做的特殊识别，仅在此文件中有效 - 不能写成
http.proxyHost=127.0.0.1（缺前缀）——那样只是普通 Gradle 属性，进不了 JVM - 命令行
-D优先级高于gradle.properties中的systemProp.配置
验证是否生效最直接的方式：在 build.gradle 里加一行 println "proxy host: ${System.getProperty('http.proxyHost')}"，跑一遍就清楚了。
为什么 -D 有时像“没起作用”？检查这三点
-D 失效往往不是语法错，而是作用域或时机问题：
- 代理类属性必须成对出现：设了
-Dhttp.proxyHost却没设-Dhttp.proxyPort，JVM 默认用 80，可能连不通 - HTTPS 流量默认走
https.proxy*，不是http.proxy*；很多公司只配了 http 代理，结果 HTTPS 仓库拉不到依赖 - Gradle 守护进程（daemon）会复用 JVM 进程：改了
-D参数后没加--no-daemon或执行gradle --stop，旧 JVM 还在跑，新参数根本没加载
复杂点在于：同一个 -D key，在不同上下文里含义可能完全不同——比如 -Dorg.gradle.jvmargs 是给 Gradle 自己的 JVM 加参数，而 -Dfile.encoding 是给构建过程中所有 JavaExec 任务用的。传之前，先想清楚这个属性最终被谁消费。
