遇到的真实问题
刚入行那会儿，我经常遇到这种尴尬情况：写好了页面布局，准备连接后端接口，结果后端同事说："接口还没写完，你先等等。"
等啊等，一等就是一周，有时候甚至两周。我只能在那干坐着，或者写一些无关紧要的代码，感觉特别被动。
后来老鸟告诉我："兄弟，你不用等后端的，自己先造点假数据跑起来，等后端接口出来后再换掉就行了。"
我当时还不信，直到看到Mock.js这个工具，才发现原来前端开发可以这么爽！
什么是前后端分离？
简单说，就是前端只管页面和交互，后端只管数据和业务逻辑。就像两个人合作做菜，一个人负责摆盘（前端），一个人负责炒菜（后端），最后合成一道完整的菜。
但是，如果摆盘的师傅等炒菜的师傅先做好菜，那整个流程就很慢。所以聪明的做法是，摆盘师傅先拿一些假菜练习摆盘，等真菜来了再换上去。
Mock.js：前端的"造物主"
Mock.js就像是前端开发者的"造物主"，可以凭空变出各种数据来。比如我要100篇文章，它就能瞬间给我100篇；我要用户信息，它也能马上生成。
安装和使用
bash
npm install mockjs
然后就可以开始"造数据"了：
javascript
import Mock from 'mockjs'
// 比如我要造10篇文章的数据
const articles = Mock.mock({
'list|10': [{ // 生成10条数据
'id|+1': 1, // ID从1开始递增
'title': '@ctitle(10, 30)', // 随机中文标题，10-30个字符
'content': '@cparagraph(3, 10)', // 随机中文段落，3-10句话
'author': '@cname', // 随机中文姓名
'date': '@date("yyyy-MM-dd")' // 随机日期
}]
})
console.log(articles.list) // 就能看到10条随机文章数据
是不是很神奇？几行代码就能生成看起来很真实的测试数据。
实战：博客文章列表功能
我们来做一个具体的例子：博客文章列表页面。这个页面需要显示文章列表，还要有分页功能。
先看接口长什么样
一般后端会给我们这样的接口文档：
text
GET /api/posts?page=1&limit=10
返回数据格式：
{
"code": 200,
"msg": "success",
"data": {
"items": [...], // 文章列表
"pagination": {
"current": 1, // 当前页
"limit": 10, // 每页数量
"total": 100, // 总数
"totalPage": 10 // 总页数
}
}
}
用Mock.js造数据
javascript
import Mock from 'mockjs'
// 定义文章标签
const tags = ["前端", "后端", "AI", "职场", "面试", "算法"]
// 造45篇文章数据
const posts = Mock.mock({
'list|45': [{
'id|+1': 1, // ID自增
'title': '@ctitle(8, 20)', // 中文标题
'brief': '@cparagraph(1, 3)', // 文章简介
'totalComments|0-50': 1, // 评论数0-50
'totalLikes|0-1000': 1, // 点赞数0-1000
'publishedAt': '@datetime("yyyy-MM-dd HH:mm")', // 发布时间
'user': { // 用户信息
'id|1-10': 1, // 用户ID 1-10
'name': '@cname', // 用户姓名
'avatar': '@image("100x100", "#ccc", "#fff", "avatar")' // 头像
},
'tags': function() { // 标签，随机选2个
return Mock.Random.pick(tags, 2)
},
'thumbnail': '@image("300x200", "#eee", "#999", "thumb")' // 缩略图
}]
}).list
// 定义Mock接口
export default [
{
url: '/api/posts',
method: 'get',
response: ({ query }) => {
// 获取分页参数
const { page = '1', limit = '10' } = query
const currentPage = parseInt(page)
const size = parseInt(limit)
// 参数校验
if (isNaN(currentPage) || isNaN(size) || currentPage < 1 || size < 1) {
return {
code: 400,
msg: '页码或每页数量参数错误',
data: null
}
}
// 计算分页数据
const total = posts.length
const start = (currentPage - 1) * size
const end = start + size
const paginatedData = posts.slice(start, end)
return {
code: 200,
msg: 'success',
data: {
items: paginatedData,
pagination: {
current: currentPage,
limit: size,
total: total,
totalPage: Math.ceil(total / size)
}
}
}
}
}
]
代码解释
让我解释一下这段代码的关键部分：
@ctitle(8, 20)：生成8-20个字符的中文标题@datetime("yyyy-MM-dd HH:mm")：生成格式化的日期时间Mock.Random.pick(tags, 2)：从tags数组中随机选择2个标签'id|+1': 1：ID从1开始递增- 分页逻辑：
(currentPage - 1) * size计算起始位置
如何在Vite项目中使用
在你的vite.config.js中加入：
javascript
import { defineConfig } from 'vite'
import { viteMockServe } from 'vite-plugin-mock'
export default defineConfig({
plugins: [
viteMockServe({
mockPath: 'mock', // mock文件夹位置
enable: true, // 开启mock
})
]
})
这样启动项目后，访问/api/posts?page=1&limit=10就能得到Mock数据了。
为什么这样做很好？
1. 不用等后端了
以前：前端 → 等后端 → 开发
现在：前端 → Mock数据 → 开发 → 换真实接口
2. 可以测试边界情况
用Mock数据，我们可以轻松测试各种边界情况：
- 空数据列表
- 错误参数
- 大量数据
- 网络超时
3. 数据格式可控
Mock数据完全由前端控制，可以确保数据格式符合前端需求。
4. 提高开发效率
前端可以专注于页面交互和用户体验，不用被后端进度拖累。
实际开发中的注意事项
1. Mock数据要接近真实
Mock的数据格式要尽量和真实接口保持一致，否则后面对接口时会有麻烦。
2. 接口文档要明确
前后端最好先确定好接口文档，包括：
- 请求路径
- 请求方法
- 参数格式
- 返回数据结构
3. 错误处理也要Mock
不仅要Mock正常情况，还要Mock错误情况，比如网络错误、参数错误等。
真实接口来了怎么办？
当后端接口开发完成后，只需要修改请求的基础URL：
javascript
// 开发环境用Mock
const BASE_URL = import.meta.env.DEV ? '' : 'https://api.real.com'
// 发请求
fetch(`${BASE_URL}/api/posts?page=1&limit=10`)
或者在axios中配置：
javascript
// 开发环境
if (process.env.NODE_ENV === 'development') {
axios.defaults.baseURL = '' // Mock接口
} else {
axios.defaults.baseURL = 'https://api.real.com' // 真实接口
}
小结
通过Mock.js，前端开发者可以：
- 摆脱对后端的依赖
- 快速验证UI和交互
- 提高开发效率
- 更好地测试各种场景
这种开发模式已经成为现代前端开发的标准做法。下次再遇到后端没写完接口的情况，你就可以自信地说："没关系，我自己造数据！"
