设计模式是针对真实痛点的结构化应对方案，通过创建型、结构型、行为型三类模式分别解决创建分散、关系僵硬、行为交织等重复问题，强调复用性与维护成本权衡，忌为用而用。
设计模式不是代码的装饰品，而是针对真实痛点的结构化应对方案。用得好，能直接把散乱、难改、易错的代码变成职责清晰、扩展方便、维护轻松的结构。
对象创建太乱？用创建型模式收口
数据库连接反复 new、配置对象每次解析、HTTP 客户端参数堆满构造函数——这类问题本质是创建逻辑分散、失控。
- 全局唯一资源（如 Redis 连接池、日志器）用单例模式，推荐静态内部类写法：延迟加载、线程安全、无同步开销
- 多类型对象按条件创建（比如不同支付渠道、不同报表格式），抽成工厂方法或抽象工厂，把 if-else 移到工厂里，业务层只面向接口
- 参数多、可选组合复杂（如构建带超时、重试、拦截器的 HTTP 请求），用建造者模式，链式调用 + build() 封装，避免构造函数爆炸
类之间牵扯太紧？用结构型模式插中间层
业务服务直接 new 第三方 SDK、UI 层掺杂数据转换逻辑、日志埋点散落在几十个 service 方法里——这是典型的关系僵硬、职责混淆。
- 接口不匹配但又必须对接（比如老系统用 XML，新模块要 JSON），用适配器模式，包装旧实现，暴露新接口
- 想加缓存、权限、日志，又不想改原逻辑，用代理模式（JDK 动态代理或 Spring AOP），在调用前后织入横切行为
- 需要动态叠加功能（比如给一个 Service 同时加缓存 + 限流 + 熔断），用装饰器模式，每个装饰器专注一件事，支持嵌套组合
行为逻辑总在改？用行为型模式划清边界
订单状态流转靠一堆 if-else、不同客户等级折扣规则混在同一个方法里、消息推送渠道随需求频繁增删——这是行为交织、难以测试和扩展。
立即学习“Java免费学习笔记（深入）”；
- 算法可互换（如校验规则、计费策略、通知方式），定义统一接口 + 多个实现类，运行时通过枚举、Map 或 Spring @Qualifier 注入，这就是策略模式
- 流程骨架固定但部分步骤可变（比如导出报表：查数据 → 格式化 → 写文件 → 发邮件），把不变逻辑放在父类，可变部分留为 abstract 方法，子类实现，即模板方法模式
- 一个动作触发多个响应（如用户注册后要发短信、写日志、更新推荐模型），用观察者模式解耦，发布者不关心谁监听，监听者各自处理
别为了模式而模式
一个工具类只被调用一次，没必要加工厂；两个支付方式就写 if-else，强上策略反而绕；没有共同接口的方法，硬套装饰器会失真。判断标准就两条：有没有重复变化的需求？引入模式后，维护成本是降了还是升了？
