AI产品经理面经

联友科技AI产品经理（数字化方向）｜技术追问：Spring Boot自动装配与自定义Starter

背景：面联友科技AI产品经理（数字化方向），简历里有小程序开发、Java/Spring后端联调经历，面试官顺着项目追问了Spring Boot自动装配。产品岗被问技术不用慌，面试官不是要你背源码，而是看你懂不懂技术边界、能不能和研发顺畅沟通。把被问到的和我的回答框架整理一下，回馈牛客。

标签：#面经 #AI产品经理 #联友科技 #SpringBoot #产品经理技术面

一、被问的问题

1. Spring Boot自动装配的原理是什么？
2. 分布式环境下自动装配是怎么运作的？
3. 怎么定义一个Starter？
4. 自动装配和@Autowired有什么区别？

二、我的回答框架

1. 先区分两个概念

• @Autowired：解决Bean之间的依赖注入。
• Spring Boot自动配置：解决根据classpath依赖自动配置Bean，也就是“引入starter就能用”。

面试官问“自动装配原理”，大概率想听后者。先点一句区别，会显得理解得比较准。

2. 自动装配四层链路

第一层：总开关

启动类@SpringBootApplication组合了@EnableAutoConfiguration，通过@Import引入AutoConfigurationImportSelector。

第二层：执行者

AutoConfigurationImportSelector负责收集候选自动配置类，核心是selectImports()。

第三层：读配置清单

去classpath所有jar包里读：

• Spring Boot 2.7之前：META-INF/spring.factories
• Spring Boot 2.7+：META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports

拿到登记好的自动配置类全限定名列表。

第四层：条件过滤

候选清单不会全加载，靠条件注解做减法：

• @ConditionalOnClass：classpath存在某个类才生效；
• @ConditionalOnMissingBean：容器里没有用户自定义Bean才生效，这是默认配置可被覆盖的关键；
• @ConditionalOnProperty：配置项满足条件才生效。

一句话总结：清单登记 + 条件过滤，约定优于配置，默认能用但用户可覆盖。

3. 分布式环境下怎么理解

自动装配是每个Spring Boot应用（每个微服务节点）启动时独立完成的本地行为，不存在一个全局的“分布式自动装配”机制。跨服务的协调靠Spring Cloud、注册中心、配置中心，和自动装配不是同一层问题。这个点答清楚，面试官会觉得你不是死背。

4. 怎么定义一个Starter

核心五步：

1. 命名：第三方用{name}-spring-boot-starter，官方用spring-boot-starter-{name}。
2. 写属性类：@ConfigurationProperties(prefix = "mylog")绑定配置。prefix必须小写字母+短横线，不能有大写或下划线，否则绑定静默失效。
3. 写自动配置类：@Configuration + @EnableConfigurationProperties + 条件注解，Bean上加@ConditionalOnMissingBean让用户可覆盖。
4. 注册配置类：2.7+用META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports，每行一个全限定名；老项目用spring.factories。
5. 打包发布：最好拆成starter（纯依赖）和autoconfigure（装配逻辑）两个模块，避免污染使用者类路径。

三、追问与易错点

追问：自动装配怎么做到按需加载？

候选配置类是全集，每个类头上的条件注解负责过滤。比如引入了Web依赖才配MVC；用户自己定义了DataSource，默认数据源配置就因@ConditionalOnMissingBean退让。

追问：自定义Starter最容易踩什么坑？

• 2.7+还用spring.factories，或者新文件路径写错，启动不报错但配置静默失效；
• @ConfigurationProperties的prefix含大写或下划线，绑定不上；
• 忘了加@ConditionalOnMissingBean，用户没法覆盖默认Bean。