什么是仓储模式（Repository Pattern）？
仓储模式是一种将数据访问逻辑从业务逻辑中分离的设计模式。它为数据源（如数据库、API、文件等）提供一个抽象层，让上层代码通过统一接口操作数据，而无需关心底层实现细节。在 PHP 中，通常用接口定义仓储契约，再用具体类实现数据库查询、保存、删除等操作。
为什么在 PHP 项目中使用仓储模式？
主要解决耦合高、测试难、替换数据源成本大的问题：
- 业务层不直接依赖 PDO、Eloquent 或 Doctrine，只依赖仓储接口，便于单元测试（可注入 Mock 仓储）
- 切换数据库或改用缓存/远程 API 时，只需替换仓储实现，不改业务代码
- 集中管理查询逻辑，避免 SQL 散落在控制器或服务中，提升可维护性
- 配合领域驱动设计（DDD），帮助划分应用层与基础设施层
仓储接口一般包含哪些方法？
不是越多越好，应围绕聚合根（Aggregate Root）设计。常见方法包括：
- find($id)：按主键查单个实体
- findAll() 或 search($criteria)：支持条件查询（建议用 Specification 模式或 DTO 封装条件）
- add($entity)：新增（注意：不立即执行 SQL，由工作单元统一提交）
- remove($entity)：标记删除
- update($entity)：部分项目省略，靠 add + 覆盖 ID 实现；复杂场景可保留
避免暴露底层细节，例如不要写 findByEmailAndStatus() 这类方法——应通过通用 search 方法传参实现。
立即学习“PHP免费学习笔记（深入）”；
仓储模式和 Laravel Eloquent 的关系？
Eloquent 本身已具备仓储+活动记录（Active Record）混合特性。直接用 Eloquent 不等于用了仓储模式，因为模型同时承担了数据映射、业务逻辑和持久化职责。
若要在 Laravel 中真正实践仓储模式：
- 定义
UserRepositoryInterface，声明 find、search 等方法 - 实现类
EloquentUserRepository，内部使用 User 模型完成查询，但对外隐藏 Eloquent 细节 - 服务类依赖接口，测试时可换为
InMemoryUserRepository - 禁用模型上的
save()、delete()等方法调用，强制走仓储
注意：过度封装简单项目可能增加复杂度，需权衡实际需要。
常见面试陷阱题怎么答？
“仓储模式是不是就是 DAO？”
DAO 更偏向技术层面的数据访问封装（如 JDBC DAO），关注 CRUD；仓储更强调领域语义，返回的是领域对象（Entity/Aggregate），且方法名体现业务意图（如 findActiveOrdersByCustomer()），而非纯技术动作。
“仓储里能不能写 SQL 或调用 Query Builder？”
可以，但必须封装在实现类内部。接口不能暴露 SQL、表名、字段等基础设施细节。如果用 Query Builder，也仅限实现类使用，上层看到的仍是 search(OrderSearchCriteria $criteria) 这样的契约。
“仓储要不要分页？返回 Collection 还是数组？”
分页属于查询规格的一部分，建议仓储方法接收 PaginationCriteria 对象并返回 PaginatedResult（含 items + total）。返回类型应是明确的 DTO 或 Entity 集合，避免直接返回 Eloquent Collection 或原始数组，以保持契约稳定。
