这期是给被后端还没写好 / 测试环境挂了 / 依赖列表越来越长折磨过的人准备的。三个东西都很小但都能当天下午省下半小时。Mock Service Worker在网络层拦截而不是在代码里打洞接口 mock 的常见做法有两种在 axios 拦截器里if (process.env.NODE_ENV development)返回假数据或者起一个本地假服务改 baseURL。前者的问题是生产代码里塞了测试分支后者的问题是多起一个服务、多一份配置、多一种出错方式。MSW官网 mswjs.io仓库组织名mswjs走的是第三条路它注册一个 Service Worker在请求真正离开页面时拦截并返回响应。你的代码发出的还是那个真实的axios.get(/api/orders)它完全不知道自己被打扰了。MSW 文档里的说法是拦截发生在网络层而不是去 patchfetch或axios本身。这意味着同一份 mock 定义可以同时用在本地开发、单元测试、E2E、甚至给同事演示的 Demo 环境里。装起来npmi-Dmsw# 生成 worker 脚本到 public/vue-cli 项目就是 publicVite 是 publicnpx msw init public/--save定义 handlerv2 的写法用http命名空间// src/mocks/handlers.jsimport{http,HttpResponse}frommswexportconsthandlers[// 你的业务接口http.get(/api/poi/list,(){returnHttpResponse.json({code:0,data:[{id:1,name:西湖,lng:120.15,lat:30.25}],})}),// 甚至可以直接 mock 第三方的 HTTP 接口http.post(/api/order/create,async({request}){constbodyawaitrequest.json()returnHttpResponse.json({orderId:MOCK-001,echo:body})}),// 模拟失败测你的错误兜底http.get(/api/map/config,()HttpResponse.error()),]启动放在入口最前面// src/main.jsif(process.env.NODE_ENVdevelopment){const{setupWorker}awaitimport(msw/browser)const{handlers}awaitimport(./mocks/handlers)constworkersetupWorker(...handlers)awaitworker.start({onUnhandledRequest:bypass})// 没定义的请求放行不拦}onUnhandledRequest: bypass这个参数值得记一下没匹配到 handler 的请求照常发出去不至于因为漏写一条规则整个页面白屏。对你Vue 2 地图最实用的两个场景后端接口还没写好时先并行开发把约定好的返回结构写成 handler前端自己先跑通渲染和交互接口出来只需删掉那几行测边界态HttpResponse.error()一行就能模拟请求失败配合超时、500、空数组把错误兜底全部覆盖一遍不用求人配合你演故障一个必要的提醒MSW 拦的是fetch/ XHR 这类请求。地图 SDK 内部有些走 JSONP 或直接插script的加载通常拦不到——那种情况要 mock 的是你自己业务层调用的那个函数而不是它的底层请求。别为此怀疑 MSW也别怀疑自己。另外它是 dev/test 依赖-DService Worker 只在开发和测试环境启动生产构建里那段if会被摇掉不会带上线上。两个命令专门对付package.json里的历史沉积npm why 包名—— 想知道某个包为什么会出现在你的依赖树里npmwhy momentnpmwhy lodash它会输出一棵路径树告诉你是xxx-loader2.1依赖的yyy1.0依赖的moment。排查我明明没用它bundle 里为什么有 60KB 的 moment这类问题时这是最短路径。比在node_modules里翻文件快一个数量级。npx depcheck—— 反过来找出package.json里声明了、但代码里根本没 import 的包。npx depcheck它直接扫依赖树找同名文件node_modules/xxx/index.js不需要项目能跑起来。对老项目尤其有效那种三年没清理的依赖列表一跑经常能挖出五六个当年的试验品。两个配合起来的用法是先用depcheck看哪些是自己写代码时留下的死依赖删掉再用npm why查那些删不掉的间接依赖到底被谁拽着——很多时候你会发现一个不起眼的老插件把整个 Moment 生态锁在了构建产物里。顺带一句加依赖的成本经常被低估。前端项目里npm i xxx只要三秒但它带来的体积、安全审计项、以及这个包还在维护吗的长期关注都是几年后由别人来还的债——常常是你自己。一句名言Make it work, make it right, make it fast.先让它能跑再让它正确最后让它快。这句话通常归于 Kent Beck。之所以值得再读一遍是因为它的顺序是不可调换的而我们的本能恰好是反的。绝大多数前端性能优化之所以做不动是因为跳过第一步直接做第三步组件还没跑通就先上Object.freeze、虚拟列表、异步组件结果功能一改就得重来一遍。反过来work → right → fast给了一个很好用的判断work功能在真实数据下能跑完right命名、边界处理、错误兜底、组件拆分讲得出去别人能接手fast这时候才允许你为了性能做不舒服的取舍而真正让人不舒服的真相是多数项目走到第三步时会发现已经足够快了——性能问题里很大一部分本来就是重复渲染“请求没合并”图片没压缩这种正确性问题在 right 阶段顺手就修完了。顺序对了第三步常常短得让自己意外。最后今天这三样有个共同点都是在别处解决的思路。MSW 不在业务代码里加分支它把 mock 挪到网络层于是代码干净、场景可复用npm why/depcheck不在 node_modules 里翻文件把考古交给工具Kent Beck 那句话本质也是换个战场——别在同一个地方同时解决正确性和性能先把正确性解决干净剩下的战场会自己缩小。我们太习惯在问题原地硬扛了写if (dev)、手动 grep 依赖、一边改 bug 一边加缓存。这三个小技巧算不上什么大智慧只是每次往旁边挪一步然后就少背一点债。下午如果接口还没好不妨先花十分钟给 MSW 写一条 handler 试试。