现代 PHP 项目中不建议从零手写表数据网关，因其相比 PDO 直接操作无明显优势，又不如 ORM 灵活；仅在维护遗留系统或教学时才考虑，且需严守单表单类、不处理关联、SQL 参数化三大约束。
表数据网关模式在 PHP 里到底要不要手写
直接说结论：现代 PHP 项目中，不建议从零手写表数据网关（Table Data Gateway）。它本质是为单张表封装 CRUD 的薄层，但和 PDO 直接操作比没明显优势，又不如 ORM 灵活；Laravel 的 Eloquent、Doctrine 的 EntityRepository 或 even Slim + PDO 封装都更实用。除非你维护遗留系统或教学演示，否则投入产出比很低。
用 PDO 实现最简表网关时的三个关键约束
如果非得实现一个轻量版（比如给小型 CMS 增加可测试的数据访问层），必须守住三条线：
-
每张表对应唯一一个类，类名如
UserGateway、PostGateway，不能复用同一类操作多张表 -
不处理关联查询——
findWithComments()这种方法不属于表网关职责，应由上层服务组合多个网关结果 -
SQL 必须参数化，禁止拼接字段名或表名；动态字段需白名单校验，例如：
$allowedFields = ['title', 'status', 'created_at'];<br>if (!in_array($sortField, $allowedFields)) {<br> throw new InvalidArgumentException('Invalid sort field');<br>}
为什么 __call() 动态方法容易翻车
有人想用魔术方法自动映射 findByEmail() → SELECT * FROM users WHERE email = ?，这看似省事，实则埋雷：
- 字段类型丢失：
findByCreatedAt()无法判断传入的是字符串还是时间戳，PDO 绑定类型可能错配 - 索引失效风险：若生成
WHERE JSON_CONTAINS(meta, ?)这类表达式，MySQL 无法走索引 - 调试困难：
getTraceAsString()里看不到实际 SQL，错误信息只报PDOException: SQLSTATE[HY000]，定位慢 - 替代方案更稳：用明确命名的方法 + 显式 SQL，例如：
public function findByStatusAndDate(string $status, DateTimeInterface $since): array<br>{<br> $sql = "SELECT * FROM posts WHERE status = ? AND created_at >= ?";<br> return $this->pdo->execute($sql, [$status, $since->format('Y-m-d H:i:s')]);<br>}
事务边界必须由调用方控制，网关内不开启/提交
表网关类里出现 $this->pdo->beginTransaction() 是典型反模式。原因很实在：
立即学习“PHP免费学习笔记（深入）”；
- 单个网关方法通常只操作一张表，而业务事务常跨多张表（如创建订单同时扣库存），事务粒度不在网关层
- 若网关自己 commit，上层调用方再 try/catch 就无法回滚——PDO 默认 autocommit，
commit()会立刻落盘 - 正确做法是把 PDO 实例传入网关构造函数，并保持其处于 autocommit=false 状态，由 service 层统一管理：
$pdo->beginTransaction();<br>try {<br> $userGateway->insert($userData);<br> $orderGateway->insert($orderData);<br> $pdo->commit();<br>} catch (Exception $e) {<br> $pdo->rollback();<br> throw $e;<br>}
真正难的不是写几个 insert() updateById() 方法，而是守住边界：不越权处理关联、不混淆事务责任、不牺牲可读性去换“自动”。多数时候，删掉网关类，直接在 service 里用 PDO 写几行带命名参数的 SQL，反而更快更可靠。
