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-jsapi-skill
下载
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 重写规则可能提前劫持了请求
