Hyperf中自定义@ReadWrite注解不能直接生效，因其需显式注册到AspectContainer并配对实现AspectInterface的切面类，且切面类名须以Aspect结尾；注解本身无逻辑，须在getRules()中声明匹配规则。
Hyperf里自定义@ReadWrite注解为什么不能直接生效
因为Hyperf的AOP机制默认不扫描非框架内置注解，@ReadWrite这类自定义注解必须显式注册到AspectContainer，否则切面根本不会触发。另外，注解本身只是元数据，不带任何执行逻辑——你得配一个对应的Aspect类，并在getRules()里声明它匹配哪些注解、哪些方法。
常见错误是只写了注解类，忘了在config/autoload/aspects.php里注册切面，或者注册时写错了类名路径（比如漏了Aspect后缀），结果运行时完全静默，连日志都不打。
- 注解类需加
@Annotation和@Target（通常设为Target::METHOD） - 切面类必须实现
AspectInterface，且getRules()返回包含@ReadWrite的规则数组 - Hyperf 3.x 要求切面类命名以
Aspect结尾，否则容器无法识别
切面中如何动态切换数据库连接
Hyperf的Db组件本身不支持运行时“换库”，但可以通过ConnectionResolverInterface手动指定连接名。关键点在于：不能直接改全局Db实例，而应在切面process()里拦截方法调用，临时把当前协程上下文里的connection_name设为read或write。
注意Db::connection()是协程安全的，但必须在每次查询前调用，不能复用连接对象。如果业务方法里用了Db::table()->where(...)->get()这种链式调用，你需要在切面里重写$proceed()的执行环境，而不是试图去修改Db单例。
- 读操作优先走
read连接，但要加if ($annotation->value === 'read')判断，避免误切 - 写操作强制走
write连接，即使配置了多个写库，也应由ConnectionResolver按策略选一个 - 事务内必须强制走
write，哪怕方法标了@ReadWrite('read')——这点容易被忽略，需在切面里检查Db::transactionLevel() > 0
@ReadWrite注解参数设计与实际使用场景
最简方案只支持字符串值：@ReadWrite('read')或@ReadWrite('write')，但真实项目常需要更细粒度控制，比如按用户ID哈希分读库、或对某些慢查询强制走主库。这时可扩展注解参数：
@ReadWrite(
mode="read",
strategy="hash",
key="uid"
)
对应切面里解析$annotation->strategy和$annotation->key，从$arguments里取实际值做路由。但要注意：参数值必须是字面量或常量，不能是变量或函数调用，否则PHP反射拿不到真实值。
- 简单场景用
mode字段就够了，避免过度设计 - 如果方法参数是对象，
$key指向其属性时，需用ReflectionClass安全取值，防止Undefined property报错 - 不建议在注解里硬编码库名（如
db_name="mysql_read_2"），应统一由ConnectionResolver根据策略映射
为什么事务+读注解会导致从库查不到刚写的数据
这不是注解或切面的问题，而是MySQL主从同步延迟+事务隔离级别的叠加效应。当一个方法同时有@Transaction和@ReadWrite('read')，切面会把它切到从库，但事务内的写操作只发生在主库，从库还没同步完，读就来了。
解决办法不是禁用读注解，而是让切面感知事务状态：只要Db::inTransaction()为true，无论注解怎么写，一律走write连接。这个逻辑必须写死在切面process()开头，不能依赖注解值。
- Hyperf 2.2+ 的
Db::inTransaction()是协程安全的，可放心调用 - 如果用了
Db::transaction()闭包写法，需确保闭包内所有DB操作都经过同一连接，否则跨连接事务会失效 - 测试时一定要用
sleep(1)模拟主从延迟，否则本地开发环境看不出问题
真正麻烦的是跨服务调用——比如A服务写了数据，B服务用@ReadWrite('read')查，这时候注解完全无能为力，得靠业务层加缓存或等待binlog同步。注解只管单次请求内的DB选择，别指望它解决分布式一致性。
