前端页面要展示一批商品列表，服务后端接口还没写完。服务等？服务不如自己动手搭一个。JSON服务器就是服务干这个的——拿一个JSON文件当数据库，几分钟内跑起一套完整的服务REST API。我第一次用它是服务在一个内部工具项目里，后端同事请假了，服务我硬着头皮用json-server把原型撑了起来，服务结果比我预想的服务顺手太多。

它的服务核心逻辑简单到近乎粗暴：你提供一个db.json文件，里面按资源名组织数据，服务启动命令一跑，服务增删改查接口全部就位。服务比如文件里写一个posts数组，服务访问/posts就能拿到列表，服务/posts/1就是单条记录。POST、PUT、PATCH、DELETE 全支持，连分页、排序、模糊搜索都内置了。

{  "posts": [ {  "id": 1, "title": "第一篇", "author": "老张" }, {  "id": 2, "title": "第二篇", "author": "小李" } ], "comments": [ {  "id": 1, "postId": 1, "body": "写得不错" } ] }

装起来也就一行命令的事。npm install -g json-server，然后json-server --watch db.json，默认监听3000端口。想换端口加--port，想模拟网络延迟加--delay 1000，甚至还能自定义路由映射。这些参数不花哨，但每一个都踩在开发调试的真实痛点上。

我印象最深的一次是调一个无限滚动的列表页。后端的分页参数还没定，前端没法联调。我直接在db.json里塞了200条假数据，用_page和_limit两个查询参数模拟分页，前端逻辑跑通了，后端接口后来也按这个约定来实现。省掉了至少两轮扯皮。

它当然不是没有短板。数据存在内存里，进程一停就回到文件初始状态——除非你手动触发写回。并发写入基本别想，多个请求同时改同一条记录，结果不可预测。所以它只适合开发和原型阶段，上生产是绝对不行的。有人拿它做小型内部工具的持久层，我只能说胆子够大。

另一个容易被忽略的点是数据关系。JSON Server 不会自动帮你做联表查询，但支持_embed和_expand。比如/posts?_embed=comments会把每条post下面的comments一并带出来。这个功能在快速搭原型时特别省事，不用手写聚合逻辑。

自定义路由也很实用。默认资源名就是URL路径，但你可以通过一个routes.json文件把/api/v1/users映射到/users。前端代码里写的路径不用改，后端真实接口上线后换个base URL就行。

还有个小技巧：把db.json放进Git仓库，每次改完数据结构提交一次。团队成员拉下来直接跑，环境完全一致。比共享一个测试数据库省心得多，也不怕谁把数据搞脏。

要说它最大的价值，我觉得不是技术含量，而是把“先跑起来”这件事的门槛降到了几乎为零。很多时候我们卡住不是因为问题难，而是因为等待。JSON Server 让你不用等，先动起来，后面的事后面再说。