Classpath根路径指向grails-app/views，如何修改以加载自定义资源？

• 此场景下classpath:解析结果指向grails-app/views，本质不是类路径的真实根目录在该位置，是Grails 3.x默认集成的GroovyPageViewResolver对类路径资源的解析做了路径重定向，专门适配GSP视图的查找逻辑，通过parentContext.getResource()拿到的路径结果，根本不是Java类加载器对应的真实类路径根。
• 尝试用classpath:..跳转上级目录抛出FileNotFoundException，是因为Spring的资源解析器从设计上就不支持对类路径资源做相对上级跳转——类路径在打包为WAR后是分散在多个Jar、多个物理目录中的，不存在统一的“上级目录”实体路径，这种写法从原理上就无法生效。
• 之前修改ApplicationResources.groovy不生效，是因为该文件用于配置Spring MVC的Web静态资源映射规则，和类路径资源的加载逻辑完全无关，修改位置本身就不对。

第一步：选择合规的资源存放路径 #

从以下两个Grails默认纳入classpath覆盖范围的目录中选一个存放JSON资源即可，无需额外适配：

• grails-app/conf/：该目录下的非类文件资源，Gradle构建时会自动拷贝到构建输出的classes/resources目录，属于标准类路径资源范畴
• src/main/resources/：Gradle官方约定的项目标准资源目录，本身就全量处于类路径扫描范围内
  注意：不要将资源存放到grails-app/views、web-app这类非类路径目录，这两个目录的内容默认不会进入类路径，仅会作为Web静态资源对外暴露，无法通过类加载器读取。

第二步：调整Gradle构建规则保障双环境一致性 #

打开项目根目录的build.gradle，加入如下配置，解决IntelliJ本地运行与Tomcat部署的资源加载一致性问题：

1. 显式声明资源目录，避免构建过程中资源漏拷贝：

sourceSets {
    main {
        resources {
            srcDirs = [
                "grails-app/conf",
                "src/main/resources"
            ]
        }
    }
}

2. 关闭JSON文件的构建期内容替换，避免特殊字符被Gradle修改导致文件损坏：

processResources {
    filesMatching("**/*.json") {
        // 不对JSON文件做占位符替换
        duplicatesStrategy = DuplicatesStrategy.INCLUDE
    }
}

3. 该配置会自动保证WAR打包时，所有资源文件会被放到WAR包内的WEB-INF/classes目录下——这是Tomcat运行时的类路径根目录，和本地开发时IntelliJ将资源拷贝到编译输出resources目录的逻辑完全一致，不会出现环境差异。

第三步：使用正确的API读取资源，避开路径重定向 #

不要使用grailsApplication.parentContext.getResource()读取类路径资源，该接口会被Grails的视图解析器拦截并重写路径，直接使用类加载器原生API或Spring的资源路径解析器即可，兼容性最优：

• 单文件JSON读取示例：

// 直接从类加载器读取指定路径的JSON流，本地与Tomcat环境均生效
def jsonStream = this.class.classLoader.getResourceAsStream("your-target.json")
if (!jsonStream) {
    throw new FileNotFoundException("类路径下未找到目标JSON资源，请检查目录配置")
}
def jsonSlurper = new groovy.json.JsonSlurper()
def jsonContent = jsonSlurper.parse(jsonStream)

• 类路径下全量JSON文件扫描示例：

import org.springframework.core.io.support.PathMatchingResourcePatternResolver
def resolver = new PathMatchingResourcePatternResolver()
// 扫描类路径下所有JSON文件，不会被Grails视图解析器重定向
def allJsonResources = resolver.getResources("classpath*:**/*.json")
allJsonResources.each { resource ->
    def stream = resource.inputStream
    // 按业务逻辑处理资源流
}

1. 扩展classpath覆盖自定义目录的实现逻辑 #

• 通过在sourceSets中显式声明资源目录，无需修改原有类加载规则，Gradle构建过程会自动将声明的目录全量纳入主源码集的资源路径，不管是本地编译输出还是WAR打包，这些目录的内容都会被放到类加载器可扫描到的位置。
• 完全摒弃相对路径跳转找资源的写法，类路径资源的定位依靠路径名称匹配，而非物理目录层级跳转，从根源上避免之前遇到的路径解析错误。

2. 双环境兼容性保障逻辑 #

• IntelliJ本地运行场景：Gradle的sourceSets配置会被IntelliJ自动识别为项目资源根，资源会被拷贝到本地编译输出的resources目录，与类文件处于同一层级，本地启动应用时类加载器可直接读取。
• Tomcat部署场景：WAR包构建阶段，processResources任务会将所有声明的资源文件拷贝到WAR包内的WEB-INF/classes目录下，该目录是Tomcat Web应用类加载器的默认扫描路径，与本地运行的类加载逻辑完全一致，不会出现路径找不到的问题。

• 不要将资源文件放到grails-app/src、grails-app/views这类非约定目录，哪怕在build.gradle中手动添加路径，本地运行与打包的路径映射也很容易出现偏差。
• 不要尝试通过获取物理文件系统路径的方式读取资源——Tomcat部署时资源是存在于WAR包内部的，并非独立的物理文件，使用file:协议查找必然报错，全程使用流的方式读取类路径资源才是兼容双环境的正确姿势。
• 修改完build.gradle后，需要在Gradle面板执行clean任务再重新编译，不要仅做增量构建，避免旧输出文件残留导致的资源找不到问题。

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