spring容器默认不调用私有setter方法进行属性注入，仅识别public void setxxx(type)形式的setter；所谓“私有setter被注入”实为lombok构造器注入、hibernate字段直写或自定义编辑器等非spring原生行为。
Spring 容器默认只调用 public 的 setter 方法 进行属性注入，这是由其反射机制决定的：BeanWrapperImpl 会遍历 getDeclaredMethods()，但仅识别并调用 public void setXxx(Type) 形式的 setter。因此，私有 setter 方法不会被 Spring 自动调用注入——这不是“权限问题”，而是设计限制。
但如果你看到某些场景下“私有 setter 被注入了”，那通常不是 Spring 原生行为，而是以下几种情况之一：
私有 setter 能被注入的常见原因与应对
Lombok 的
@Setter(access = AccessLevel.PRIVATE)+@RequiredArgsConstructor混用
Lombok 生成的私有 setter 本身不会被 Spring 调用；但如果同时用了@RequiredArgsConstructor（且字段未加final），Lombok 可能生成带参构造器，而 Spring 若启用构造器注入，就会绕过 setter，直接通过构造器赋值。此时看似“私有 setter 生效”，实则是构造器注入在起作用。JPA/Hibernate 等 ORM 框架介入
在实体类中，Hibernate 使用javassist或bytecode enhancement直接写入字段（跳过 setter），或通过PropertyAccessStrategy强制访问私有 setter。这属于 ORM 层行为，与 Spring 容器无关。Spring 本身不参与这个过程。手动配置
CustomEditor或PropertyEditorSupport
极少数定制场景下，开发者注册了自定义属性编辑器，显式调用setAccessible(true)访问私有 setter。但这属于侵入式 hack，不推荐，且破坏封装性与可维护性。
正确做法：别依赖私有 setter 注入
-
✅ 优先使用构造器注入（推荐）
将关键依赖声明为final字段，通过全参构造器初始化。Spring 3.0+ 全面支持构造器注入，且语义清晰、不可变、线程安全：public class UserService { private final UserRepository userRepository; private final EmailService emailService; public UserService(UserRepository userRepository, EmailService emailService) { this.userRepository = userRepository; this.emailService = emailService; } } -
✅ 若需 setter，保持 public，但用
@NonNull+ 初始化校验
避免 setter 空赋值风险，配合@RequiredArgsConstructor(onConstructor_ = @__({@Autowired}))（Lombok）或手动校验：public void setUserRepository(UserRepository userRepository) { if (userRepository == null) throw new IllegalArgumentException("userRepository must not be null"); this.userRepository = userRepository; } -
⚠️ 禁用 setter 注入敏感字段（安全重点）
如isAdmin、accountBalance等字段，即使声明了 public setter，也应在 Controller 层禁用绑定：@InitBinder public void initBinder(WebDataBinder binder) { binder.setDisallowedFields("admin", "accountBalance"); // 阻止请求参数绑定 }或改用 DTO 分离传输对象与实体，从根本上切断非法字段映射路径。
总结一句话
Spring 不支持也不应支持私有 setter 的自动注入。所谓“技巧”，本质是规避设计缺陷的临时补丁；真正稳健的做法，是用构造器注入保障依赖完整性，用 DTO + @InitBinder 或 @JsonCreator 控制数据入口，再辅以 @PostLoad 处理衍生逻辑——把控制权收回来，而不是和反射权限较劲。
