Gradle Isolated Projects 启动卡住，检查 worker 数与嵌套构建数

开启 Gradle Isolated Projects 后，构建卡在启动配置阶段，日志几乎不再推进，可以比较 worker 上限与构建树里的 build 数量。具体报告在 Gradle 9.7.1 中，worker 数等于或小于 build 数时出现冻结，增加上限可以绕开原复现条件。

这里的 build 不等于普通子项目数量。一个根构建里的多个 project 与 included build、构建逻辑构建，是不同层级；不能把 settings 中所有子项目简单相加就认为得到了准确阈值。先记录实际复合构建结构、原命令和 worker 配置。

受影响路径在按需配置项目时使用额外 readyQueue，等待某个项目配置完再安排下一批；多个构建占据有限 worker 时，这种等待安排可能无法继续推进。Gradle 9.8.1 的正式代码仍保留该等待结构。已有调整调度队列契约的补丁，不代表它已进入这个正式版本，不能据此承诺升级就解决。

先在资源允许的测试构建中做容量对照，例如：

./gradlew <原任务> --max-workers=8 --info

8 只是示例，应选择高于已知构建树 build 数、且机器可以承受的值。原任务也要替换；保留其他 Isolated Projects 与构建参数，这样才能判断改变容量是否对同一配置路径有影响。不要顺手开启或关闭多个缓存选项，把差异混在一起。

确认有效后，可以在项目的 gradle.properties 中设置对应上限：

org.gradle.workers.max=8

已有值和机器资源必须先核对。CI 容器的 CPU、内存限制与开发机不同，不能把本机能承受的并行量直接推给所有 runner。增加 worker 也不会给缺失的插件、失败的配置脚本或外部进程提供正确结果。

若构建仍停住，保存线程转储与最后的配置日志，查看是否仍在项目配置等待路径。任务自己等待外部服务、插件锁死、下载阻塞或另一个工作队列耗尽，会呈现相似的“没有输出”，不能继续无限提高上限。

验收要使用原复合构建和原任务，覆盖低上限的定位对照及选定容量下的完整结束；再重复一次已有缓存的构建，确认没有只是偶然避开等待。记录 wrapper 版本、实际 worker 值与 included build 结构，方便在 CI 中复查。

这是一条针对已确认条件的临时配置办法，正式完整修复版本仍未确认。即使容量对照恢复，也不应认定所有 Isolated Projects 冻结都由同一原因造成；后续采用正式补丁版本时，仍要用原低容量条件重新检查，才能知道是否可以恢复较低的并行设置。