Gradle本身不提供开箱即用的文件监听+自动构建机制，需依赖--watch（Gradle 8.4+）或外部工具如fswatch/chokidar触发gradlew，且任务必须正确定义inputs/outputs。
Gradle 本身不提供开箱即用的文件监听 + 自动构建机制，它不是像 Webpack 或 Spring Boot DevTools 那样的热重载工具。所谓“监听文件变化并自动构建”，必须靠外部手段触发 gradlew，或借助 Gradle 的 --continuous 模式（已弃用）或 --watch（Gradle 8.4+ 新特性）实现近似效果。
用 --watch 启动持续构建（Gradle 8.4+）
这是目前最接近“监听 + 自动构建”的官方方案，但需注意它只监听任务的输入文件（inputs.files），不是任意路径。
- 确保你用的是 Gradle 8.4 或更高版本（
./gradlew --version查看） - 任务必须正确定义输入输出，例如
compileJava、processResources天然支持；自定义任务需显式声明：tasks.register('myTask', MyCustomTask) { inputs.files(fileTree('src/main/resources')) outputs.dir(layout.buildDirectory.dir('generated')) } - 执行命令：
./gradlew build --watch，修改被监听的输入文件后，Gradle 会自动重新运行受影响的任务 - 不监听
build.gradle变化——改脚本需手动重启--watch
监听任意路径？得靠外部工具触发 gradlew
如果你要监听 config.json、version.properties 或非标准资源目录，Gradle 不会自动感知，必须引入外部 watcher。
- Linux/macOS 推荐
fswatch：fswatch -o config.json | xargs -n1 -I{} ./gradlew build - Windows 可用
PowerShell的FileSystemWatcher，或安装chokidar-cli：npx chokidar 'config.json' --on-change './gradlew build' - 关键点：这类方式每次都会启动全新 Gradle 进程，无法复用配置/构建缓存上下文，比
--watch开销大 - 避免无限循环：确保构建产物（如生成的
build/下文件）不在监听范围内
为什么 --continuous 被弃用，以及替代陷阱
Gradle 7.0 标记 --continuous 为废弃，8.0 正式移除。它的问题很实际：
- 监听逻辑粗粒度，容易误触发（比如 IDE 保存临时文件）
- 不区分文件变更是否真影响任务输入，常导致无意义重建
- 与构建缓存（
org.gradle.caching=true）协同差，频繁跳过缓存校验 - 若任务没正确定义
inputs/outputs，--watch也无效——这是最容易忽略的前提
真正稳定可靠的“响应式构建”，核心不在监听本身，而在于让每个任务清晰声明自己关心什么文件、产出什么结果。否则，任何 watcher 都只是在盲扫。
