classpath*: 不能扫描所有 XML 文件，仅匹配类路径各元素顶层的 .xml 文件，不递归子目录或 jar 内嵌套路径；需显式写 classpath*:META-INF/spring/*.xml 才能加载指定路径。
classpath\*:\*.xml 是什么，它真能扫到所有 XML 文件？
不能。它只匹配类路径下**所有 jar 包和目录中顶层的 .xml 文件**，不递归子目录，也不扫描 jar 内嵌套路径（比如 META-INF/spring/*.xml 就不会被命中）。
常见错误现象：classpath\*:\*.xml 在 IDE 里跑得通，打包成 jar 后却加载不到配置——因为 IDE 的 classpath 是展开的目录结构，而 jar 包里文件是扁平 ZIP 条目，\*.xml 只匹配根层级。
-
classpath\*:表示“遍历所有 classpath 元素”（每个 jar、每个 classes 目录都算一个） -
\*.xml是 Ant 风格通配符，只匹配当前路径下的直接文件，不进子目录 - Spring 实际调用的是
ResourcePatternResolver，底层依赖ClassLoader.getResources("")获取路径前缀，再做字符串匹配
想加载 META-INF/spring/ 下的 XML 怎么写？
必须显式写出路径层级，classpath\*:META-INF/spring/*.xml 才行。注意这里不是正则，* 仅代表“当前目录下任意文件名”，不能跨级。
使用场景：多模块项目中，各 starter 自带自动装配配置，统一放在 META-INF/spring/ 下，主应用靠这个通配加载。
- 错写成
classpath\*:META-INF/*/spring/*.xml→ 不生效（**才支持递归，但 Spring 的classpath\*不支持**） - 错写成
classpath:META-INF/spring/*.xml（缺*）→ 只查第一个 classpath 元素，漏掉其他 jar 中的同名路径 - jar 包内路径区分大小写：Windows 开发时正常，Linux 运行时报
FileNotFoundException，因为META-INF必须全大写
classpath: 和 classpath\*: 性能与兼容性差异
classpath: 找到第一个就停，快；classpath\*: 要遍历全部 classpath 元素，慢，且某些 ClassLoader（如 OSGi、WebSphere 的定制类加载器）可能不支持 getResources("")，直接抛 NullPointerException。
参数差异：只有 classpath\*: 支持通配符前缀，classpath: 后面跟通配符会被当字面量处理（比如 classpath:*.xml 就是在找一个叫 *.xml 的文件）。
- Spring Boot 2.4+ 默认禁用
classpath\*:加载application.properties类资源，避免启动变慢 - JDK 9+ 模块系统下，如果 XML 在 named module 里，
classpath\*:可能无法访问，需改用ClassPathResource手动构造 - 测试时容易忽略：
@ContextConfiguration(locations = "classpath\*:/config/*.xml")在test/resources有文件、main/resources 没有时，仍会加载 test 下的——因为 test classpath 在 main 前
替代方案：什么时候该放弃通配符，改用手动注册？
当 XML 分布杂乱、路径层级深、或需要条件加载（比如按 profile 过滤），硬靠 classpath\*: 容易失控。Spring 提供了更可控的方式。
性能影响：通配符触发全量扫描，100+ jar 时启动延迂数百毫秒；手动指定路径可跳过无关包。
- 用
@ImportResource("classpath:/config/app-context.xml")显式导入，路径清晰、IDE 可跳转 - 在
ApplicationContextInitializer中用GenericXmlApplicationContext动态注册，适合根据环境拼接路径 - Spring Boot 推荐用
@Configuration类 +@Bean替代 XML，避免路径问题本身
真正麻烦的从来不是写对通配符，而是别人改了 jar 包结构、升级了依赖、换了类加载器之后，它还在那儿静默失效。
