Mock的核心价值是打破前后端依赖困境，实现并行开发、提前验证接口契约、覆盖异常场景；高频考察点包括工程化意识、协作痛点理解及方案选型能力。
Mock 在前端开发和面试中，已不是“用不用”的问题，而是“怎么用得对、用得稳、用得有分寸”的问题。面试官问 Mock，很少只考你 Mock.mock() 怎么写，更多是在考察：你是否理解前后端协作的真实痛点、是否具备工程化意识、能否在脱离后端时依然保障开发节奏和质量。
Mock 的核心价值与高频追问点
面试官常会以“为什么需要 Mock”切入，这不是让你背定义，而是看你有没有真实项目视角：
- 后端接口未就绪，但页面交互逻辑、状态流转、错误边界都要提前验证
- 联调阶段发现字段名/嵌套结构和文档不一致，靠改死数据太脆弱，Mock 能统一源头
- 要测试“服务器返回空数组”“网络超时”“500 错误”等非 happy path 场景，真实环境难复现
- 团队共用同一份接口文档，Mock 数据可作为文档的可执行验证——文档改了，Mock 也得同步，否则就是漏洞
答到这里，如果能补一句：“所以我一般把 Mock 规则和接口文档放在一起维护，甚至用 Swagger + Mock 工具自动生成”，立刻拉开差距。
Mock.js 常见写法与避坑要点
写法本身简单，但面试官爱在细节里挖坑：
Wjs Uploading Video
下载
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
-
规则语法别硬记，抓主干：
"list|5-10"表示生成 5–10 条数据；"id|+1"表示自增；"@date('yyyy-MM-dd')"是日期占位符。重点是理解“模板驱动”逻辑——你定义的是结构和约束，不是具体值 -
慎用全局拦截：比如
Mock.setup({ timeout: '200-600' })会影响所有请求，包括真实登录接口或第三方 SDK，建议只在开发环境启用，并用process.env.NODE_ENV === 'development'包裹 -
真实请求没被拦截？先查三件事：是否在 axios 实例创建前引入了 mock.js；是否用了 Vite 的 proxy 代理，导致请求根本没走到 JS 层；是否 mock 规则里的 URL 和你发的请求路径大小写/斜杠不一致（如
/api/uservs/api/user/）
Mock 方案选型的实战判断逻辑
当被问“Mock.js 和 MSW 你怎么选”，不要只说优缺点，要带场景：
- 小团队单页应用、快速验证 UI 和流程 → 用 Mock.js，零配置、上手快、规则直观
- 中大型项目、需要精确控制请求生命周期（如模拟延迟、重试、条件响应）、未来可能做 E2E 测试 → 选 MSW，它工作在 Service Worker 层，不污染业务代码，且可复用于 Cypress 等工具
- 已有后端服务，只想临时改某几个接口响应 → 用 Vite/Webpack 本地代理 + rewrite，不引入新库，改动最小
补充一句很加分的话：“我们组现在是 Mock.js 做日常开发，MSW 做自动化测试，两者不冲突，按需切换。”
面试中如何展示工程素养
高级一点的面试，会把你拉进一个具体情境里考你：
-
“接口字段下周才定稿，但明天就要给产品演示，你怎么处理？”→ 回答要体现分层：先用 Mock.js 搭出骨架（字段名用
@word占位），再约定好字段语义和类型注释（如// status: 'active' | 'inactive' | 'pending'），最后等文档落地，只改 mock 规则，不动组件逻辑 -
“Mock 数据上线了怎么办？”→ 必须强调构建时剥离：Webpack 用 DefinePlugin 注入环境变量，Vite 用
define配置，在生产环境直接跳过 mock 初始化；同时 CI 流程里加检查，禁止mock相关代码出现在 prod 构建产物中 -
“怎么保证 Mock 数据和真实接口长期一致？”→ 提到方案：用 JSON Schema 描述接口，Mock.js 或 MSW 基于此生成数据；或用 OpenAPI（Swagger）规范，配合工具如
openapi-backend自动生成 mock 服务
不复杂但容易忽略。
