（二）
先说单例模式，这玩意儿在框架里简直像空气一样无处不在。数据库连接、缓存处理、配置加载，哪个不是全局唯一实例？但见过有人把业务逻辑也塞进单例的，结果单元测试时各种依赖缠绕得像毛线团。好的框架会把单例控制在基础设施层，比如Laravel的Service Container虽然底层用单例管理实例，但通过依赖注入让业务层无感知，这才是优雅的实现。
（三）
工厂模式在对象创建场景简直是大杀器。记得有次接手个老项目，到处是new MySQL()、new PostgreSQL()，光数据库切换就要改二十多个文件。现在主流框架的ORM模块基本都采用抽象工厂+反射机制，像ThinkPHP的Db类，配置里改个类型就能自动切换不同数据库驱动，连事务处理都不用重写。不过要注意避免过度设计------见过有人在简单业务里套三层工厂接口，那真是把螺丝刀当屠龙刀使。
（四）
观察者模式在事件系统里玩得最溜。用户注册后要发邮件、写日志、更新统计，要是全写在Controller里，代码能膨胀到三屏都滚不完。Yii2的Event类就做得漂亮，用on()方法挂监听器，trigger()触发时还能传数据包。不过这里有个坑：事件命名太随意会导致难以追踪调用链，最好像Symfony那样用常量定义事件名。
（五）
MVC本身其实就是复合模式的典范。但很多人把Model当成数据库表映射，结果业务逻辑全挤在Controller里。看过最离谱的项目里，Controller方法超过800行，还混着SQL查询和HTML拼接。正确的做法应该是用领域模型+Service层，Model只处理数据结构和基础验证，复杂业务交给Domain Service，这样即使哪天要换框架，业务代码也能完整迁移。
（六）
策略模式在处理业务规则时特别管用。比如支付接口要同时支持支付宝、微信、银联，如果在代码里写满if-else，每接入新支付方式就得全量回归测试。用策略模式配合配置数组，就像Laravel的Payment Gateway那样，新支付渠道只需实现统一接口，核心流程根本不用动。不过实际开发中记得要把策略类设计成无状态的，否则并发场景容易出鬼畜问题。
（七）
最后说说装饰器模式。中间件机制本质上就是装饰器链，比如请求验证->权限校验->参数过滤这几个环节，每个环节都能独立替换。但见过有团队在装饰器里搞副作用的，比如在日志装饰器里修改请求参数，这种隐蔽的耦合最让人头疼。好的实践应该像PSR-15规范那样，保证每个中间件都是纯函数式的。
（八）
设计模式不是银弹，用错了比不用更可怕。见过有团队在初创项目里强套DDD的，两个月才产出三个接口。真正优秀的框架应该提供恰到好处的模式实现，既保证扩展性又不失开发效率。下次选框架时，不妨重点看看它的核心模块用了哪些模式，这些模式是否与你的业务增长路径匹配------这比跑分测试更能预见代码的生命力。