Middleware中应解析X-Region请求头,校验其是否在databases.php配置的regions白名单内,并通过RequestContext::set()存入上下文;DAO层需显式接收连接名参数并调用Db::connection($region),确保事务与查询使用同一ConnectionInterface实例,严禁在Middleware中直接执行DB查询或覆盖全局连接。

Middleware里怎么拿到Header并决定用哪个数据库连接
Hyperf 的 Db::connection() 默认只支持静态连接名,想根据请求头(比如 X-Region: cn)动态切换,必须在请求生命周期早期介入。Middleware 是最合适的入口点,但要注意:不能在 Middleware 里直接调用 Db::connection() 并“覆盖全局连接”,因为 Hyperf 的 Db 组件底层用的是连接池 + 连接名映射,不是运行时可重绑定的单例。
真正可行的做法是:在 Middleware 中解析 X-Region,把解析结果存到 RequestContext::set() 或 ApplicationContext::get(ContainerInterface::class)->set(),然后在后续 DAO/Repository 层按需读取、显式指定连接名。
常见错误是试图在 Middleware 里执行 Db::connection('cn')->table(...) —— 这样写虽然能跑,但会绕过连接池管理,且无法被事务上下文感知,容易引发连接泄漏或事务失效。
- 推荐 Header key 用
X-Region,值限定为配置文件中已声明的连接名(如cn、us、sg),避免运行时拼接连接名 - Middleware 中应校验该 Header 值是否存在于
config/autoload/databases.php的键中,非法值建议返回 400 或 fallback 到默认连接 - 不要在 Middleware 中执行任何 DB 查询,只做解析和上下文注入
如何让 DAO 类自动识别当前 Region 并使用对应连接
DAO 不继承 Model 时,最稳妥的方式是构造函数注入 ConnectionInterface 实例,而不是硬编码 Db::connection('cn')。你可以结合 Factory 或自定义注解 + AOP 实现自动注入,但简单项目建议手动传参。
示例:在 Controller 中调用 DAO 时,先从上下文取 region,再显式传入:
// 在 Controller 方法中
$region = RequestContext::get()->header('X-Region')[0] ?? 'default';
$userDao = make(UserDao::class, ['connection' => $region]);
$userDao->find(123);
DAO 内部则用传入的连接名初始化:
class UserDao
{
protected ConnectionInterface $connection;
<pre class="brush:php;toolbar:false;">public function __construct(string $connection = 'default')
{
$this->connection = Db::connection($connection);
}
public function find(int $id): array
{
return $this->connection->table('users')->where('id', $id)->first();
}}
注意:如果用了事务,$this->connection->transaction() 必须与查询用同一个连接实例,否则事务不生效。
Region 和数据库配置怎么对齐才不会出错
Hyperf 的 databases.php 配置必须和 Header 值严格一致。例如 Header 是 X-Region: us,那配置数组里必须有 'us' => [ ... ] 这一项,不能是 'US' 或 'us-east' —— 否则 Db::connection($region) 会抛出 InvalidArgumentException: Connection [us] not found。
建议在 config/autoload/databases.php 顶层加个 regions 键,明确列出合法值,方便 Middleware 校验:
'regions' => ['cn', 'us', 'sg'],
'default' => 'cn',
'connections' => [
'cn' => [ /* ... */ ],
'us' => [ /* ... */ ],
'sg' => [ /* ... */ ],
],
这样 Middleware 就可以安全地做白名单判断,而不是靠 try-catch 捕获异常来兜底。
- 不同 region 的库结构必须完全一致,否则 DAO 层 SQL 会报错(如字段不存在、类型不匹配)
- 如果某些 region 只读,可在对应连接配置中设置
'read_only' => true,并在 DAO 中检查连接属性,禁止写操作 - 连接名不要带特殊字符或路径分隔符,
Db::connection()不支持cn-prod这类含短横线的名称(除非你重写了连接解析逻辑)
为什么不能用 @Inject + @Value 注解自动注入 region 连接
Hyperf 的 @Inject 和 @Value 是容器启动时解析的,而请求 Header 是运行时才有的。试图写 @Value("${request.header.X-Region}") 会失败,因为 ${...} 表达式在 DI 容器构建阶段求值,此时请求上下文根本不存在。
也有同学尝试用 @Aspect + 自定义注解(如 @UseRegion)在方法执行前切换连接,这种方式技术上可行,但会显著增加调用栈深度、干扰协程调度,且事务传播变得不可控 —— 比如一个带 @Transactional 的 Service 方法调用了多个 DAO,AOP 切面在每个 DAO 方法入口切换连接,会导致事务跨连接,最终报错 Cannot commit transaction on connection X while transaction is active on connection Y。
所以动态 region 的核心约束就一条:连接选择必须发生在事务开启之前,且整条调用链使用同一个 ConnectionInterface 实例。
复杂点在于,当 Controller 调用多个 Service,而每个 Service 又调用多个 DAO 时,需要确保它们共享同一连接实例 —— 最简单的方式是把连接实例作为参数逐层传递,或者用 Coroutine::getContext() 存储(但要小心协程销毁时机)。别为了“看起来干净”强行用 AOP 或注解隐藏这个传递过程。











