Grails 3.3.1中resources.groovy定义的Bean重载后属性为空问题

这个问题本质是Grails热重载机制在重新创建ApiService实例时，没有重新绑定外部配置的属性导致的。首次启动时Bean初始化流程完整，能正确读取外部配置，但修改类触发热重载后，新实例的属性注入逻辑没有被执行，所以server变成了null。下面是几个针对性的解决方案：

方案1：在resources.groovy中显式绑定配置属性 #

修改你的resources.groovy，在定义apiService Bean时，直接从Grails配置中获取属性并赋值给Bean。这样每次Bean被创建（包括热重载时），都会重新读取配置值：

import com.yourpackage.ApiService
import grails.core.GrailsApplication

beans = {
    apiService(ApiService) {
        // 替换成你实际的配置键名
        server = grailsApplication.config.getProperty('api.server')
        // 如果你用的是Grails 3+，也可以用environment来获取：
        // server = environment.getProperty('api.server')
    }
}

方案2：利用Spring Boot的配置绑定注解（Grails 3+适用） #

如果你的项目基于Grails 3或更高版本（本身集成了Spring Boot），可以给ApiService添加@ConfigurationProperties注解，让Spring自动帮你绑定配置属性，不管是启动还是热重载都能生效：

首先在ApiService类上添加注解：

import org.springframework.boot.context.properties.ConfigurationProperties

// 前缀对应你外部配置里的键，比如配置里是api.server，前缀就设为"api"
@ConfigurationProperties(prefix = "api")
class ApiService {
    String server
    // 其他属性...
}

然后保持resources.groovy里的Bean定义即可：

import com.yourpackage.ApiService

beans = {
    apiService(ApiService)
}

方案3：调整热重载相关启动参数 #

你启动时使用了-Ddisable.auto.recompile参数，这个参数可能干扰了类重新编译后的属性注入流程。可以尝试：

• 移除这个参数，让Grails自动重新编译修改后的类，确保Bean初始化的完整流程被执行
• 如果必须保留该参数，修改ApiService后可以尝试手动重启应用的上下文（不过这种方式比较繁琐，不推荐日常开发用）

额外注意事项 #

• 确保你的外部配置文件（比如application.properties、application.yml或者自定义配置文件）在Grails的监控路径内，热重载时能被正确读取
• 如果使用自定义配置文件，要在Grails的主配置里声明加载它，比如在application.yml中添加：

grails:
    config:
        locations:
            - classpath:your-custom-config.properties

内容的提问来源于stack exchange，提问作者Alan Hill