mock的核心是解决联调阻塞、异常难复现、接口未就绪等实际卡点;该用在并行开发、依赖隔离、极端数据构造,不该用于已有真实接口、不校验行为或替代文档;mock.js与msw差异在于拦截层级、环境安全性和协作成本;手写时需说明可变长度、动态字段、函数响应的设计意图;排查失效要按请求方式、url匹配、引入时机、拦截覆盖顺序检查。

回答 JS 中 Mock 模拟类面试题,核心不是背语法,而是讲清“为什么这么模拟”和“问题出在哪”。面试官想确认你是否真用过 Mock 解决过开发或测试中的实际卡点,比如联调阻塞、异常分支难复现、接口未就绪却要推进 UI。
明确 Mock 的定位和适用边界
被问“什么时候该用 Mock?什么情况不该用?”,直接点出场景本质:
- 该用:前后端并行开发时替代未完成接口;测试中隔离外部依赖(如 API、定时器、localStorage);构造极端数据(空列表、超长文本、500 错误响应)验证兜底逻辑
- 不该用:已存在真实可用接口还硬 mock(造成环境不一致);mock 后不校验行为(比如只返回数据却不检查是否调用了正确 URL 或参数);用 Mock 替代接口文档沟通(Mock 是契约的验证手段,不是替代品)
对比 Mock.js 和 MSW 等方案的关键差异
当被问“Mock.js 和 MSW 你怎么选?”,聚焦三点现实约束:
DMap GL地图JSAPI(dmapgl)开发指南。用于编写、审查、调试 DMap 地图 API 代码,涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 拦截层级:Mock.js 劫持 XHR,对 fetch/axios 无效(除非手动封装);MSW 基于 Service Worker,能拦截所有浏览器发起的请求,更贴近真实网络链路
- 环境控制:Mock.js 需靠环境变量或构建时剔除,否则有上线风险;MSW 默认仅在 dev/test 环境激活,天然安全
- 协作成本:Mock.js 规则写在前端代码里,后端无法感知;MSW 的 handler 可导出为标准 OpenAPI 格式,支持前后端共用一份契约
手写一个典型 Mock 场景,突出设计意图
若被要求现场写一段模拟用户列表的代码,别只堆语法,边写边说明决策:
- 用
Mock.mock('/api/users', { "list|5-10": [...] })—— 因为需要可变长度数据,覆盖分页/空状态等边界 - 字段用
@cname、@email而非固定字符串 —— 保证每次请求返回不同数据,避免缓存误判或逻辑耦合 - 对 POST 接口加函数响应:
Mock.mock('/api/users', 'post', (options) => { ... })—— 为了读取options.body并返回带 ID 的新建对象,模拟真实创建流程
调试 Mock 失效时的排查路径
被问“mock 不生效,怎么查?”,按执行流顺序列步骤:
- 确认请求方式:是 fetch 还是 axios?Mock.js 默认不拦截,需额外适配(例如 axios 的 adapter 或封装 request 方法)
- 核对 URL 匹配:正则是否写错(如
/^\/api\/users$/忘了起止符)、通配符是否支持(/api/users/*在 Mock.js 中有效,但/api/users/**无效) - 检查引入时机:Mock.setup() 是否在请求发起前执行?Vue 项目中是否在 main.js 最顶部引入,而非组件内懒加载?
- 验证是否被其他拦截器覆盖:比如 Vue Devtools、某些代理插件或本地 Nginx 重写规则可能提前劫持了请求










