Composition API：逻辑复用的快乐与痛苦
组合式 API：双刃剑Composition API 是 Vue 3 的灵魂。它允许我们将逻辑通过 Hooks（Composables）的方式进行提取和复用。 理想很丰满我想象中的代码： 123const { user } = useUser()const { articles } = useArticles()const { loading } = useLoading() 清爽、干净、模块化。 现实很骨感实际写出来的代码： 123const { user, loading: userLoading, error: userError } = useUser()const { articles, loading: articleLoading, error: articleError } = useArticles()// 命名冲突！到处重命名！ 而且，如果你把所有逻辑都堆在 setup 里，不加以拆分，它就会变成一个巨大的面条代码（Spaghetti Code），比 Opt...
组件通信：Props 传值传到手抽筋
Props, Emit, Provide, Inject…Vue 的组件通信方式多达十几种。父子通信用 Props/Emit，跨层级用 Provide/Inject，兄弟组件用 EventBus（Vue 3 移除了，得自己手写或用mitt），全局状态用 Pinia。 传值的痛苦当你有 5 层组件嵌套，最外层的组件想传个 ID 给最里面的组件。Props Drilling（属性透传）简直是灾难。 Parent -> Child -> GrandChild -> GreatGrandChild -> Target 每一层都要声明 Props，写得我想吐。虽说可以用 provide/inject，但不仅失去了类型推断的便利（TS 还要额外定义 InjectionKey），而且数据流变得难以追踪。
Pinia：Vuex 的继任者，好吃又好用
菠萝（Pinia）真好吃Vuex 复杂的 mutation, action, getter 曾让人头大。Pinia 的出现，简直是清流。 为什么是 Pinia？ 没有 Mutation：终于不用为了改个状态写那繁琐的模板代码了，直接在 Action 里改，或者直接改！ TypeScript 友好：完美的类型推断，不用像 Vuex 那样写一堆泛型接口。 极简 API：defineStore 一把梭。 逐渐掉光的头发随着学习的深入，我发现事情并不像我想象的那么简单。Pinia 这个知识点，简直是我的噩梦。 文档里写得轻描淡写，实际用起来坑巨多。比如，我在 store 里解构 state，结果响应性丢了！ 12const store = useUserStore()const { name } = store // ❌ 响应性丢失 必须用 storeToRefs(store)。这种细节，一旦不知道，就是一下午的调试时间。 令人头秃的细节在这个快速发展的前端时代，技术的更新迭代速度简直让人窒息。每一次框架的更新，不仅带来了新的特性，也带来了新的焦虑。作为一名追求极...
样式设计：CSS 也就是随便写写... (并没有)
CSS 的痛与乐作为一个前端，最怕的不是写 JS 逻辑，而是调 CSS 样式。居中？对齐？适配？每一个词都能让猛男落泪。 Vue 中的 Scoped CSSVue 提供了 <style scoped>，这简直是防止样式污染的神器。它通过给元素添加唯一的 data-v-xxx 属性，确保你的样式只在这个组件内生效。 123.example[data-v-f3f3eg9] { color: red;} 但是！当你试图修改子组件的样式时（比如修改 Element Plus 的组件样式），scoped 就变成了拦路虎。这时候你就得用深度选择器 :deep()。 123.parent :deep(.child) { /* 这样才能穿透过去 */} 之前不知道这个，我傻傻地去写全局样式，结果污染了整个项目，被组长骂了一顿。 动态样式Vue 3 允许我们在 CSS 中绑定 JS 变量： 123.text { color: v-bind(color)} 太酷了！这才是现代化开发嘛！ 样式设计看似简单，实则深不可测...
生命周期钩子：生老病死，Vue 组件的一生
组件的一生万物皆有灵，Vue 组件也不例外。它们从被创建（Creation），到挂载（Mounting），到更新（Updating），最后销毁（Unmounting），走完了一生。而我们开发者，就是那个掌握生杀大权的神。 Vue 3 的变化在 Vue 2 中，我们熟悉的是 created, mounted, destroyed。在 Vue 3 的 Composition API 中，这些变成了 onMounted, onUnmounted 等等。 最让我困惑的是 setup()。它在 beforeCreate 和 created 之前执行。这意味着在 setup 里面，我们不需要写这一类的钩子了，直接写逻辑就行。 实际应用中的坑我曾经遇到过一个 Bug，在 onMounted 里面去获取 DOM 元素的高宽。理论上这时候 DOM 已经渲染好了，对吧？ 错！如果你的组件里面有 v-if 或者异步组件，onMounted 触发的时候，子组件可能还没渲染完！这时候拿到的高度是 0。解决办法是用 nextTick，或者检查你的组件结构。 为什么会这样？回想起刚开始接触 Vue 的时候，那...
路由守卫：你是谁？你去哪？有通行证吗？
前端的保安：Vue Router做单页应用（SPA），路由管理是绕不开的一环。而“路由守卫”（Navigation Guards）则是其中最精彩（也最容易出 Bug）的部分。 全局前置守卫：beforeEach这就好比小区门口的保安大爷，不管你是谁，进门先查证。 1234567router.beforeEach((to, from, next) => { if (to.name !== 'Login' && !isAuthenticated) { next({ name: 'Login' }) } else { next() }}) 看起来逻辑天衣无缝？只要没登录，就踢回登录页。但是！如果你的逻辑写得稍微有一点漏洞，就会陷入无限循环。 比如，你忘记判断 to.name !== 'Login'，那么用户被重定向到 Login 页，再次触发 beforeEach，再次重定向… 浏览器直接卡死，你也懵逼了。 组...
Ref vs Reactive：响应式的哲学思考 (头秃篇)
响应式的哲学在深入学习 Vue 3 的过程中，不管是新手还是老鸟，都会遇到一个经典问题：ref 和 reactive 到底用哪个？ 官方的定义 ref：接受一个内部值并返回一个响应式且可变的 ref 对象。ref 对象仅有一个 .value property，指向该内部值。 reactive：返回对象的响应式副本。 看起来很简单，对吧？ref 处理基本类型，reactive 处理对象。但是在实际开发中，情况远比这复杂。 踩坑实录我曾经试图用 reactive 去定义一个数组，结果发现直接重新赋值会丢失响应性！ 123let list = reactive([])// ... 异步获取数据后list = newData // ❌ 响应性丢失！界面不更新！ 为什么？因为 reactive 返回的是一个 Proxy 对象，直接赋值 list = newData 只是修改了变量 list 的引用，并没有修改原来的 Proxy 对象。 正确做法是用 ref，或者用 list.push(...newData)。但是 ref 每次都要写 .value，真的好烦啊！在模板里倒是会自动解包，但...
Vue 3 启航
梦开始的地方记得刚接触前端的时候，大家还在用 jQuery 一把梭。那时候的代码充满了 $ 符号，回调地狱更是家常便饭，三件套东一块西一块是常态。后来 React 和 Vue 横空出世，带给了我们全新的组件化开发体验。而今天，我正式决定投入 Vue 3 的怀抱。 为什么选择 Vue 3？有人说 React 更灵活，有人说 Angular 更规范。但在我看来，Vue 3 找到了优雅与性能的完美平衡点。 性能的质变：Vue 3 重写了响应式系统，利用 ES6 的 Proxy 取代了 Object.defineProperty。这意味着什么？意味着我们再也不用担心数组下标修改监听不到的问题了！而且，初始化的速度快得惊人。 Composition API：这绝对是 Vue 3 最大的杀手锏。在 Options API 时代，一个功能的逻辑往往分散在 data、methods、computed 里，维护起来像是在玩“找你妹”。而现在，我们可以像这就写原生 JS 一样，把相关逻辑聚合在一起。这简直是代码组织的神器！ TypeScript 支持：Vue 2 对 TS 的支持简直是灾难，而 V...
