mirage避坑：原理讲透再用
mirage避坑要从原理说起。很多问题不是代码难，而是把 Mirage 当成真实后端、抓包代理或万能 mock 平台。它本质是在前端运行时拦截请求并返回假响应，边界弄清楚，坑会少一半。
先给结论：它模拟的是接口行为，不是后端能力
Mirage JS 的核心逻辑很朴素：页面正常发 fetch 或 XMLHttpRequest，请求被 Mirage 的服务捕获，匹配到你写的路由后，返回你定义的数据。它让前端以“像真的一样”的方式开发，但它不等于真的后端。
所以 mirage避坑第一条就是别过度相信 mock。鉴权、数据库事务、文件上传、复杂权限、并发写入，这些后端细节 Mirage 可以模拟表面流程，但不能替你验证真实可靠性。
坑一：路由匹配错，以为工具坏了
Mirage 是按方法和路径匹配的。GET /api/user 和 POST /api/user 不是一回事，/api/users/1 和 /users/1 也不是一回事。路径差一个前缀，就会直接漏过去或报未处理请求。
我的做法是把接口路径集中写，不在页面里到处拼字符串。遇到请求没返回，先看 Network 面板，再看 Mirage 路由。别一上来重装依赖，八成不是安装问题。
坑二：假数据太完美，测不出真问题
很多 mock 数据都长得像样板间：名字三个字、图片必有、价格正常、状态只有成功。这样的数据看着舒服，但没用。真实接口里最容易出事的是空值、长文本、边界数字和奇怪状态。
我会刻意放几条脏数据：头像为空、标题 50 个字、金额为 0、列表为空、分页 total 小于 pageSize。UI 能扛住这些，线上才少翻车。Mirage 的强项正是让你低成本制造麻烦。
坑三：返回结构和后端不一致
这是联调时最烦的坑。前端按 Mirage 的 {users:[...]} 写完了，后端实际返回 {code:0,data:{list:[]}}，页面改一圈，白忙。
解决办法不复杂：mock 前先定接口契约。哪怕后端还没开发，也要先约定字段名、分页格式、错误码。Mirage 只是执行这个契约，不要让它自己长出一套标准。
坑四：生产环境残留mock
Mirage 本来就该服务开发环境。如果线上还启动 mock，轻则接口异常，重则用户看到假数据。这个坑不常见，但一旦发生很难看。
稳妥做法是入口处加环境判断，只在 development 或明确的 mock 模式下启动。打包前全局搜 makeServer、createServer，CI 里也可以加检查。别把“我记得删了”当流程。
收个尾：用它提速，别让它做裁判
Mirage 最值钱的地方，是让前端在接口没好时也能推进页面，并且提前测试异常状态。它不是后端替身，也不是接口正确性的最终证明。
真正的 mirage避坑口诀很短：路径对齐、结构对齐、数据故意不完美、上线绝不启动。按这四条来，它会是帮手；反过来，它就会变成返工制造机。
常见问题
mirage避坑最重要的一点是什么？
最重要的是返回结构必须贴近真实后端。字段名、外层包装、分页格式一旦不一致，后面联调会大量返工。
Mirage能不能用于生产环境？
不建议。Mirage 主要用于开发和演示，生产环境应该走真实接口。除非是非常明确的离线演示页面，也要单独隔离。
Mirage为什么有些请求拦不住？
常见原因是路径或方法没匹配上，或者请求走了不同域名但没有配置 passthrough。先看浏览器 Network，再核对 routes。