关键在于用闭包或类封装可变状态以实现动态响应：闭包适合轻量单例接口（如开关通知），类适合多资源场景（如订单系统），msw支持真实请求流控制，需注意测试间状态隔离。
模拟带有状态变化的复杂后端接口，关键不是“固定返回值”，而是让 Mock 能记住请求历史、维护内部状态，并根据当前状态 + 请求参数动态响应。这需要跳出静态 JSON 模拟的思维，用可变变量 + 闭包或类封装状态逻辑。
用闭包封装状态和行为
适合轻量、单例式接口（如一个计数器服务、开关状态、分页列表的增删改）：
- 定义一个立即执行函数，内部声明状态变量（如 isLocked = false、items = []、page = 1）
- 返回一个函数，接收 request（含 method、url、body），内部根据 method 修改状态并返回对应响应
- 例如模拟「用户开关通知」接口：
POST /api/notify/toggle：每次调用翻转 notifyEnabled 值，返回新状态
用 Class 封装多状态、多资源的 Mock 服务
适合中大型测试场景（如模拟订单系统：订单创建 → 支付 → 发货 → 完成，每步改变订单 status）：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 定义 MockOrderService 类，属性包含 orders = new Map()、nextId = 1
- 方法如 create(orderData)、pay(orderId)、ship(orderId)，各自更新对应订单的 status 字段
- 在 Jest 或 MSW 中，把该实例挂载为全局 mock 对象，或通过工厂函数注入到测试用例中
配合 MSW（Mock Service Worker）实现真实请求流控制
MSW 允许你在 handler 中写任意 JS 逻辑，天然支持状态驱动：
- 在 rest.post('/api/order') handler 中，读取内存中的订单列表，生成新订单并 push 进去
- 在 rest.patch('/api/order/:id') 中，根据 req.params.id 查找订单，校验当前 status 是否允许该操作（如只能从 ‘created’ → ‘paid’），再更新
- 用 context.status(400).json({ error: 'Invalid transition' }) 模拟业务校验失败
注意状态生命周期与测试隔离
避免测试间状态污染是核心难点：
- 每个 test case 开始前，重置 mock 状态（如 mockService.reset() 或 jest.clearAllMocks()）
- 不要在模块顶层定义共享状态变量；把状态初始化放在 beforeEach 或 mock factory 内部
- 若用 MSW，推荐搭配 setupServer + server.resetHandlers()，而非全局持久化 handler
不复杂但容易忽略。状态模拟的本质是把后端业务规则“翻译”成前端可执行的 JS 逻辑，重点不在“像不像”，而在“能不能触发你代码里真实的分支路径和副作用。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
