为什么需要有框架
屏蔽底层实现，例如：
1.1 数据库操作底层
底层需要处理：数据库连接池创建 / 管理、SQL 语句拼接与防注入、事务开启 / 提交 / 回滚、结果集解析、断线重连等；
框架 / GORM 屏蔽方式：如 GORM 封装了
db.Create(&user)、db.Where("id=?", 1).First(&user)等操作，底层的连接池配置（如最大连接数、空闲连接数）、SQL 预编译、事务控制都被框架封装，开发者无需直接操作database/sql包的Stmt、Tx等底层对象;
1.2 中间件与请求链路底层
底层需要处理：请求拦截器的链式调用、中间件的顺序执行、请求 ID 传递、链路追踪（Trace）埋点等；
框架屏蔽方式：如 Gin 的
r.Use(loggerMiddleware, recoveryMiddleware)，开发者只需定义中间件函数，框架自动处理中间件的执行顺序和请求上下文传递，无需手动维护调用
规范代码位置，统一代码风格
框架会定义清晰的目录划分规则，强制 / 引导开发者按功能 / 职责归类代码，开发者无需纠结 “配置放哪”“接口逻辑写在哪”，直接按框架约定的目录放代码，团队成员一看就懂。
提升可维护性
分层架构降低耦合，便于局部修改
内置错误处理与日志体系，简化调试维护
自动化工具支持，降低维护工作量，例如使用gorm自动生成单表的CRUD操作
什么是好的框架
少即是多
实现一个方法，或者一个功能，框架只需要提供有且仅有一种实现方式，便于统一代码。如果实现一种功能的方式提供了N种，这也是给开发人员带来选型的负担。同时，保证技术一致性，团队使用框架指定的库，避免 “一人一套工具” 导致的代码混乱，便于维护。
提供丰富的库，用于支持业务开发
围绕业务全流程需求构建了丰富且适配性强的库生态 —— 这些库覆盖数据处理、网络通信、安全防护、工具支撑、业务组件等核心环节，既避免开发者重复造轮子，又能通过 “框架 + 库” 的无缝协同降低集成成本。
对于代码开发的风格起到良好的引导作用
框架可以规范开发人员写的代码位置，以及风格。框架对代码开发风格的引导作用，本质是通过自身的设计范式、API 风格、约定俗成的最佳实践，让开发者在使用框架的过程中，自然对齐统一的代码风格 —— 这种引导不是强制约束，而是 “潜移默化的示范”+“配套工具的规范”，最终让团队代码风格趋同，可读性和维护性大幅提升。
基础的业务代码模块化
通用框架解决的是 “共性技术问题”（如 HTTP 处理、数据库交互、模块化规范），但自身业务的 “个性化场景” 和 “专属逻辑”，需要在框架基础上做二次封装，让框架能力与业务深度绑定，最终形成 “通用框架 + 业务封装层” 的专属技术体系。这种基于业务需求的封装，本质是把 “通用能力” 转化为 “业务专属能力”
应急兜底
框架可以通过异常捕获、熔断降级、超时重试、限流隔离、事务回滚等机制，将复杂的容错逻辑封装为可直接使用的工具或 API，业务开发者无需从零实现这些 “非业务核心但关键” 的能力。例如：框架可通过统一封装脱敏逻辑 + 异常兜底处理，既保证所有场景下手机号的合规脱敏，又能在数据异常（如非标准手机号、空值、特殊格式）时避免系统报错
框架的常见设计思想
配置即一切
本质是约定优于配置的延伸，框架预先定义好 “通用逻辑模板”，将模板中的 “变量部分” 交给配置填充：
框架负责实现 “模板逻辑”（如数据库连接池的创建、销毁、复用）；
开发者负责提供 “配置变量”（如数据库 IP、端口、最大连接数）；
最终框架通过 “配置 + 模板” 自动组装出完整功能，无需开发者手写模板内的重复逻辑。
优点在于可以提供极致的自动化能力，大幅降低开发成本，框架通过配置自动完成底层逻辑的初始化，开发者无需关注 “如何实现”，只需关注 “配置什么”。但是，有时候配置本身的学习成本也很高。
IOC
所有的服务都通过容器负责，即提供者注入，使用者使用，优点在于可以将各个类服务解耦成功，但缺点在于使创建对象复杂化，不直观
AOP
如过滤器、拦截器、中间件可以再统一的逻辑横切面进行逻辑注入。可以使一些通用的逻辑比较容易处理，比如可以用来做鉴权，统一错误封装等操作
MVC
将系统拆分为 Model（处理数据逻辑与业务规则）、View（负责数据展示与交互界面）、Controller（接收请求并协调 Model 与 View）三大模块，通过关注点分离降低耦合。主流框架（如 Spring MVC、Beego）均落地这一模式，Controller 作为调度中枢衔接请求与业务，Model 封装数据层逻辑，View 聚焦展示层实现，既让代码职责清晰，也提升了系统的可维护性与扩展性。但是，有时候试图与控制器的界限在某些时候不好确定，以及没有从业务角度上进行通用概念抽象
DDD
DDD（领域驱动设计）是聚焦业务领域的架构思想，核心是将系统按业务领域拆分，让代码映射真实业务逻辑，而非技术实现。框架通过分层架构（领域层、应用层、基础设施层）支撑 DDD 落地，领域层封装核心业务规则，应用层协调领域逻辑，基础设施层提供技术支撑，既解决复杂业务的建模难题，也让系统随业务演进更灵活。优点在于可以从业务角度出发设计模型，缺点是引入了复杂度，需要考虑性能与模型的平衡
相关文章
