你有没有遇到过这种情况：接手一段别人写的代码，翻来覆去看不懂逻辑，函数套函数，类绕类，改一处，崩一片？这时候光靠注释已经救不了你了，得往更深的地方挖——看源码。
但看源码不是逐行翻译，而是要抓住结构和意图。这时候，设计模式就成了你的“阅读理解指南”。它不教你写多炫技的代码，而是帮你理解为什么代码要这么写，甚至预判下一步会怎么走。
从一个常见场景说起
比如你在做一个电商项目，订单状态有“待支付”“已发货”“已完成”等。一开始可能用一堆 if-else 判断状态再执行对应操作。可随着状态越来越多，逻辑越来越复杂，代码就开始“膨胀”。
这时候如果你熟悉“状态模式”，就会想到：把每个状态封装成一个类，让它们自己决定行为。去看一些成熟框架的源码，比如 Spring 或者 React 的状态管理逻辑，其实都能看到这种思想的影子。
public interface OrderState {
void handle(OrderContext context);
}
public class PaidState implements OrderState {
public void handle(OrderContext context) {
System.out.println("订单已支付，准备发货");
context.setState(new ShippedState());
}
}这段代码没做什么惊天动地的事，但它把变化的部分隔离开了。下次加个“退款中”状态，不用动原有逻辑，新增一个类就行。这就是设计模式带来的可维护性。
源码分析是反向学习的好机会
很多人觉得设计模式难学，是因为例子太抽象。其实最好的学习方式，是去读那些已经在用的开源项目的源码。比如看 JDK 里的 java.util.concurrent 包，会发现线程池的实现大量使用了“策略模式”——不同拒绝策略对应不同行为。
再比如，观察 Android 中的 RecyclerView，它的 Adapter 和 ViewHolder 配合，本质上就是“适配器模式”的落地。你不需要重新发明轮子，但得知道轮子是怎么转的。
别为了模式而模式
也有人滥用设计模式，明明一个函数能解决的事，非得搞出七八个接口和实现类，搞得人头晕。这就像做饭，调料再好，放太多也毁菜。
真正懂设计模式的人，往往写出来的代码看起来“平平无奇”，但扩展性强、边界清晰。他们在写代码之前，脑子里已经有了一张结构图，知道哪里该留口子，哪里该封死。
所以，看源码不只是为了抄答案，更是为了看清别人是怎么做权衡的。有些地方用了单例，是因为资源昂贵；有些地方用了观察者，是因为状态需要广播。背后都有上下文，不能脱离场景硬套。
下次你再打开 GitHub 上某个库的源码，不妨先别急着搜“怎么用”，而是看看它的包结构，类命名，接口定义。很多时候，设计模式就藏在这些细节里，像一条暗线，串起了整个系统的骨架。