中includes不生效主因是路径匹配错误或filtering配置不当：includes路径需相对于Directory（默认src/main/Resources），多级目录须用**；filtering=true时含${}的文件若无对应properties会静默跳过；excludes优先级高于includes；src/main/java下资源需显式声明resource；testresources与resources隔离，测试配置需单独配置；filtering对二进制文件可能导致损坏，应按需启用。
resource 标签里 includes 不生效？检查 filtering 和路径写法
默认情况下，maven 的 <resources></resources> 只复制 src/main/resources 下的文件，不递归扫描子目录里的非标准后缀（比如 .conf、.yaml），也不处理 src/main/java 下的配置类同名资源。你加了 <includes></includes> 却没看到文件进 target/classes，大概率是路径匹配规则没对上。
常见错误现象：src/main/resources/config/app.conf 没被复制，但 pom.xml 里写了 <include>config/*.conf</include> —— 实际要写成 <include>config/**</include> 或 <include>config/*.conf</include>（注意双星号才匹配多级目录）。
-
<includes></includes>是相对directory的路径，不是项目根目录；默认directory是src/main/resources，所以<include>config/app.conf</include>才对，而不是<include>src/main/resources/config/app.conf</include> - 如果启用了
<filtering>true</filtering>，且文件含${xxx}占位符但没配properties，Maven 会静默跳过该文件（不报错但不复制） -
<excludes></excludes>优先级高于<includes></includes>，两者共存时，先 exclude 再 include，容易误删
想把 src/main/java 下的 .properties 当资源打包？必须显式声明 resource
Maven 默认只认 src/main/resources 为资源目录，src/main/java 下的任何文件（哪怕叫 log4j2.xml）都不会进 classpath，除非你手动加一个 <resource></resource> 块指向它。
使用场景：有些老项目把配置和代码放一起，或者用 Lombok + @PropertySource 注解读取同包下的 app.properties，这时必须让 Maven 把它打进去。
- 在
<build><resources></resources></build>里加一个新<resource></resource>，<directory>src/main/java</directory> - 配合
<includes></includes>精确控制，例如<include>**/*.properties</include>，避免把 .java 文件也拷过去 - 注意：ide（如 IntelliJ）可能不会自动识别这种非标 resource 目录，需手动标记或刷新 Maven project
testResources 和 resources 配置不共享，测试用的配置得单独配
很多人以为在 <resources></resources> 里配好 application-test.yml 就能在 test classpath 里用，结果 @ActiveProfiles("test") 启动失败——因为测试阶段用的是 <testresources></testresources>，和主资源完全隔离。
性能影响：如果测试资源目录很大（比如塞了上百 MB 的 mock 数据），又没用 <excludes></excludes> 过滤，会导致 mvn test 启动变慢、target 目录膨胀。
- 测试资源默认目录是
src/test/resources，但你可以像主资源一样自定义，例如加个<testresource></testresource>指向src/test/config - 如果主资源和测试资源有重叠（比如都用
logback-spring.xml），别指望 Maven 自动合并，得靠 profile 或不同文件名区分 - spring boot 项目中，
src/test/resources/application.yml会被自动激活，但src/test/resources/bootstrap.yml需要额外确认是否被spring-cloud-context正确加载
构建时资源过滤（filtering=true）导致二进制文件损坏？关掉它或白名单控制
filtering=true 会让 Maven 尝试解析所有匹配文件里的 ${xxx} 占位符，对文本文件没问题，但对图片、字体、jsON Schema 等二进制或结构敏感内容，轻则乱码，重则文件不可用（比如 PNG 头被改坏）。
容易踩的坑：全局开 filtering，然后发现打包后的 logo.png 在浏览器打不开，或者 Swagger UI 的 swagger-ui-bundle.js 报语法错误。
- 只对明确需要替换的文件开 filtering，例如
<include>*.properties</include>+<filtering>true</filtering> - 对二进制或 json/YAML 文件，用
<filtering>false</filtering>显式关闭，即使它们也在同一个<resource></resource>块里 - 如果用了 Spring Boot 的
application.yml且含占位符，确保filtering=true，否则${server.port}不会被替换
Maven 资源处理最麻烦的不是怎么写，而是不同插件（maven-resources-plugin、spring-boot-maven-plugin、maven-war-plugin）对同一份 <resource></resource> 的解释略有差异，尤其是路径通配和 filtering 时机。上线前务必检查 target/classes 里实际生成了哪些文件，别只信 pom.xml 里的配置。