从 Vue 到简历：我在北京通勤路上折腾出的实战笔记
上周五晚上十一点，我坐在回天通苑的地铁上，耳机里放着《前端早读课》的播客，脑子里却还在想今天被产品经理怼的那个需求：“这个组件能不能做得像 Llama 那样智能一点？”我一脸懵——Llama 是 Meta 的大模型啊大哥！但转念一想，也许他只是想要个“更聪明”的交互体验。这让我意识到：技术再酷，也得落地到项目里才有价值。
作为一个在北京每天通勤一小时的前端工程师，我最近正处在要不要跳槽的纠结期。一方面，当前公司用的技术栈稳定得有点“古董”（Vue 2 + webpack 4，懂的都懂）；另一方面，我又担心跳出去后面对一堆新玩意儿手忙脚乱。为了给自己攒点底气，我决定把 Vue.js 生态系统彻底摸一遍，顺便搞个小项目练练手——既能写进简历，又能传到 GitHub 上装点门面（别笑，这年头没几个 Star 真的不好找工作）。
起手式：为什么选 Vue？不是 React？
说实话，React 我也学过，Hooks 写起来确实优雅。但在我们这种传统行业公司，Vue 的模板语法对新人更友好，而且团队里老哥们习惯了选项式 API，一时半会儿改不了。更重要的是——Vue 的文档是真的香！中文社区活跃，遇到问题搜一下基本都有答案。不像某些框架，报错信息长得像加密电报。
于是，我决定以 Vue 3 为核心，搭配 Vite、Pinia、Vue Router 等官方生态工具，构建一个“智能任务管理面板”。名字我都想好了：LlamaTask（蹭个热点，产品经理应该会满意吧？）。
踩坑实录：从“Hello World”到线上事故
1. 组合式 API 的真香与真坑
一开始我死活不用 <script setup>，觉得“太激进”。直到某次重构一个表单组件时，发现逻辑复用简直地狱——mixins 冲突、this 指向混乱，改个字段要查半天。咬牙切齿切换到组合式 API 后，世界清净了。
<script setup>
import { ref, computed } from 'vue'
import { useTaskStore } from '@/stores/task'
const taskStore = useTaskStore()
const newTask = ref('')
const isValid = computed(() => newTask.value.trim().length > 0)
function addTask() {
if (isValid.value) {
taskStore.add(newTask.value)
newTask.value = ''
}
}
</script>
这段代码现在看很简单，但当时我卡在 ref 和 reactive 的选择上纠结了半小时。后来明白：简单状态用 ref，复杂对象用 reactive。别想太多，先跑起来再说。
2. Pinia：比 Vuex 更清爽的状态管理
我们项目之前用 Vuex，配置文件长得像毕业论文。迁移到 Pinia 后，store 文件直接变成函数式写法，测试也方便多了。
// stores/task.ts
import { defineStore } from 'pinia'
export const useTaskStore = defineStore('task', {
state: () => ({
tasks: [] as string[],
filter: 'all' as 'all' | 'active' | 'completed'
}),
getters: {
filteredTasks: (state) => {
if (state.filter === 'active') return state.tasks.filter(t => !t.completed)
if (state.filter === 'completed') return state.tasks.filter(t => t.completed)
return state.tasks
}
},
actions: {
add(task: string) {
this.tasks.push({ text: task, completed: false })
}
}
})
重点来了：Pinia 支持 TypeScript 推导！不用再写 interface 套娃，IDE 自动提示爽到飞起。上周上线时，测试小姐姐居然没提一个 bug，我差点以为她请假了。
3. Vite：快到让我怀疑人生
以前启动项目要等 30 秒，现在 vite dev 秒开。HMR（热更新）快得离谱，改一行 CSS 都不用刷新页面。最夸张的是 build 时间——从 webpack 的 90 秒降到 8 秒！那天我激动地在群里发了个“Vite 牛逼”，结果运维小哥回我：“你是不是又没关 sourcemap？” 😅
性能优化：别让用户等成化石
做技术博客的人总爱谈性能，但真实项目里，往往是为了应付老板的 KPI。不过这次我是认真的——LlamaTask 要跑在低端安卓机上也不能卡。
我做了三件事：
懒加载路由：首页只加载核心组件
// router/index.ts const Home = () => import('@/views/Home.vue')虚拟滚动：任务列表超过 100 条就上
vue-virtual-scroller防抖输入：搜索框加 300ms debounce，避免疯狂触发计算
效果如何？用 Lighthouse 测了一下：
| 指标 | 优化前 | 优化后 |
|---|---|---|
| FCP | 2.1s | 0.8s |
| TTI | 3.5s | 1.2s |
| Bundle Size | 1.8MB | 620KB |
虽然离 PWA 还差得远，但至少比隔壁组那个“首屏白屏 5 秒”的项目强多了（手动狗头）。
GitHub 与简历：让代码替你说话
折腾完这一套，我把 LlamaTask 传到了 GitHub。README 写得贼认真，连部署链接和 Lighthouse 报告截图都放上了。还特意加了个 CONTRIBUTING.md，假装自己是个开源大佬。
其实我心里清楚：面试官不会细看你几百行代码，但他们一定会看你的工程规范和文档意识。比如：
- 是否用 ESLint + Prettier 统一风格？
- 是否有单元测试（哪怕只有 20% 覆盖率）？
- 是否用语义化 commit（feat: add task input validation）？
这些细节，在简历上写“熟悉前端工程化”可比干巴巴的“精通 Vue”有力得多。
最后：跳还是不跳？
写这篇文章的时候，我已经收到了两家公司的面试邀约。一家要求 Vue 3 + TypeScript + 微前端经验，另一家直接问：“你 GitHub 上那个 LlamaTask 能讲讲设计思路吗？”
说实话，我还没决定去哪家。但至少现在，我不再是那个听到“Llama”就发慌的小前端了。技术人的底气，从来不是来自跳槽，而是来自亲手写过的每一行代码。
如果你也在迷茫期，不妨试试：找个周末，关掉微信，开个新 repo，用最新的技术栈做个玩具项目。不为别的，就为下次写简历时，能理直气壮地写上一句：
主导 Vue 3 全家桶项目从 0 到 1，GitHub 获得 XX Star（哪怕只有 2 个）
毕竟，在这个卷成麻花的前端圈，能跑起来的代码，永远比完美的计划更有说服力。
P.S. 地铁到站了，下篇可能聊聊“如何用 Vue + Web Worker 实现本地 AI 推理”——开玩笑的，Llama 跑不动，但 TinyLLM 或许可以？
评论 0