Spring 5.x + JDK 8 下 XML 配置虽被标记为 legacy 但仍可用，需锁定 Spring 5.3.37、仅引入 spring-context/spring-beans、使用正确 XSD 地址，并注意构造注入优先、prototype 行为及混合配置风险。
Spring 5.x + JDK 8 环境下，XML 配置方式已不推荐但依然可用
Spring 官方从 5.2 开始明确标记 ClassPathXmlApplicationContext 为“legacy”，不是不能用，而是新项目里硬上 XML 会卡在依赖、版本、IDE 支持三道坎上。如果你必须用（比如维护老系统、教学演示），核心是锁死版本组合：JDK 8 + Spring 5.3.37（最后一个支持 JDK 8 的 5.x 小版本）+ Maven 坐标不带 spring-boot-starter。
常见错误现象：java.lang.NoClassDefFoundError: org/springframework/core/metrics/ApplicationStartup —— 这是用了 Spring 6+ 的 JAR 却配了 JDK 8；org.xml.sax.SAXParseException: cvc-complex-type.2.4.c —— XML 命名空间写错或 XSD 地址失效。
- XML 文件头必须用 Spring 5.x 对应的 XSD：
http://www.springframework.org/schema/beans/spring-beans-5.3.xsd，别抄网上过时的 3.0 或 4.0 地址 - Maven 里只引
spring-context和spring-beans，别加spring-web或spring-boot相关依赖，否则类路径污染导致BeanFactory初始化失败 - IDEA 默认不识别
applicationContext.xml，右键文件 → “Mark as Spring Config” 才能获得 bean 引用提示
ClassPathXmlApplicationContext 启动失败的三个高频原因
这个类看似简单，但初始化过程会静默跳过很多配置问题，直到你调 getBean() 才报错。最常卡在资源加载、解析、实例化三个阶段。
- XML 文件不在
src/main/resources下，或名字没写对 ——new ClassPathXmlApplicationContext("app.xml")会找 classpath 根目录下的app.xml，不是当前包路径 - bean 的
class属性写的是接口名（如com.example.Service），而不是具体实现类（如com.example.DefaultService），Spring 不会自动帮你猜实现 - 构造函数参数类型匹配失败：XML 里用
<constructor-arg value="123"/>传字符串，但目标类构造器要的是int，得显式写type="int"，否则报No matching factory method found
XML 中 <property> 和 <constructor-arg> 到底怎么选
这不是风格问题，是对象生命周期和可测试性的分水岭。Spring 官方文档早就不鼓励 setter 注入（<property>），因为会导致 bean 构造后处于不完整状态。
立即学习“Java免费学习笔记（深入）”；
- 强制依赖（比如 Service 必须有 Dao）—— 用
<constructor-arg>，Spring 会在构造时检查参数是否可解析，漏配直接启动失败 - 可选依赖（比如日志开关、回调监听器）—— 用
<property>，配合autowire="byType"或显式 ref，但注意autowire在 XML 中默认关闭 - 混合使用没问题，但别在一个 bean 定义里既写
<constructor-arg>又写<property>同名字段，Spring 会优先走构造注入，setter 被忽略且不报错
XML Bean 定义里 scope="prototype" 的真实行为
很多人以为 prototype 就是“每次 getBean 都新建”，但忽略了它只控制 Spring 容器内的实例数量，不干涉对象内部状态或线程安全。
- prototype bean 的构造函数会被多次执行，但它的依赖（比如一个 singleton dao）仍是共享的 —— 这点常被误认为“没生效”
- prototype bean 里的字段如果存了可变状态（如
List<String> cache = new ArrayList<>()），多线程并发调用时会互相污染，Spring 不负责同步 - prototype bean 不会自动销毁：容器关闭时，只有 singleton bean 触发
destroy-method，prototype 的清理得你自己在业务代码里做
真正难搞的不是怎么写 XML，而是当团队里有人开始混用 JavaConfig（@Configuration）和 XML 时，@ImportResource 加载顺序、profile 激活条件、bean 名称冲突这些事，根本不会在编译期暴露。
