hyperf 框架虽不内置 erp 功能，但可高效支撑 erp 中订单批量发货：通过协程、事务分批（如每批 500 条）、异步队列、状态校验、操作日志与事件解耦，保障性能、一致性与可追溯性。
Hyperf 框架本身不内置 ERP 功能，但可以高效支撑 ERP 系统中订单发货状态的批量修改。核心在于利用 Hyperf 的协程能力、数据库事务控制、队列异步处理及合理的分批策略，兼顾性能、一致性和可追溯性。
使用事务 + 分批更新保障数据一致性
直接执行 UPDATE orders SET status = 'shipped' WHERE id IN (...) 在数据量大时易锁表、超时或内存溢出。推荐用 Hyperf 的 Db::transaction 包裹分批操作：
- 通过
OrderModel::query()->where(...)->chunk(500, function ($orders) { ... })拆解 ID 列表，每次只处理 500 条 - 每批在事务内完成状态更新、发货时间写入、操作日志记录（建议单独日志表）
- 若某批失败，整个事务回滚，避免部分更新导致状态不一致
结合消息队列实现异步批量处理
前端提交“批量发货”请求后，不应同步执行耗时操作。推荐接入 Hyperf 的 hyperf/amqp 或 hyperf/redis 驱动的延迟队列：
- 控制器接收参数（如订单 ID 数组、操作人 ID、发货单号等），生成唯一任务 ID，推入队列
- 消费者服务拉取任务，按分批 + 事务方式执行更新，并实时更新任务状态（如：processing → success / failed）
- 前端通过轮询或 WebSocket 查询任务进度，提升用户体验
添加业务校验与状态流转约束
ERP 中发货不是简单改字段，需符合业务规则：
- 校验订单当前状态是否为
confirmed或packed，禁止从cancelled或shipped再发货 - 检查库存扣减是否已完成（可关联
InventoryService进行预检） - 调用物流接口获取运单号后，再更新订单状态，避免“已发货”但无单号
- 使用状态机组件（如
hyperf/state-machine）显式定义order_status转换规则
记录可审计的操作日志与变更快照
ERP 对操作溯源要求高，不能只改状态：
- 插入
order_operation_logs表，记录操作人、时间、原始状态、目标状态、订单 IDs、备注（如“批量发货-仓库A”） - 对关键字段（如
shipping_no,shipping_at）做变更前快照，便于后续对账或回滚分析 - 日志表建议用 Hyperf 的
AsyncQueue异步写入，避免阻塞主流程
不复杂但容易忽略的是：批量发货后需触发下游动作，比如通知 WMS 出库、推送至财务系统生成应收单。这些宜通过事件机制（Hyperf\Event）解耦，在状态更新成功后派发 OrderShippedEvent，由监听器分别处理。
