maven 原生不支持 `
在标准 Maven 项目结构中，
不过，实际开发中常需规避特定包路径带来的编译冲突（如共享代码库中某模块存在重复类、不兼容 API 或待移除的遗留代码）。此时推荐采用 “白名单包含（include）替代黑名单排除（exclude）” 的稳健方案，配合精准的构建控制：
✅ 正确做法：用 显式声明需编译的源码范围
在 pom.xml 的 maven-compiler-plugin 配置中，清空默认扫描行为，只编译明确指定的包路径：
org.apache.maven.plugins maven-compiler-plugin 3.8.0 ${maven.compiler.source} ${maven.compiler.target} UTF-8 com/company/my_module/**/*.java com/company/core/**/*.java
⚠️ 注意： 是相对于 sourceDirectory 的路径模式（默认为 src/main/java），且必须以 **/*.java 结尾；多个 标签表示“或”关系。
? 同时规避常见陷阱：控制测试执行范围
若项目已转为多模块结构（如通过 parent POM + modules 拆分），需警惕 Maven 默认会递归执行所有子模块的 test 生命周期阶段。当某模块缺少其他模块的测试依赖或源码时，mvn compile 可能因触发 surefire:test 而失败——即使你本意只是编译主代码。
解决方案是在该模块的构建命令中显式跳过测试：
mvn clean compile -Dmaven.test.skip=true
或在 pom.xml 中永久禁用（仅限非测试模块）：
org.apache.maven.plugins maven-surefire-plugin 3.0.0-M9 true
? 总结
- ❌ 不要尝试寻找
—— 它不存在，也不符合 Maven 设计哲学； - ✅ 使用
实现“最小化编译集”，这是最可靠、可复现的排除策略； - ✅ 多模块项目中，务必检查生命周期绑定（尤其是 test 阶段），避免意外触发跨模块测试；
- ✅ 若需更灵活的源码管理（如条件化源目录），可考虑 build-helper-maven-plugin:add-source 配合 profile 控制，但复杂度显著上升，建议优先使用 includes 方案。
此方法已在 Maven 3.6+ 和 JDK 8–17 环境中验证有效，兼顾兼容性与可维护性。
