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 或注解隐藏这个传递过程。
