抽象父类中禁用@autowired字段注入，因spring不实例化抽象类导致npe；推荐构造函数注入+protected final字段，或protected setter注入，或模板方法传参解耦依赖。
抽象父类里直接写 @Autowired 字段，看似省事，但运行时经常报 NullPointerException。根本原因在于：Spring 容器不会单独实例化抽象类，它只管理子类的 Bean；而 Java 的构造流程又要求先执行父类构造器——此时依赖还没被 Spring 填充，字段自然为 null。要让公共逻辑真正“可复用、不踩坑”，得绕开字段注入的陷阱，用更可靠的方式封装。
用构造函数注入 + protected final 字段
这是最推荐的写法。把依赖声明为 protected final，在子类构造器中完成注入，既保证不可变性，又让子类能安全使用。
- 抽象父类只定义字段和 getter，不写
@Autowired - 子类显式声明构造器，接收依赖并传给父类（或自己持有）
- Spring 能识别子类构造器参数并自动注入，父类字段在对象创建后即有效
示例：
public abstract class BaseService {protected final UserRepository userRepository;
protected BaseService(UserRepository userRepository) {
this.userRepository = userRepository;
}
}
@Service
public class UserService extends BaseService {
public UserService(UserRepository userRepository) {
super(userRepository);
}
}
用 @Autowired setter 方法（带 protected 修饰）
如果构造器方式改动成本高，可以用 setter 注入，但必须确保方法是 protected 且无参，由 Spring 自动调用。
- 避免在抽象类中用
@Autowired字段，改用@Autowiredsetter 方法 - 方法设为
protected，子类无法覆盖逻辑，但 Spring 仍能反射调用 - 字段本身用
protected final或普通protected都可，建议加final防误赋值
示例：
public abstract class BaseService {protected final UserRepository userRepository;
protected BaseService() {
this.userRepository = null; // 占位，实际由 setter 覆盖
}
@Autowired
protected void setUserRepository(UserRepository userRepository) {
this.userRepository = userRepository;
}
}
统一提供模板方法，依赖由子类传入
当父类逻辑需要多个不同依赖，或部分子类依赖不一致时，可把依赖作为模板方法的参数，彻底解耦容器感知。
- 父类定义
protected abstract方法获取依赖，或直接让子类在模板方法中传参 - 父类只做流程控制，不持有依赖引用，完全规避注入时机问题
- 适合高度定制化场景，比如不同子类连不同数据库、调不同外部服务
示例：
public abstract class DataProcessorpublic final T process() {
return doProcess(getDataSource());
}
protected abstract DataSource getDataSource();
protected abstract T doProcess(DataSource ds);
}
避免的写法
这些看似简洁的写法，在抽象类中实际风险很高，应主动避开：
- 在抽象类字段上直接写
@Autowired protected XxxService service;—— 构造阶段为空，调用即崩 - 给字段加
final同时标@Autowired—— 编译可能过，但运行时报 “blank final field not initialized” - 在抽象类构造器里加
@Autowired—— Spring 不解析抽象类构造器上的注解 - 靠子类
@PostConstruct手动赋值 —— 顺序难控，易遗漏，破坏容器管理契约
