gradle daemon内存不足需区分报错类型：仅outofmemoryerror才调堆内存，临时用-dorg.gradle.jvmargs="-xmx2g -xx:maxmetaspacesize=512m"验证，永久配置须写入gradle.properties（非settings.json），改后需关闭vscode窗口生效。
VSCode 里运行 Kotlin 程序触发的 Gradle 守护进程（Daemon）内存不足，不是 VSCode 本身的问题，而是 Gradle 子进程在后台启动时堆内存默认太小——尤其 Kotlin + Android 或多模块项目，tsserver、Gradle Daemon、kotlinc 三者叠加，1.4GB 默认上限很快打满。
Gradle Daemon 启动失败前先看报错类型
打开 VSCode 内置终端执行 ./gradlew build 或运行 Kotlin 脚本时，注意错误是否含以下关键词：
-
java.lang.OutOfMemoryError: Java heap space→ 确认是 Daemon 堆内存不足 -
Could not connect to the Gradle daemon→ 很可能是旧 Daemon 卡死或端口被占，不一定是内存问题 -
Unable to start the daemon process→ 多数由-Xmx配置缺失或冲突导致
只有明确出现 OutOfMemoryError 才需调内存；否则优先走「清理残留进程」流程。
临时验证：命令行加 -Dorg.gradle.jvmargs
别改全局配置，先用单次命令快速验证是否有效：
./gradlew build -Dorg.gradle.jvmargs="-Xmx2g -XX:MaxMetaspaceSize=512m"
说明：
-
-Xmx2g是核心，设为 2GB（Kotlin 编译器本身吃内存，低于 1.5g 容易崩） -
-XX:MaxMetaspaceSize=512m防止元空间溢出，尤其用了大量注解处理器时 - 值不建议直接写
-Xmx4g：超过 3g 后收益急剧下降，且可能挤占其他进程（如tsserver）资源 - 该参数只作用于本次构建的 Daemon 进程，不影响 VSCode 主进程或 Extension Host
永久生效：配 gradle.properties（非 settings.json）
VSCode 的 settings.json 对 Gradle Daemon 完全无效。必须在用户级或项目级 gradle.properties 中配：
路径：
- 全局（所有项目）：
~/.gradle/gradle.properties - 项目级（推荐）：项目根目录下的
gradle.properties
内容（仅一行）：
org.gradle.jvmargs=-Xmx2g -XX:MaxMetaspaceSize=512m
注意：
- 不要加引号，不要换行，不要空格多余
- 如果已有
org.gradle.jvmargs行，直接覆盖，别追加 - 改完后必须关闭当前 VSCode 窗口（不只是 reload），否则旧 Daemon 进程仍用旧参数
Kotlin 特定场景：PicoCLI 或 Ktor 项目常卡在 Daemon 初始化
某些 Kotlin 框架（如用 picocli 启动 CLI 工具、ktor-server 带大量反射扫描）会在 Daemon 预热阶段就耗尽内存。此时需额外加参数：
org.gradle.jvmargs=-Xmx3g -XX:MaxMetaspaceSize=768m -XX:+HeapDumpOnOutOfMemoryError
说明：
-
-Xmx3g是临界点，2g 在复杂反射场景下仍不够 -
-XX:+HeapDumpOnOutOfMemoryError会生成java_pid*.hprof文件，方便后续用 VisualVM 分析泄漏源头 - 别在
NODE_OPTIONS或VSCODE_NODE_OPTIONS里设这些——它们只影响 Node 进程，对 Gradle Daemon 无效
真正容易被忽略的是：Gradle Daemon 和 Kotlin 编译器（kotlinc）是两个独立 JVM 进程，前者管构建生命周期，后者管字节码生成；org.gradle.jvmargs 只控制前者，若编译阶段崩了（比如 kotlin-gradle-plugin 报错），得去查 kotlinOptions.jvmTarget 或升级插件版本。
