hyperf多租户批量修改需确保租户上下文全程透传、sql自动注入租户字段、事务并发状态一致：用context显式存取tenant_id，模型配合全局作用域实现自动过滤，高并发下采用原子sql与租户级分布式锁。
在Hyperf中实现多租户下的安全批量修改，核心不是“绕过租户隔离去改数据”，而是让批量操作天然运行在租户上下文里，同时防止误操作越权或跨租户污染。关键在于三点：租户上下文绑定、批量SQL的租户字段自动注入、以及事务与并发下的状态一致性。
租户上下文必须全程透传
不能依赖中间件设置一次就万事大吉——协程挂起恢复后，静态变量或全局属性极易被覆盖（参考购物车串号事故）。必须用 Hyperf Context 显式存储当前租户ID，并在所有数据访问层强制读取：
- 登录或请求入口处，将租户标识（如 header 中的 X-Tenant-ID）写入 Context：
Context::set('tenant_id', $tenantId) - 数据库查询前，统一从 Context 获取租户ID，禁止硬编码或从 Request 临时提取
- 批量更新前，先校验 Context 中是否存在有效 tenant_id，缺失则直接中止并报错
批量更新必须走模型 + 全局作用域，禁用原生 SQL 直写
手动拼接 UPDATE 语句极易遗漏 WHERE tenant_id = ?，且无法复用租户过滤逻辑。正确做法是：
- 为模型引入租户 Trait（如
Tenantable），配合全局作用域（GlobalScope）自动添加where tenant_id = ? - 批量更新使用 Eloquent 风格：
User::where('status', 'pending')->update(['status' => 'active'])—— 此时全局作用域已生效，无需额外加 where - 若需更底层控制（如大批量不触发模型事件），可用 QueryBuilder，但必须显式调用
where('tenant_id', Context::get('tenant_id'))
高并发下防误覆盖与事务边界要清晰
批量修改常伴随状态流转（如订单批量发货），若多个协程同时操作同一租户的不同批次数据，可能因缓存/锁粒度不当引发冲突：
- 避免在事务外做条件判断再更新（如“查出100条待处理记录 → 循环 update”），应改用原子 SQL：
UPDATE orders SET status = 'shipped' WHERE tenant_id = ? AND status = 'ready' LIMIT 100 - 对关键批量操作加租户级分布式锁（如 Redis Lock），Key 为
lock:tenant:{id}:batch_ship，防止同一租户重复触发 - 日志与监控需标记租户ID，确保审计可追溯；失败任务重试时，必须重新加载 Context，不可复用旧协程残留值
不复杂但容易忽略
