mirage测评：这些坑先看
mirage测评不能只说好不好用，我更想把踩坑顺序摊开讲。它做前端 mock 很快，能模拟接口、数据库和延迟，但如果一上来就乱写返回值，后面联调会反噬。下面按实际落地流程走一遍。
第1步：先判断你到底需不需要它
我的 mirage测评结论比较直接：如果你只是偶尔写两个假数组，没必要上 Mirage JS；如果你有登录、列表、详情、筛选、分页，且后端经常慢半拍，它就值。
它的优势是能把 API 行为集中管理，而不是散在组件里。页面里还是正常发请求，Mirage 在浏览器里拦住并返回数据。这样以后换真接口，改动范围小。
第2步：别急着写模型，先定接口形状
不少人一上手就 models、factories 全开，结果字段名和后端文档对不上。我的做法是先拿接口文档或口头约定，写出请求方法、路径、入参、返回结构。
比如分页接口到底返回 {list,total}，还是 {data:{items,total}}，这件事要先定。Mirage 写得再漂亮，只要结构不一致，页面联调时还是要返工。
第3步：逐个接口加，不要一次铺满
我见过一个项目第一天就 mock 了 40 个接口，后面没人维护，三天后全失真。更靠谱的流程是按页面走：先登录，再列表，再详情，再操作按钮。
每加一个接口就打开页面点一遍，看 loading、空数据、成功提示、失败提示有没有覆盖。Mirage 的价值不只是“有数据”，而是让你提前看到页面在不同状态下会不会垮。
第4步：模拟慢接口和错误，别只测顺风局
Mirage 可以设置 timing，也可以返回 new Response(500, {}, {message:'error'}) 这类错误。这个功能比造 20 条假数据更有用。
我做表单页时会专门测三种情况：提交按钮连点、接口 2 秒才返回、后端返回字段错误。很多“线上偶现”的问题，其实本地用 Mirage 就能提前揪出来。
第5步：联调时一个个放行真实接口
Mirage 支持 passthrough，让没被 mock 的请求走真实网络。联调时别一次全部关掉，容易分不清问题在哪。我的流程是保留大部分 mock，只把当前要联调的接口放出去。
这套测评下来，我觉得 Mirage 不适合懒人随手糊数据，适合愿意把接口契约管起来的团队。用得认真，它省的是沟通成本；用得随意，它会制造假安全感。
常见问题
mirage测评里最大的缺点是什么？
最大缺点是维护成本。接口字段变了，Mirage 也要跟着改；如果没人负责同步，它会变成过期假后端。
Mirage JS适合大型项目吗？
适合局部使用，比如新模块、新页面、复杂状态测试。全项目长期完全依赖 Mirage 不太现实，除非团队有明确维护规范。
Mirage和直接写mock数据有什么区别？
直接写 mock 数据通常在组件里，后面难清理；Mirage 模拟的是请求层，页面代码仍按真实接口方式写，更接近联调环境。