技术文章

我在县城远程带新人写Vue的踩坑记录

说实话，回县城老家远程办公快两年了，当初那个一心只想在大厂卷出头的做题家，现在每天最大的烦恼居然是村口大喇叭太吵影响我敲代码。作为一个坚定的Vim党，我平时写代码基本不碰VSCode或者WebStorm，全靠终端和Neovim插件续命。组里同事都觉得我是个异类，但习惯了肌肉记忆后，那套键位真的回不去了。

最近组里接了个县城智慧农业的内管后台，后端那几个老哥用Springboot把接口撸得飞起，结果前端页面没人写。产品经理天天在群里催进度，领导一拍大腿，让我带刚招的两个应届生搞前端。正好我最近也在刷前端面试题准备年底看看有没有更好的远程机会，干脆就边带人边自己梳理，弄了这份零基础入门指南。

别整虚的，先跑起来

带新人最怕一上来就讲底层原理，应届生本来就容易懵。我直接让他们用Vite起项目，现在都2024年了，千万别再碰Vue CLI和Webpack了，那冷启动速度能让人等到怀疑人生。

npm create vite@latest my-agri-admin -- --template vue
cd my-agri-admin
npm install
npm run dev

看着浏览器里瞬间弹出的Vue Logo，两个新人的眼睛都亮了。我顺势跟他们强调，Vue的核心就是组件化。别把几百行代码全塞在一个文件里，我平时对性能优化比较痴迷，见过太多因为组件拆分不合理导致Vue响应式追踪开销过大的惨案。

我的建议是：按业务模块拆，一个页面尽量不超过300行。遇到复杂的表格或者表单，直接抽成独立组件，通过defineProps和defineEmits传值。

跟后端老哥联调的正确姿势

后端兄弟的Springboot接口写得倒是规范，但前端如果直接裸调接口，代码绝对没法看。我花了一下午教他们封装Axios。

这里有个坑必须提：很多新手喜欢在每个组件里写一遍请求拦截，导致代码极其冗余。我直接甩给他们一个基础的拦截器模板：

import axios from 'axios'
import { ElMessage } from 'element-plus'

const request = axios.create({
  baseURL: '/api',
  timeout: 10000
})

request.interceptors.request.use(config => {
  const token = localStorage.getItem('token')
  if (token) {
    config.headers.Authorization = `Bearer ${token}`
  }
  return config
})

request.interceptors.response.use(
  response => {
    if (response.data.code !== 200) {
      ElMessage.error(response.data.msg || '系统开小差了')
      return Promise.reject(new Error(response.data.msg))
    }
    return response.data
  },
  error => {
    ElMessage.error('网络异常，请稍后再试')
    return Promise.reject(error)
  }
)

export default request

有了这个，他们再去调后端的Springboot接口，代码瞬间清爽了不少。顺便提一嘴，联调的时候记得让后端把跨域配好，别在前端搞什么代理，生产环境迟早要炸。

那些让人头秃的渲染细节

带人的过程中，我发现他们对v-if和v-show的区别总是搞不清楚。我干脆给他们整理了个表格，贴在工位（其实是他们县城出租屋）的墙上：

特性	v-if	v-show
DOM操作	真正的条件渲染，销毁/重建DOM	始终渲染，仅切换CSS display
编译过程	惰性加载，初始条件为假时不编译	编译阶段就渲染好
性能消耗	切换开销高	初始渲染开销高
适用场景	运行时条件很少改变	频繁切换显示状态

上周五晚上加班，有个新人写了一个包含上千条数据的设备列表，为了图省事全用了v-if控制展开收起，结果页面卡得连鼠标都动不了。我当时真的想砸键盘，赶紧让他改成v-show，并且给列表加上虚拟滚动。

说到列表渲染，必须吐槽一下key的滥用。很多新手喜欢用index作为key，这在涉及列表项删除、排序时，会导致严重的渲染错误和性能下降。我逼着他们把key全换成了后端返回的唯一设备ID，这才算把性能隐患掐死在摇篮里。

不用IDE怎么调试前端？

作为Vim党，最常被问到的问题就是：“你不用IDE，前端怎么Debug？”

其实现在Neovim的生态已经很完善了。我给他们演示了一下怎么用Chrome DevTools配合Vim进行调试。在代码里打上debugger，然后在Chrome里断点。如果是复杂的逻辑，我会在Neovim里配置nvim-dap，直接连着Node.js调试。

不过对于刚入门的新人，我还是建议先用VSCode过渡。等他们对Vue的生命周期、响应式原理摸透了，再考虑折腾Vim也不迟。毕竟工具只是手段，写出健壮的代码才是目的。

另外，做县城这种ToG或者ToB的项目，浏览器兼容性是个绕不开的坎。上周测试妹子跑过来，说有个老用户的页面白屏了。我远程一看，好家伙，用的还是十年前的IE11，甚至还有个奇葩的双核浏览器兼容模式。

没办法，只能老老实实加上Babel的polyfill，并且在CSS里避开一些太新的特性。这也算是一种另类的“性能优化”吧，毕竟让老设备能流畅跑起来，也是一种用户体验。

写在最后

带这两个新人这半个月，虽然每天被各种奇葩Bug搞得焦头烂额，但看着他们从连组件传值都搞不明白，到现在能独立扛起几个模块，心里还是挺有成就感的。

其实前端开发没那么神秘，无非就是理解数据驱动视图的本质，然后不断在用户体验和代码可维护性之间找平衡。我当年也是个只会死磕算法的小镇做题家，现在在县城远程办公，反而让我有更多时间去思考代码本身，而不是被无意义的内耗裹挟。

年底面试的时候，要是面试官问起Vue的底层原理，我大概会把这段时间带人踩过的坑，结合我搞性能优化的经验，好好跟他们吹……哦不，好好交流一下。不说了，产品经理又催着要加个数据大屏的需求，我得去切屏敲代码了。