设计模式 —— 正确使用 vs 滥用在评估设计模式是否合理还是跟风/过度使用时参考。何时使用模式反复出现的变化—— 相同算法或结构但有不同行为如不同的折扣规则→ Strategy 或类似模式。生命周期或创建复杂性—— 对象创建有许多变体或步骤 → 当重复或复杂性真实存在时使用 Factory、Builder。横切关注点—— 边界处的日志、验证、认证 → 在边缘使用 Decorator、中间件或适配器。稳定抽象、变化实现—— 你预期切换实现如仓库、网关→ 接口 实现依赖注入。经验法则当你感受到第三次重复或第二个变化轴打开同一模块的第二个理由时引入模式。在代码或文档中命名模式使意图清晰。何时不使用模式简单、线性的代码—— 无重复一个变更理由。在这里添加 Factory 或 Strategy 只会增加间接层而无收益。推测性需求—— 我们以后可能需要切换实现。优先 YAGNI当你实际上有第二个实现或第二个变更理由时再添加抽象。每个类都是模式—— 不是每个类都需要在 Factory 或 Interface 后面。在模式能解决真实设计问题的地方使用它们。跟风与滥用跟风—— 因为我们就是这么做的或企业代码有 Factory而使用模式没有清晰的设计理由。症状只调用new的 Factory、单一实现且无第二个计划的 Strategy。过度使用—— 每个类名都带模式名只做委托、不添加任何逻辑的层比直接版本更难理解的代码。误用—— 用错模式解决错误问题例如用 Singleton 实现应该可测试可替换的东西隐藏真实设计的模式例如Facade 背后的 God Object。好的信号模式名称出现在有帮助的设计文档或注释中例如“用于折扣计算的 Strategy”。至少有两个具体变体或有清晰、明确的未来变化理由。测试和调用点因为抽象而更简单例如测试注入假仓库。当有人提议或已添加 Factory、Strategy、Repository 或其他模式时在审查中使用此参考——问这解决了什么重复或变化“和是否有第二个实现或第二个变更理由”