根据个人习惯，在入门一门新技术前喜欢提三个问题，它是什么？它能干什么？为什么需要它？
对于一般React开发时，我们常常需要进行三步配置：
- 安装node.js
- 配置包管理工具并安装对应脚手架工具包
- 使用脚手架创建项目
倘若直接从html过度到前端框架开发，肯定直接被上面三个步骤弄懵了，只知道要这么做，不知道为什么这么做。接下来分步介绍下这些操作的含义和内容。
1、关于node.js
许多前端开发者都直接将其视为后端语言，认为自己作为前端开发无需理解它。实际上前端人员在使用现代框架时常常需要与它打交道。所以对于它在我们开发中是扮演何种角色是需要了解的。
node.js是什么？
Node.js官方定义为：是一个免费、开源、跨平台的 JavaScript 运行时环境, 它让开发人员能够创建服务器 Web 应用、命令行工具和脚本。其实若我们将能够实现http接口的语言当作后端语言的话，将node.js视作后端语言也是符合定义的。
node.js能干什么？
严格来说，它就是一个专门用于脱离浏览器的js运行工具。一般而言我们会将它当作一种后端接口的实现工具，即：可以使用Node.js编写网络接口。
为什么需要它？
传统html想要部署至服务器，需要一个能够将它代理起来的应用程序（如前后端不分离时的后端程序，可以用java、python等代理起来，或现在常用的nginx、tomcat等反向代理服务代理这些静态资源）。
但是作为前后端分离架构流行的现在，我们期望的是前端代码和后端代码完全分开。此时普通html就需要一个能够单独代理它的程序。在服务器部署时，我们可以用反向代理服务器部署，但是我们本地开发时，单独安装一个就有些不方便了。
于是，我们可以在本地运行调试时，直接使用node.js临时把我们的静态网页代理起来（编写一个http监听程序，收到请求后将静态资源返回）。这就是我们在学习使用原生html时，可以直接打开，但是我们在使用React相关脚手架时，需要访问http://localhost的原因所在了。
这也是我们在使用类似相关脚手架时，需要提前安装node.js的原因，也是为什么我们调试时无需配置nginx等代理，但是将项目打包后想部署时，却需要nginx代理的原因了。
2、关于npm或yarn等包管理工具
对于包管理工具，在正式代码开发中是经常遇到了。基本上市面上的大多数语言都会有成熟的包管理工具，如python的pip、java的Maven等等。
包管理工具是什么？
包管理工具提供了命令行工具，可以方便地下载、安装、升级、删除包，也可以让你作为开发者发布并维护包。
包管理工具能干什么？
对于此类工具，在我的理解中就是帮助我们引入别人代码的工具。即：为项目引入第三方包的工具。
为什么需要它？
因为在我们的项目开发中，我们不可能所有的功能都是自己实现。重复造轮子是低效的（学习目的除外），所以我们常常需要引入别人的工具包来加速我们的开发。当你想复用别人代码时，没有什么比直接npm install xxx后就直接使用更方便的事情了。
而我们常常见到的package.json则属于它在项目中的配置描述文件。而node_modules则是它存放三方代码的地方。
3、 关于脚手架
我们会常常用到vite、vue-cli等脚手架工具。
它是什么？
在我看来它就是一段别人写好的脚本。
它能干什么？
上面在介绍Node.js的时候说过，我们前后端分离项目中前端开发的时候需要借助node来临时代理起我们的静态网页，但是人人都能手写这段代码么？不尽然吧。所以有人这些node的操作封装成了脚手架，使用者仅需执行固定的命令即可完成对应的操作。
为什么需要它？
很显然，它可以让前端开发者只专注代码开发。
4、以上理解在实际使用中的用处。
如果对以上概念有了相应的理解，则我们在前端开发中遇到的一些问题和现象我们就可以简单的理解了。如：
1、跨域问题在脚手架中的配置解决方案
我们前端常常会遇到跨域问题，关于跨域其本质为浏览器的同源策略（即浏览器获得的js仅能够向与它同源的网站发送请求，同源即为ip或域名和端口相同）。我们在开发时，若想在前端解决跨域问题，则需要在配置文件中写入一个proxy的描述来解决同源。
细心的小伙伴会发现，配置了proxy后，我们启动web后，f12时，所有的http都指向了localhost，但是实际的服务器却收到了请求。这里的本质就是我们的脚手架通过node.js在本地开启了一个转发，将所有本地固定url的请求转发向服务器端。
由于同源策略来自浏览器，而node不会有这种限制。所以可以成功解决跨域。
这里也就解释了为什么在脚手架中此类配置叫proxy（代理），为什么我们配置代理后http请求应该指向本地而非远端。也解释了为什么此类配置在打包后就会失效（因为开发时脚手架帮你代理了，但是打包后，你的dist文件里就只剩下静态资源了，部署时需要重新使用ngxin等进行配置跨域问题）
2、部署前端时的部署方案
随着node的发展，我们发现在部署前端项目时我们有了更多的选择：利用nginx部署、利用PM2部署等等。实际本质上都是需要一段能够实现监听http请求并响应静态资源的程序而已。所以我们时长会看到使用node的包如pm2、server等部署前端，其实本质上和你本地脚手架开发时开启的临时资源代理是一样的。只要了解了这一原理，不论是何种部署方案都可以轻松理解。
3、js不是解释型语言么，为脚手架部署时为什么要单独build？
这里的build不在和静态语言将代码编译成可执行文件一样。这里的build一般时指的脚手架将你的代码翻译成node可以读取并代理的前端静态资源。由于你部署时肯定不会在服务器单独安装脚手架，所以需要用build命令转成node.js的原生可识别的方式拉。所以脚手架这个名字就很形象，当你盖房子时需要脚手架来方便你快速搭建，但是最后交付时就需要拆除了（这个角度同样能够解释为什么build后，你脚手架配置的proxy就会失效）。
补充——关于React等框架做了什么
在我看来，其核心功能就是帮助我们自动刷新dom元素，提高开发效率。