hyperf 升级至 v3.x 后批量操作需重点适配语义一致性、事务安全与协程隔离：替换弃用写法、改用 schema::table 链式迁移、禁用循环开事务、显式传递 context 版本信息。
Hyperf 升级后，尤其是从 v2.x 到 v3.x 及以上（如 v3.1.51），数据库操作层和迁移机制虽保持向后兼容性，但批量修改逻辑若依赖旧版行为、扩展方法或上下文处理方式，容易出错。适配重点不在“能否运行”，而在于语义一致性、事务安全性和协程上下文隔离。以下是关键适配方向：
检查并替换已弃用的批量更新写法
v3.x 起强化了 Query Builder 的类型安全与链式调用一致性。以下常见写法需调整：
- 旧写法（v2.x 兼容但不推荐）：
$this->db->table('users')->where('status', 0)->update(['status' => 1]);
新建议：显式使用affected()判断影响行数，并包裹在事务中，避免静默失败 - 若原逻辑含多表 JOIN 更新，v3.x 不再默认支持原生 JOIN UPDATE 语法；应改用子查询或分步处理（先查 ID，再 in 批量更新）
- 避免直接拼接数组进
update()，字段值需经类型转换（如intval()、Carbon::parse()），防止协程间数据污染
重写迁移中的批量 DDL 操作
原有 migration 中若用原生 SQL 做批量字段修改（如 ALTER TABLE ... MODIFY COLUMN 多次），需注意：
- v3.1+ 支持
Schema::table()链式变更，推荐统一用该方式，例如：Schema::table('orders', function (Blueprint $table) { $table->string('remark', 500)->change(); }); - 批量加字段/索引时，不再允许单个 migration 文件内多次调用
Db::statement()执行 DDL；应合并为一次执行，或拆分为多个独立 migration 文件（命名按规范：如2026_09_10_100000_add_remark_to_orders.php和2026_09_10_100001_add_index_status_to_orders.php） - 涉及表注释、字段注释的，继续使用
$table->comment()和Db::statement("ALTER TABLE ... COMMENT")组合，无需改动
升级事务与并发批量操作逻辑
v3.x 对事务嵌套、协程并发下的连接复用更严格，原有“循环内开事务”模式极易触发连接池耗尽或死锁：
- 禁用“for 循环中每次
beginTransaction()”——改为先收集待更新 ID 或数据，再单次事务内批量处理 - 若需分批处理大数据量（如 10 万条用户状态更新），使用
Collection::chunk(1000)+ 外层事务 + 每 chunk 内部DB::transaction()，并设置wait_timeout≥ 10s 防止超时中断 - 涉及软删除批量恢复，优先使用 v3.1.51 新增的
createOrRestore()或withTrashed()->restore()，而非手写UPDATE SET deleted_at = NULL
验证 Context 与版本上下文对批量操作的影响
若你的批量逻辑被 API 版本中间件（VersionMiddleware）包裹，且内部调用了带版本判断的服务（如按 v1/v2 返回不同字段），需确认：
- 批量操作是否在子协程中执行？如果是，必须显式调用
Context::copy($parentContext)传递api_version，否则子协程读不到版本标识 - 禁止在批量循环体内反复调用
Context::get('api_version')—— 应在入口处取一次，作为参数传入处理函数 - 若批量操作结果要写入缓存，cache key 必须包含当前版本号（如
user_list_v2_202609），避免 v1/v2 缓存互相覆盖
