hyperf框架批量修改crm客户跟进状态需解耦业务与操作入口，保障事务性、权限控制和可追溯性：一、用枚举+状态机定义合法状态及流转规则；二、封装followupbatchservice实现事务更新与日志记录；三、提供web、api、定时任务多入口；四、强化权限校验、二次确认、通知与快照审计。
Hyperf框架实现CRM客户跟进状态的批量修改，核心在于解耦业务逻辑与批量操作入口，避免直接在控制器里硬编码循环更新，同时保障事务一致性、权限控制和操作可追溯性。关键不在于“能不能改”，而在于“安全地、可控地、可审计地改”。
一、定义清晰的跟进状态模型与变更规则
跟进状态应作为独立业务实体管理，而非简单字符串字段。推荐使用枚举类 + 状态机约束：
- 创建
App\Enum\FollowUpStatus枚举，明确限定合法值（如PENDING、CONTACTED、QUOTED、CLOSED_WON）； - 在
FollowUp模型中通过访问器/修改器校验赋值，禁止非法状态写入； - 定义状态流转规则（例如不允许从
CLOSED_LOST直接跳回CONTACTED），批量修改前做预检，失败项单独返回提示，不中断整体流程。
二、封装原子化批量更新服务
避免在 Controller 中直接调用 update() 或 whereIn()，而是交由领域服务统一处理：
- 编写
FollowUpBatchService，接收客户ID列表（或筛选条件）+ 目标状态 + 当前操作人ID； - 内部使用事务包裹：先查出待更新记录（含原始状态、负责人、最后跟进时间等上下文），再执行批量更新；
- 同步写入操作日志表（
follow_up_batch_logs），记录批次ID、操作人、影响行数、原始/目标状态、执行时间； - 支持异步执行：对超千条数据，可投递至
hyperf/job队列，前端返回任务ID供轮询查询进度。
三、提供多通道批量入口，适配不同场景
用户批量操作路径应灵活，不局限于后台列表页勾选：
-
Web后台页面：复用 kingadmin 类风格的 action 下拉菜单，配合全选/反选 JS，提交时携带
selected_ids和action=update_status； -
API接口：提供
POST /api/v1/follow-ups/batch-status，支持传 ID 数组 或 SQL 条件（如{"where": {"owner_id": 123, "status": "PENDING"}}），后端做白名单字段校验； -
定时规则触发：结合 Hyperf 动态定时任务模块，配置“每日9点将超48小时未跟进的线索状态改为
STALE”，自动执行无需人工干预。
四、强化安全与可观测性
批量修改是高危操作，必须前置拦截与事后留痕：
- 权限校验：调用
AuthManager验证当前用户是否具备该客户池/部门的批量修改权限，禁止跨团队批量操作； - 敏感操作二次确认：前端弹窗显示“将修改 X 条记录的状态为【已报价】，确认继续？”，后端接口仍需校验 CSRF Token 或操作签名；
- 变更通知：更新完成后，向操作人推送站内信，并可选发送邮件摘要（含修改前后对比样例）；
- 数据快照（可选）：对关键客户，批量修改前自动保存一条
follow_up_snapshots记录，便于后续审计回溯。
