初级Java开发使用Spring框架特性为何被指存在代码耦合问题

框架使用的核心逻辑澄清 #

你对框架价值的理解没有错，框架的存在本身就是为了封装通用能力、减少重复编码、降低底层逻辑出错概率。但团队提出的「减少框架耦合」要求同样是工业界经过大量项目验证的最佳实践，核心原因集中在两点：

• 降低后续维护成本：如果核心业务代码和Spring强绑定，后续做框架版本升级（比如Spring Boot 2.x升级3.x时大量旧注解、API废弃）、甚至部分场景切换轻量化框架时，核心业务逻辑需要整体重构，成本极高
• 大幅提升测试效率：和Spring耦合的代码无法脱离Spring容器运行，单元测试每次都需要启动完整Spring上下文，单测执行效率会从毫秒级降到秒级甚至十秒级，纯Java编写的业务逻辑可以直接Mock依赖，不需要启动容器就能完成测试，适配CI/CD流程的效率提升非常明显

关于@Autowired被批评的具体说明 #

对字段注入的限制是Spring官方早已明确的最佳实践，并非针对个人：

• 字段注入（直接在成员变量上加@Autowired）完全依赖Spring容器的反射能力完成赋值，类脱离Spring容器后无法正常实例化，同时IDE无法提前检测到依赖缺失的问题，只有运行时启动容器才会抛出空指针或Bean缺失异常
• 要求使用构造器注入本质是鼓励你用纯Java原生的方式实现依赖注入，不需要依赖任何Spring特性：你可以在自己实例化对象时直接传入依赖，IDE能在编码阶段就提示构造参数缺失，不可变依赖还可以用final修饰，天然保证线程安全

如果觉得手写构造器太繁琐，可以配合Lombok的@RequiredArgsConstructor注解自动生成带必要参数的构造器，编码量和使用@Autowired完全一致，同时符合低耦合的要求

合理的框架使用边界参考 #

框架特性可以用，但要明确使用的场景边界，不要把框架特性侵入到核心业务逻辑中：

• 仅在应用启动类、配置类、框架适配层这些和基础组件强相关的位置使用Spring专属特性
• 核心业务逻辑层的代码全部用纯Java实现，依赖的外部能力只暴露接口，注入逻辑统一交给外层框架层处理

按照这个边界开发，既能享受Spring框架提供的各种能力，也能保证核心业务代码的可移植性、可测试性，符合大多数企业级项目的协作规范。

内容的提问来源于stack exchange，提问作者user17432086