本文目录导读：
- 遵循SOLID原则（面向对象基础）
- 利用设计模式（常见复用模式）
- 架构分层与依赖注入（架构级复用）
- 工具与代码组织（工程化复用）
- 实际编码技巧（日常复用手册）
- 框架原生功能利用（以 Laravel 为例）
- 注意反模式（避免复用的陷阱）
- 总结建议
优化PHP项目的代码复用是提升开发效率、降低维护成本的核心手段，下面从设计模式、架构分层、工具链和实际技巧四个维度，为你梳理一套系统的优化策略：
遵循SOLID原则（面向对象基础）
这是代码可复用的基石,尤其关注“开闭原则”和“里氏替换原则”。
- 单一职责： 一个类或函数只做一件事，不要写一个既负责数据库查询又负责生成HTML的类。
- 依赖倒置： 依赖抽象（接口），而非具体实现，这样更换数据库（MySQL→PostgreSQL）时，上层代码无需改动。
利用设计模式（常见复用模式）
PHP 的 OOP 特性非常适合实现经典设计模式：
- 策略模式： 解决同类算法（如支付、快递、通知）的替换问题。
PaymentProcessor接受PaymentStrategy接口，具体实现AlipayStrategy或WechatStrategy可自由切换。 - 工厂模式： 创建复杂对象时避免到处
new。LoggerFactory::create('file')或LoggerFactory::create('database')。 - 观察者模式： 事件驱动，适合解耦（如用户注册后发邮件、加积分），Laravel 的
Event/Listener就是此模式的实现。 - 模板方法模式： 定义算法骨架，子类重写特定步骤，报表生成：父类定义
生成表格 -> 填充数据 -> 导出PDF/CSV，子类实现填充数据的具体逻辑。
架构分层与依赖注入（架构级复用）
采用 MVC 或更现代的架构
- 控制器（Controller）：薄（只负责接收请求、调用服务、返回响应）。
- 服务层（Service Layer）：存放核心业务逻辑（如
OrderService::createOrder()），这是复用的核心战场，控制器、API、CLI 命令、队列任务均可调用。 - 仓库层（Repository）：封装数据访问，切换数据源（ORM vs 原生SQL）时只改这一层。
- 模型（Model）：只定义属性、关系，不写业务逻辑。
依赖注入容器
使用依赖注入容器（PHP-DI、Laravel Service Container、Symfony DI）管理对象依赖，好处是：
- 代码不依赖具体类,而是依赖接口。
- 单元测试时可轻松注入模拟对象（Mock）。
工具与代码组织（工程化复用）
- Composer 私有包： 将通用模块（如短信发送、日志、权限校验）提取为独立包，用
composer require引入，跨项目复用最有效。 - Traits（小心使用）： 当类需要共享方法但不适用继承时，可用
trait，但避免过度使用，防止代码逻辑隐式耦合。 - 创建辅助函数类： 把重复的“小工具”（如时间格式化、数组排序、加密算法）封装到
Utils类或独立命名空间中，与业务逻辑隔离。 - 服务容器统一注册： 将第三方库（如 Guzzle、Monolog）通过服务容器配置，而非直接
new，这样更换实现只需改一处配置。
实际编码技巧（日常复用手册）
- 参数化查询：将查询条件作为参数传递，而非硬编码。
- 抽象重复流程：所有数据库操作前的“事务开始-执行-提交或回滚”流程，可用一个公共函数/方法封装。
- 使用中间件/管道模式：对请求进行统一的预处理或后处理（如日志记录、权限检查、参数验证），Laravel、Slim 等框架均支持。
- 避免复制粘贴： 当你发现自己第三次复制同一段代码时，就该抽象了。
框架原生功能利用（以 Laravel 为例）
现在的 PHP 框架已内置大量复用支持：
| 功能 | 作用 |
|---|---|
| 自定义 Artisan 命令 | 将脚本逻辑作为类复用，可在不同环境执行。 |
| Service Provider | 注册和绑定服务到容器，一次性配置，全局可用。 |
| Form Request | 验证逻辑与控制器分离，可在不同方法间复用。 |
| Policy / Gate | 权限检查逻辑集中管理，视图和控制器均可调用。 |
| Job / Queue | 延迟处理、异步任务的逻辑封装，支持多次复用。 |
注意反模式（避免复用的陷阱）
- 上帝类：一个类包含太多不相关的功能，强行复用会导致难以维护。
- 过度抽象：不要为只出现一次的代码创建复杂模式，YAGNI（你不会需要它）原则很重要。
- 陷阱：继承过深：超过 3 层继承，维护成本急剧上升，尽可能用组合代替继承。
总结建议
- 从现实需求出发：先找项目中出现 3 次以上的代码片段。
- 优先用 Composer 管理：如果是通用功能（加密、发送邮件、支付），优先搜索 Packagist 上成熟的包，而非自己实现。
- 先 Service 化，再 Package 化：先在项目内通过服务层实现复用，等稳定后提取为独立包。
- 配合版本控制：复用代码一定要有接口文档和单元测试，否则会变成“黑盒”难以调试。
最终目标是：业务代码只写一次，变更时只改一处，不同地方共享同一份逻辑。 这样你的项目会在长期迭代中越来越“轻盈”。
