观点评论：如“现代前端开发是否过度依赖框架？

前端开发者的一天，往往是从一条 `npm create vite@latest` 开始的。脚手架帮我们搭好项目，路由、状态管理、UI 组件库层层嵌套，我们熟练地安装依赖、配置插件、编写业务组件——却很少停下来问一句：这个页面真的需要 React 吗？这个按钮真的需要引入整个 Element Plus 吗？当“框架先行”成为行业惯性，我们或许该认真审视：现代前端开发，是否已经过度依赖框架了？

框架解决过真问题，但也制造了新惯性

二十年前，前端工程师还在用原生 JavaScript 操作 DOM，`getElementById` 和 `appendChild` 写到手软。跨浏览器兼容性更是噩梦，同一个页面在 IE6 和 Firefox 里表现迥异。正是这些问题促生了 jQuery，再到后来 Angular、React、Vue 相继登场，组件化、响应式数据流、虚拟 DOM 等理念极大提升了开发效率和用户体验。没有框架，单页应用的复杂状态管理几乎是不可想象的。

可当框架成为唯一思考方式，问题也随之而来。很多团队在技术选型时根本没有“是否需要框架”这个选项，只有“用 Vue 还是 React”。为了一个静态展示页，有人硬生生引入一个完整的前端工程化体系：Webpack 打包、ESLint 配置、Redux 或 Pinia 全局状态仓库、几十个 npm 依赖……最终产出的只是一个几乎没有交互的落地页，首屏却要加载上百 KB 的 JavaScript。

框架的隐性成本：性能、复杂度与心智负担

依赖框架最直接的代价是性能。JavaScript 解析和执行本身就是成本，框架的抽象层越多，浏览器需要做的额外工作就越多。一个简单的列表排序，如果用原生 JavaScript 或轻量工具库，可能只需要几毫秒；但跑在 React 的虚拟 DOM diff 上，还要经过组件渲染管线，开销就上去了。对复杂应用来说，框架的性能优化能力足以弥补这些消耗，但对大部分轻量页面而言，纯属杀鸡用牛刀。

更隐蔽的成本是“认知复杂度”本身。React 开发者不得不理解闭包陷阱、Hooks 依赖数组、并发特性；Vue 开发者需要厘清响应式代理和编译时优化。框架带来的抽象，本是为了降低复杂度，可当版本迭代、生态转向时，开发者花在“跟上框架变化”上的精力，往往超过了解决业务问题本身。不少面试题已经变成了“React 18 的 useTransition 怎么用”这类框架考古题，而非“如何设计一个高性能组件”这样的基本功考察。

没有框架的时代，我们反而活得更明白？

这并非鼓吹回归 jQuery 或原生 DOM 时代——那是矫枉过正。真正值得追问的是：我们是否已经丧失了“不用框架”的思考能力？每当遇到一个需求，我们第一反应是到 npm 上搜现成库，而不是分析需求本质。很多前端工程师甚至不会写原生的事件委托，不知道该怎样用 `IntersectionObserver` 实现懒加载，不清楚 CSS Grid 已经能完成过去需要 JS 插件才能做到的复杂布局。

我们需要警惕的是“锤子定律”：手里拿着锤子，看什么都是钉子。当框架成为那位锤子，前端的一切问题都被强制解释为“组件化问题”“状态问题”“工程化问题”。而事实上，很多页面只需要静态 HTML 加少量脚本，很多交互动效用 CSS 就能完成，很多数据请求用原生 fetch 就够了。框架应该是解决方案之一，而非唯一的思维模板。

回归业务，让工具自己证明价值

说到底，前端开发的终极目标不是写出漂亮的组件树，而是高效、可靠地交付用户价值。一个医疗预约页面，一张产品宣传页，一个数据可视化图表——它们的技术需求天差地别，凭什么都要套上同一套 SPA 框架？优秀的团队会做技术选型评估：项目规模、团队维护能力、长期迭代节奏、性能预算，综合考量后才能决定框架是否值得引入——包括是否使用像 Astro、Svelte 这类更轻量的选择，或者干脆采用传统的服务端渲染加渐进增强。

这不是反框架，而是去魅框架。当我见到有人为了做一个官网，用 Next.js 启动开发服务器，只为了给页面加几行动画时，我会提醒他：浏览器原生 API 加上一个 CSS transition 就能做到的东西，不必让整个 Node 生态陪你加班。工具为人服务，人不该成为工具的祭司。

结语

现代前端开发并没有“过度依赖框架”——更准确地说，是过度依赖“用框架解决问题的习惯”。框架解决了复杂应用的组织问题，却也让简单任务变得臃肿。下一次新建项目时，不妨先问自己：我真的需要那三行依赖吗？还是说，一个 HTML 文件就足够了？保持对底层技术的理解和敬畏，才能在工具与本质之间找到那条轻盈的路径。