hyperf批量修改需兼顾数据一致性与协程隔离性，应通过协程池控并发、分片事务、where条件校验、显式上下文传递及query builder安全操作来实现。
在 Hyperf 中批量修改数据库记录时，关键不是“能不能并发”，而是“如何让并发不破坏数据一致性与协程隔离性”。直接用 for 循环 + 协程开一堆 update，看似快了，实则极易踩坑：连接池耗尽、事务错乱、上下文丢失、主键冲突或覆盖写。真正安全高效的批量修改，必须结合协程调度、连接池控制、事务边界和上下文管理来设计。
用协程池控制并发度，避免打爆数据库
盲目启动成百上千个协程去执行 update，会导致连接池瞬间被占满（哪怕配置了 max_connections=100），后继请求拿不到连接而超时。正确做法是限制并发数，复用连接：
- 通过 Hyperf\Pool\PoolFactory 创建专用的协程池，设置合理 size（如 5–20，视数据库负载和单次更新耗时而定）
- 每个协程从池中获取一个连接执行单条或小批量 update（例如每次改 10 条），而非每条记录一个协程
- 避免在协程内使用全局 DB 实例（如 DB::table()），改用注入的 ConnectionInterface，确保走连接池
按业务逻辑分片 + 显式事务，防止脏写和丢失更新
批量修改常涉及状态变更（如“未支付→已支付”），若多个协程同时读-改-写同一行，可能覆盖彼此结果。解决方案不是加锁，而是靠数据库层保障：
- 使用 WHERE 条件包含原始状态，例如：
UPDATE orders SET status = 2 WHERE id IN (?) AND status = 1，返回影响行数判断是否成功 - 对需要强一致性的场景（如库存扣减），把一批 ID 拆成固定大小的分片（如每片 50 条），每个分片在一个独立事务中执行
- 禁用自动提交，手动控制
$connection->beginTransaction()和commit()/rollback()，并在异常时回滚
隔离协程上下文，避免用户/租户信息串号
如果批量操作需携带当前请求的上下文（如 operator_id、tenant_id、trace_id），绝不能依赖静态变量或全局 config。必须显式传递：
- 在发起协程前，用 Hyperf\Context\Context::set() 存入必要字段；子协程内用 get() 取出，用于日志记录或审计字段填充
- 更稳妥的方式是将上下文数据作为参数传入协程闭包或任务类构造函数，不依赖 Context（适合父子协程明确、无嵌套调度的场景）
- 切勿在协程中修改单例对象的属性（如 AuthManager::$user），这类状态会跨协程污染
用 Hyperf 的 DbTable 或 QueryBuilder 配合协程客户端
Hyperf 的 hyperf/database 组件默认启用协程 MySQL 客户端，但需确认配置启用连接池且驱动为 mysql（非 pdo_mysql）。执行时推荐方式：
- 避免 raw SQL 拼接，用 QueryBuilder 构建条件，保证类型安全与防注入
- 对大批量更新，优先考虑 INSERT ... ON DUPLICATE KEY UPDATE 或 REPLACE INTO 替代逐条 UPDATE（需表有唯一索引）
- 如需极高吞吐（如百万级），可导出 ID 列表到临时表，用 JOIN 方式批量更新，再由一个协程完成，比并发更稳
