面经策

Spring Boot 是否可以使用 XML 配置 ？ ​

  • 标签：Spring Boot、后端

🏛 业务架构师 ​

可以，但原则上不用。

Spring Boot 完全兼容 XML 配置：@ImportResource("classpath:beans.xml") 就能把老的 XML 定义导入容器，Transition 场景（老系统渐进改造、接手遗留项目）完全可行。XML 能做的事注解都能做，官方定位也一直是"XML 保留兼容，注解优先"。

我的架构立场分三个层次：

  1. 存量：遗留系统的 XML 配置不必急着重写——能跑的代码改写本身就是风险，在功能迭代触碰到的模块里顺手注解化即可（童子军军规）；
  2. 增量：新项目一律注解 + JavaConfig（@Configuration/@Bean）。理由不只是潮流：JavaConfig 可编译期检查、可重构（改类名自动跟）、可调试断点、可条件化——XML 的拼写错误只能运行期发现，这在交付节奏快的业务团队里是真实的缺陷成本；
  3. 配置与代码的边界：无论注解还是 XML，装配逻辑都不该承载环境差异——环境差异属于外部化配置（yml/ConfigMap/Nacos），代码只表达结构。把环境参数写死在 XML 或 JavaConfig 里，是比"用什么格式"严重得多的架构错误。

一句话回答：技术上支持（@ImportResource），工程上淘汰——选择注解的本质是选择编译期安全性和重构友好性。

🏗 系统架构师 ​

能用，但不推荐：@ImportResource("classpath:beans.xml") 导入 XML 配置即可，Boot 自身零 XML 完成全部装配。

我的实践判断：

  1. 新项目一律 Java Config 加注解——类型安全、编译期检查、可重构、可断点；XML 的字符串引用在重构面前极其脆弱；
  2. XML 存在的合理场景只剩两类：存量系统迁移（几十个 XML 的老系统按「新功能注解、旧模块渐进迁移」策略处理，避免大爆炸重写）；个别只提供 XML 接入方式的老第三方框架；
  3. 迁移治理：我做过把千行 XML 清理成 Java Config 的专项——先冻结增量（ArchUnit 规则禁止新增 XML Bean 定义），再按模块渐进收敛，两年归零。

原则：技术可行性不是采用理由，一致性与可维护性才是——团队内一种装配风格胜过两种「都支持」。

💻 全栈开发专家 ​

可以。@ImportResource 引入：

java
@SpringBootApplication
@ImportResource("classpath:applicationContext.xml")
public class App { ... }

还在用的场景：

  1. 遗留系统迁移：老 Spring 项目几十个 XML（数据源、事务切面），一次性重写成 JavaConfig 风险大——标准路线是先 @ImportResource 全量继承，再逐块迁成注解，每步回归
  2. 只提供 XML 配置的老框架（十年前的内部 SDK、工作流引擎）
  3. 运维要求改文件不改代码的极端场景（不推荐，配置中心更合适）

我的原则：新代码一律 JavaConfig/注解——类型安全（编译期查错 vs XML 运行期才炸）、IDE 重构友好（全局重命名不破坏配置）、条件装配能力 XML 表达不了、和 Boot 自动配置心智一致。

迁移时注意 XML 细节的对应写法：depends-on 对应 @DependsOn、lazy-init 对应 @Lazy、方法注入对应 @Lookup，逐个验证，别信"一换就能跑"。