设计模式教程看多了，容易得一种病：看什么代码都觉得需要重构，重构就想套模式。结果一个 CRUD 接口搞出五个类三个接口，新人接手代码先看半小时类图才能找到入口。
我见过最离谱的案例：一个内部工具的配置模块，总共 3 个配置项，被人用策略模式 + 工厂模式 + 模板方法模式重构了一遍。重构前一个 switch 搞定，重构后 8 个类 2 个接口。说是\”开闭原则\”，结果 3 个月里需求没变过一次，但每次加配置项要改 4 个文件。
今天不聊怎么用设计模式，聊聊什么时候不该用。
单例模式的温床：全局变量披着面向对象的外衣
单例模式是最容易被滥用的模式，因为它的卖点是\”全局唯一\”，这跟全局变量的卖点一模一样。
“`java // 这种单例跟全局变量有什么区别？ public class AppContext { private static AppContext instance = new AppContext();
private Map<String, Object> attributes = new HashMap<>();
public static AppContext getInstance() { return instance; }
public void setAttribute(String key, Object value) {
attributes.put(key, value);
}
public Object getAttribute(String key) {
return attributes.get(key);
}
} “`
这不是单例模式，这是 HashMap 换了件衣服。但它比 HashMap 更危险，因为单例模式给了你一种\”我做了设计\”的错觉。
单例真正需要用的场景很少：连接池、线程池、全局配置。如果你的单例只是个数据袋（data bag），大概率不需要单例，需要的是重新审视你的依赖关系。
更糟糕的是单例 + 可变状态。一个有状态
