Vue

我们每天的开发，可能都是从一个npm run dev开始的。npm scripts对我们来说，天天用它，但很少去思考它。 不信，你看看你项目里的package.json，是不是长这样👇： 这能用吗？当

大家好，我又来了🤣。 打开2025年的招聘软件，十个资深前端岗位，有八个在JD（职位描述）里写着：“有Node.js/Serverless/全栈经验者优先”。 全栈 👉 成了我们前端工程师内卷的一种方

我刚入行那会儿，还是jQuery的时代。当时面试，事件委托（Event Delegation） 几乎是必考题。能用.on()方法，在一个父元素上，优雅地处理动态添加的子元素的事件，是衡量一个前端是否会

作为组长，我在Code Review里，最常跟新人强调的一句话就是：“不要忘了提交lock文件！ ” 为什么？因为lock文件是保证我们团队成员、测试环境、线上服务器，能安装完全一致的依赖版本的“契约

如果你用过Vue，你一定对它那响应式系统印象深刻。你只需要在<script>里修改一个数据，template里对应的视图就会自动更新。 整个过程很丝滑流畅。 但作为工程师，我们都知道，它正是Vue框架

提到现代前端框架，比如React、Vue，你一定听过“虚拟DOM”（Virtual DOM）这个词。它被认为是提升性能的关键所在，是框架设计的核心思想之一。 但是，虚拟DOM到底是什么？它为什么能带来

在写下这个标题的时候，我已经做好了被喷的准备。我知道，在前端这个世界里，聊框架之争，就像在聊哪家烧烤最好吃一样，永远没有标准答案。 在动笔之前，我想先表明立场：我不是要捧一踩一，两个框架都是我吃饭的家

我们有个项目，在几个页面之间频繁同步筛选状态：比如商品分类、价格区间、排序方式、分页……一开始用的是组件通信 + Pinia，全局 store 越写越大，维护起来越来越乱。 直到我们开始把状态写进 U

JavaScript 中的 Proxy 是一把极其强大的API，允许你劫持对象的读取、赋值、删除、函数调用等等。但它并不是“无所不能”。在某些边界场景下，Proxy 是拦截不了的，甚至有些你以为能拦的

Vue 从 Vue 3 开始，进入了“编译期优化”的时代。大量代码在运行前就被静态分析、优化、裁剪了。这对于性能是好事，但对开发者来说也提出了更高要求：你得知道哪些是编译期行为，否则你调试半天的代码，

Vue 响应式系统是 Vue 框架的核心，但大多数开发者只停留在 ref 和 reactive 的表面用法。今天聊聊它背后几个不为人知的实现细节，帮你理解 Vue 响应式系统底层。 1. Proxy

我们的前端系统一度拆成了 7 个子应用：A 是核心系统，B 是订单，C 是库存……最开始大家都觉得：“哎，模块化、多团队并行、还能独立部署，好事啊。” 真做下去，才发现微前端的难度根本不是“怎么加载子

上线前两个月，我们的权限系统崩了三次。 不是接口没权限，而是： 页面展示和真实权限不一致； 权限判断写得四分五裂； 权限数据和按钮逻辑耦合得死死的，测试一改就炸。 于是，我们老老实实把整个权限体系拆了

过去五年，我面试过不下 80 个前端应聘者，代码能力千差万别，但有一件事惊人一致： 不是 Angular、不是 Svelte、不是 Qwik、不是 Web Components，甚至连 WebGL、T

这半年用组合式 API 用得比较深，项目里遇到不少 edge case，文档没有明确提，踩坑只能自己总结。下面这几种 setup() 写法，我们项目里是常规写法，调试方便，协作时出问题也好排查。 1.

💥先说结论：除非你团队真的“特别大”，否则别再迷信 Pinia 用完 Pinia，最后我自己掏出一套组合式 API 封装后，项目变清爽了、调试变简单了、开发变自由了。 Pinia 确实“像 Vuex

起因：一句话的“需求” 一天，产品在设计稿下方评论说： 我本来以为就是加个 transition，小事一桩。 上线后产品说：“嗯，这个感觉不错耶，那我们把所有按钮 hover 都做成统一的吧。” 我知

说实话，Vue3 出来这么久，光 Composition API 和响应式就够大家研究半天了。但性能优化这块，很多人还停留在“用 v-if 替代 v-show”“不要重复渲染”这种 level。 今天

1. 抽组件 ≠ 拆文件夹 很多初学 Vue 的人对“组件化”的理解就是：“页面上出现重复的 UI？好，抽个组件。” 于是你会看到这样的组件： 接着你又遇到需要加图标的输入框，于是复制一份： 再后来你

很多 Vue 3 用户都知道有 watchEffect()，也偶尔用用，但真正理解它运行机制和使用场景的开发者，其实并不多。 它被认为是“比 watch 更方便的响应式侦听”，但用不好，它也能成为项目