工程化 on Last Stand

前端模块化

Sat, 05 Oct 2024 00:00:00 +0800

一、模块化的理解

1.什么是模块?

将一个复杂的程序依据一定的规则(规范)封装成几个块(文件), 并进行组合在一起
块的内部数据与实现是私有的, 只是向外部暴露一些接口(方法)与外部其它模块通信

2.模块化的进化过程

全局function模式 : 将不同的功能封装成不同的全局函数
- 编码: 将不同的功能封装成不同的全局函数
- 问题: 污染全局命名空间, 容易引起命名冲突或数据不安全，而且模块成员之间看不出直接关系

function m1(){
 //...
}
function m2(){
 //...
}

namespace模式 : 简单对象封装
- 作用: 减少了全局变量，解决命名冲突
- 问题: 数据不安全(外部可以直接修改模块内部的数据)

let myModule = {
 data: 'www.baidu.com',
 foo() {
 console.log(`foo() ${this.data}`)
 },
 bar() {
 console.log(`bar() ${this.data}`)
 }
}
myModule.data = 'other data' //能直接修改模块内部的数据
myModule.foo() // foo() other data

这样的写法会暴露所有模块成员，内部状态可以被外部改写。

IIFE模式：匿名函数自调用(闭包)
- 作用: 数据是私有的, 外部只能通过暴露的方法操作
- 编码: 将数据和行为封装到一个函数内部, 通过给window添加属性来向外暴露接口
- 问题: 如果当前这个模块依赖另一个模块怎么办?

// index.html文件
<script type="text/javascript" src="module.js"></script>
<script type="text/javascript">
 myModule.foo()
 myModule.bar()
 console.log(myModule.data) //undefined 不能访问模块内部数据
 myModule.data = 'xxxx' //不是修改的模块内部的data
 myModule.foo() //没有改变
</script>

// module.js文件
(function(window) {
 let data = 'www.baidu.com'
 //操作数据的函数
 function foo() {
 //用于暴露有函数
 console.log(`foo() ${data}`)
 }
 function bar() {
 //用于暴露有函数
 console.log(`bar() ${data}`)
 otherFun() //内部调用
 }
 function otherFun() {
 //内部私有的函数
 console.log('otherFun()')
 }
 //暴露行为
 window.myModule = { foo, bar } //ES6写法
})(window)

最后得到的结果：

Webpack与Vite

Sat, 05 Oct 2024 00:00:00 +0800

前言

vite比webpack快？

vite比webpack简单？

今天我们就来分析一下，到底有什么不一样的地方！

定位

对比之前，我们先要搞懂，vite与webpack的定位以及关系才可以。

那前端社区中常谈到的这些工具webpack、rollup、parcel、esbuild、vite、vue-cli、create-react-app、umi他们之间的关系是怎样的。

webpack、rollup、parcel、esbuild都是打包工具，代码写好之后，我们需要对代码进行压缩、合并、转换、分割、打包等操作，这些工作需要打包工具去完成。
vue-cli、create-react-app、umi 是基于webpack的上层封装，通过简单的配置就可以快速创建出一个项目，把更多的时间放在业务开发上。
vite开发环境依赖esbuild进行预构建，生产环境则依赖rollup进行打包，并且充分利用了现代浏览器的特性，比如http2、ES module，vite是站在众多巨人肩膀上的一个产物，类似webpack + webpack-dev-server的结合体，是一个非常棒的前端项目的构建工具。

运行原理

首先，我们从运行原理上分析一下，vite为什么比webpack快。

webpack运行原理

当我们使用webpack启动项目时，webpack会根据我们配置文件（webpack.config.js）中的入口文件（entry），分析出项目项目所有依赖关系，然后打包成一个文件（bundle.js），交给浏览器去加载渲染。

这样就会带来一个问题，项目越大，需要打包的东西越多，启动时间越长。

关于ES module

在讲vite运行原理之前，我们先说一下ES module

目前，绝大多数现代浏览器都已经支持ES module了，我们只需要在<script>标签中添加type="module"，就可以使用ES module了。

下面这段代码是可以直接在浏览器中运行的。

// test.js
export default function hello() {
  console.log('hello world');
}

// index.html
<script type="module">
  import hello from './test.js';

  hello(); // hello world
</scirpt>

vite运行原理

在<script type="module">中，浏览器遇到内部的import引用时，会自动发起http请求，去加载对应的模块。

vite也正是利用了ES module这个特性，使用vite运行项目时，首先会用esbuild进行预构建，将所有模块转换为es module，不需要对我们整个项目进行编译打包，而是在浏览器需要加载某个模块时，拦截浏览器发出的请求，根据请求进行按需编译，然后返回给浏览器。

这样一来，首次启动项目（冷启动）时，自然也就比webpack快很多了，并且项目大小对vite启动速度的影响也很小。

构建方式

我们再来看一下，vite与webpack在项目构建上有哪些区别。

webpack

webpack是基于nodejs运行的，但js只能单线程运行，无法利用多核CPU的优势，当项目越来越大时，构建速度也就越来越慢了。

vite

vite预构建与按需编译的过程，都是使用esbuild完成的。

esbuild是用go语言编写的，可以充分利用多核CPU的优势，所以vite开发环境下的预构建与按需编译速度，都是非常快的。

http2

vite充分利用了http2可以并发请求的优势，这也是速度快的一个主要原因。接下来，我们了解一下http2的来龙去脉。

在之前http1的时候，浏览器对同一个域名的请求，是有并发限制的，一般为6个，如果并发请求6个以上，就会造成阻塞问题，所以在http1的时代，我们要减少打包产物的文件数量，减少并发请求，来提高项目的加载速度。

2015年以后，http2出现了，他可以并发发送多个请求，不会出现http1的并发限制。这时候，将打包产物分成多个小模块，并行去加载，反而会更快。

vite也充分利用了这一优势，对项目资源进行了合理的拆分，访问项目时，同时加载多个模块，来提升项目访问速度。

热更新

vite速度快的另一个原因是与webpack不同的热更新机制。

任务自动化

Sat, 05 Oct 2024 00:00:00 +0800

在前端开发中，我们经常需要执行各种重复性任务，比如编译代码、启动本地服务器、监听文件变化、运行测试、部署代码等。虽然可以使用不同的工具来完成这些任务，但npm本身提供了一个强大的功能：npm scripts。通过npm scripts，我们可以将这些任务脚本化并集中管理，从而提高开发效率。本文将专注于如何使用npm scripts自动化前端开发任务，以及它在项目管理中的作用。

什么是`npm scripts`？

npm scripts是npm提供的一种机制，允许我们在项目的package.json文件中定义一组命令，方便执行各种任务。在package.json文件中，scripts字段可以包含多个脚本，每个脚本都是一个键值对，其中键是脚本的名称，值是实际要执行的命令。例如：

{
 "scripts": {
 "build": "webpack --config webpack.config.js",
 "test": "jest"
 }
}

在上面的示例中，定义了两个脚本：build 和 test。可以通过以下方式在命令行中运行这些脚本：

npm run build
npm run test

npm会执行对应的命令，自动帮我们完成编译和测试任务。

为什么使用`npm scripts`？

在现代前端开发流程中，自动化任务是不可或缺的，而npm scripts的使用有以下几大优势：

减少对全局依赖的需求：在传统项目中，开发者通常需要全局安装各种命令行工具，如webpack、eslint、babel等。而npm scripts可以直接调用项目的本地依赖，无需全局安装。这确保了不同开发环境中的工具版本一致，减少了版本冲突和兼容性问题。
集中管理任务：npm scripts将所有任务定义集中在package.json文件中，项目中的所有开发人员都可以直观地看到可用的任务列表，无需了解每个工具的详细使用方法。只需运行npm run <task>，便可一键完成常见任务。
支持跨平台执行：npm scripts中的命令可以跨平台使用，在Windows、macOS和Linux系统上表现一致，尤其适合团队协作。
便于组合和链式执行：npm允许通过逻辑操作符来组合脚本，实现复杂任务的自动化执行。例如可以通过&&和||来串联多个任务，使得多个步骤一次完成。

如何定义和使用`npm scripts`？

让我们通过具体的示例来看看npm scripts如何自动化前端开发任务。

1. 设置基本的开发任务

假设我们正在开发一个React项目，我们可以在package.json中定义以下基本任务：

{
 "scripts": {
 "start": "webpack serve --mode development",
 "build": "webpack --mode production",
 "test": "jest",
 "lint": "eslint src/**/*.js"
 }
}

这里的脚本分别执行以下任务：

前端构建工具详解

Thu, 07 Aug 2025 00:00:00 +0800

谈到构建工具，大家首先想到的肯定就是 Webpack 以及现在最🔥的 Vite。 Webpack，功能强大，生态丰富，从面世到今天，一直是很受大家欢迎；Vite 采用 unbundle 构建模式，带来了极致的开发体验，给开发人员以新的选择。

在这两个构建工具之外，还有其他的构建工具，如和 Webpack、Vite 类似的 Rollup、Parcel、Esbuild，自动化构建工具 grunt、gulp，以及更加久远的 YUI Tool。

这些工具的存在，构成了前端构建工具的发展史。

YUI Tool + Ant

YUI tool 是 07 年左右出现的一个构建工具，功能比较简单，用于压缩混淆 css 和 js 代码，需要配合 java 的 Ant 使用。

当时 web 应用开发主要采用 JSP，还不像现在这样前后端分离，通常是由 java 开发人员来编写 js、css 代码，前端代码都是和后端 java 代码放在一起的。因此前端代码的压缩混淆也就基于 java 实现了。

Grunt / Gulp

Grunt / Gulp 都是运行在 node 环境上的自动化工具。

在开发过程中，我们可以将一些常见操作如解析 html、es6 代码转换为 es5、less / sass 代码转换为 css 代码、代码检查、代码压缩、代码混淆配置成一系列任务，然后通过 Grunt / Gulp 自动执行这些任务。

Grunt 和 Gulp 的不同点：

前端任务自动化（npm scripts实现）

Thu, 07 Aug 2025 00:00:00 +0800

在前端开发中，我们经常需要执行各种重复性任务，比如编译代码、启动本地服务器、监听文件变化、运行测试、部署代码等。虽然可以使用不同的工具来完成这些任务，但npm本身提供了一个强大的功能：npm scripts。通过npm scripts，我们可以将这些任务脚本化并集中管理，从而提高开发效率。

本文将专注于如何使用npm scripts自动化前端开发任务，以及它在项目管理中的作用。

什么是`npm scripts`？

{
 "scripts": {
 "build": "webpack --config webpack.config.js",
 "test": "jest"
 }
}

在上面的示例中，定义了两个脚本：build 和 test。可以通过以下方式在命令行中运行这些脚本：

npm run build
npm run test

npm会执行对应的命令，自动帮我们完成编译和测试任务。

为什么使用`npm scripts`？

在现代前端开发流程中，自动化任务是不可或缺的，而npm scripts的使用有以下几大优势：

减少对全局依赖的需求：在传统项目中，开发者通常需要全局安装各种命令行工具，如webpack、eslint、babel等。而npm scripts可以直接调用项目的本地依赖，无需全局安装。这确保了不同开发环境中的工具版本一致，减少了版本冲突和兼容性问题。
集中管理任务：npm scripts将所有任务定义集中在package.json文件中，项目中的所有开发人员都可以直观地看到可用的任务列表，无需了解每个工具的详细使用方法。只需运行npm run <task>，便可一键完成常见任务。
支持跨平台执行：npm scripts中的命令可以跨平台使用，在Windows、macOS和Linux系统上表现一致，尤其适合团队协作。
便于组合和链式执行：npm允许通过逻辑操作符来组合脚本，实现复杂任务的自动化执行。例如可以通过&&和||来串联多个任务，使得多个步骤一次完成。

如何定义和使用`npm scripts`？

让我们通过具体的示例来看看npm scripts如何自动化前端开发任务。

1. 设置基本的开发任务

假设我们正在开发一个React项目，我们可以在package.json中定义以下基本任务：

{
 "scripts": {
 "start": "webpack serve --mode development",
 "build": "webpack --mode production",
 "test": "jest",
 "lint": "eslint src/**/*.js"
 }
}

这里的脚本分别执行以下任务：

代码规范工程化

Thu, 07 Aug 2025 00:00:00 +0800

规范化是前端工程化的一个重要部分。现在，有许多工具能够辅助我们实行代码的规范化,比如你一定知道的 ESLint 和 Prettier。

今天，来聊聊这些工具的工作原理和基本使用，了解它们是如何发挥作用的，以及如何更好地利用这些工具去规范项目的代码。

1. ESlint - 检查你的 JavaScript 代码

让我们先从知名度最高的 ESLint 开始。

1.1. ESLint 及其作用

Lint 是一类专门用于检查代码的工具软件，也称 linter。ESLint ，即 JavaScript （ECMAScript）代码的检查工具。

正如官网的介绍 —— “Find and fix problems in your JavaScript code”，ESLint 能够辅助查找出你的 JavaScript 代码中的问题，包括：

代码风格问题（styles）。比如，运算符两边的空格、语句末尾的分号。
不好的写法。比如，使用 == 进行比较而不是 ===。
可能存在逻辑问题的代码模式。比如，定义了一个变量，但没有使用到它。

此外，ESLint 还能够帮你自动修复一些简单的问题。

我们将在下一小结学习如何使用 ESLint 检查我们的 JavaScript 代码，并修复其中的一些问题。

1.2. ESLint 快速上手

为了在项目中使用 ESLint，需要先安装它。

# 初始化一个 npm 项目
mkdir eslint-test
cd eslint-test
npm init -y
# 安装 eslint
npm init @eslint/config

回答一系列问题后，你可以看目录中的配置文件 .eslintrc.js，这个配置文件告诉 ESLint 如何去解析项目，这个项目采用了哪些规范和规则。

版本控制

Thu, 07 Aug 2025 00:00:00 +0800

什么是版本控制

版本控制是一种系统性的方法，用于管理和跟踪软件开发项目中的代码、文件和资源。它的核心目标是在不同时间点的开发中保持代码的一致性、可追溯性和可维护性。

为什么要做版本控制

这个问题可以从定义中的关键词可以看出端倪：不同时间点下的代码一致性、可追溯性、可维护性。这里额外补充一点：当今的互联网开发早已步入敏捷迭代，各种动态化方案层出不穷都有着顺应时代潮流的意思，因此软件开发一定会越来越多地涉及到团队开发，团队之间的协作也一定需要这样一个机制去保障稳定性。

代码一致性

版本控制系统允许开发人员有效地管理和组织项目中的代码。它跟踪每个文件的历史记录，记录了每个版本的变更，包括谁做了什么修改、何时以及为什么。

可追溯性

版本控制系统允许为重要的里程碑或发布创建标签（tag），以便轻松识别和回滚到特定版本。

并且当某个版本的代码出现问题，版本控制系统允许开发人员轻松地回滚到之前的稳定版本，并在不破坏其余代码的情况下进行修复。

可维护性

开发人员可以创建分支（branch），这是一个独立的代码副本，用于开发新功能、修复错误或进行实验性工作。然后，这些分支可以与主代码库合并，以实现功能集成。

团队协作

在多人协作的环境中，不同开发者可能同时修改代码。版本控制系统确保不同的修改不会互相冲突，以及如何解决冲突。

版本控制系统促进了团队之间的协作，可以通过代码审查工具进行代码审查，以确保代码质量和一致性。

版本控制工具`Git`

`Git`的安装

`WIndows`

访问 Git官网，选择对应的操作系统下载即可。

这里下载独立安装包即可

点install就行，会自动安装一个git GUI工具，但通常不会直接用它

下载完成安装即可，输入以下命令验证安装是否成功

git version

图形化工具

安装

这里推荐TortoiseGit这个工具，非常方便。但我觉得Git本身学习成本并不高，GUI工具更多是为了提升效率，基本的Git知识点还是需要掌握的。

下载本体

然后是语言包

安装时一路next即可，安装完本体后再安装语言包。

配置好Github的账户、邮箱、秘钥等，注意配置好了密钥也不会在下述部分显示，可以打开编辑全局进行查看

使用

在使用之前先提前补充一个点（后续会详细介绍），Git有本地仓库和远端仓库的概念，通常支持HTTPS和SSH两种协议进行关联，两种方式优缺点也十分明显：

HTTPS：无需额外配置，但是在每次连接远端仓库时需要输入账号密码进行校验。
SSH：生成一组密钥对，需要本地进行配置，好处是配置好后每次连接远端仓库时会自动比较密钥对，无需额外校验。关于SSH详细可以参考这篇文章ssh-远程登录协议

为了一劳永逸，我们这里配置下SSH，首先打开Git bash

# 输入下列命令，最后一个参数是您的邮箱
$ ssh-keygen -t rsa -C yourEmail.com

可以看到密钥对已经生成了

进入上述目录，注意.ssh文件夹默认是隐藏的，直接访问路径就行

以Github为例，配置公钥

创建一个Demo项目，平时学习的话就创建公有项目就行

复制一下我们的项目链接

选取一个你喜欢的目录作为本地工作区，然后按鼠标右键

包管理

Thu, 07 Aug 2025 00:00:00 +0800

现如今，前端开发的同学已经离不开 npm 这个包管理工具，其优秀的包版本管理机制承载了整个繁荣发展的NodeJS社区，理解其内部机制非常有利于加深我们对模块开发的理解、各项前端工程化的配置以加快我们排查问题（相信不少同学收到过各种依赖问题的困扰）的速度。

本文从三个角度：package.json、版本管理、依赖安装结合具体实例对 npm 的包管理机制进行了详细分析。

一、剖析 package.json

在 Node.js 中，模块是一个库或框架，也是一个 Node.js 项目。Node.js 项目遵循模块化的架构，当我们创建了一个 Node.js 项目，意味着创建了一个模块，这个模块必须有一个描述文件，即 package.json。它是我们最常见的配置文件，但是它里面的配置你真的有详细了解过吗？配置一个合理的 package.json 文件直接决定着我们项目的质量，所以首先带大家分析下 package.json 的各项详细配置。

1.1 必备属性

package.json 中有非常多的属性，其中必须填写的只有两个：name 和 version ，这两个属性组成一个 npm 模块的唯一标识。

npm包命名规则

name 即模块名称，其命名时需要遵循官方的一些规范和建议：

包名会成为模块url、命令行中的一个参数或者一个文件夹名称，任何非url安全的字符在包名中都不能使用，可以使用 validate-npm-package-name 包来检测包名是否合法。
语义化包名，可以帮助开发者更快的找到需要的包，并且避免意外获取错误的包。
若包名称中存在一些符号，将符号去除后不得与现有包名重复

例如：由于react-native已经存在，react.native、reactnative都不可以再创建。

如果你的包名与现有的包名太相近导致你不能发布这个包，那么推荐将这个包发布到你的作用域下。

例如：用户名 conard，那么作用域为 @conard，发布的包可以是@conard/react。

查看包是否被占用

name 是一个包的唯一标识，不得和其他包名重复，我们可以执行 npm view packageName 查看包是否被占用，并可以查看它的一些基本信息：

若包名称从未被使用过，则会抛出 404 错误：

另外，你还可以去 https://www.npmjs.com/ 查询更多更详细的包信息。

1.2描述信息

基本描述

{
 "description": "An enterprise-class UI design language and React components implementation",
 "keywords": [
 "ant",
 "component",
 "components",
 "design",
 "framework",
 "frontend",
 "react",
 "react-component",
 "ui"
 ]
}

description用于添加模块的的描述信息，方便别人了解你的模块。

持续集成/持续部署（CI/CD）

Thu, 07 Aug 2025 00:00:00 +0800

传统应用发布模式

开发人员：在开发环境完成代码编写，单元测试，测试通过后提交到代码仓库

运维人员：把项目部署到测试环境，供QA团队测试，测试通过后，部署生成环境

测试人员：进行测试，测试完成后通知运维部署生产环境

缺点

项目在早期就存在错误，但到最后集成的时候才发现
需要手动操作，易错率高
开发与运维需要及时沟通有了以上缺点，那么就有了CI/CD

CI/CD

持续集成(CI):

合并开发人员正在编写的所有代码
一天内进行多次合并和提交代码
从存储库或生产环境中进行构建和自动化测试，确保没有集成问题并及早发现任何问题

持续交付(CD):

可以通过将更改自动推送到发布系统来随时将软件发布到生产环境中
持续部署，并自动将更改推送到生产中

GitLab内置CI/CD

运行流水线任务

Job

在文件中可以定义一个或多个作业，每个作业具有唯一的名称，每个作业是独立执行的，每个作业至少包含一个script

stages：

用于定义作业可以使用的阶段，并且是全局定义，同一个阶段的作业并行运行，不同阶段按顺序运行

only：

用分支策略来限制jobs构建

script:

项目中package中的脚本

environment：

定义此作业完成部署的环境名称

下面是每个jobs的详细变量名

Keyword	Required	Description
script	yes	Runner执行的命令或脚本
image	no	所使用的docker镜像，查阅使用docker镜像
services	no	所使用的docker服务，查阅使用docker镜像
stage	no	定义job stage（默认：`test`）
type	no	`stage`的别名（已弃用）
variables	no	定义job级别的变量
only	no	定义一列git分支，并为其创建job
except	no	定义一列git分支，不创建job
tags	no	定义一列tags，用来指定选择哪个Runner（同时Runner也要设置tags）
allow_failure	no	允许job失败。失败的job不影响commit状态
when	no	定义何时开始job。可以是`on_success`，`on_failure`，`always`或者`manual`
dependencies	no	定义job依赖关系，这样他们就可以互相传递artifacts
cache	no	定义应在后续运行之间缓存的文件列表
before_script	no	重写一组在作业前执行的命令
after_script	no	重写一组在作业后执行的命令
environment	no	定义此作业完成部署的环境名称
coverage	no	定义给定作业的代码覆盖率设置

配置.gitlab-ci.yml

stages:
 - deploy_dev
 - deploy_test
 - deploy_production

deploy_dev:
 stage: deploy_dev
 environment:
 name: dev
 only:
 - dev
 script:
 - rsync -av . ${WORKSPACE_PATH} && cd ${WORKSPACE_PATH}
 - npm run build:dev
 - ansible-playbook ansible-deploy.yml --extra-vars "hosts=cloud_ui_test projectDir=${WORKSPACE_DIST_PATH} projectName=${PROJECT_NAME} webRootPath=/opt/devroot/"

deploy_test:
 stage: deploy_test
 environment:
 name: test
 only:
 - master
 script:
 - rsync -av . ${WORKSPACE_PATH} && cd ${WORKSPACE_PATH}
 - npm run build:stage
 - ansible-playbook ansible-deploy.yml --extra-vars "hosts=cloud_ui_test projectDir=${WORKSPACE_DIST_PATH} projectName=${PROJECT_NAME} webRootPath=${WEB_ROOT_PATH}"

deploy_production:
 stage: deploy_production
 only:
 - production
 when: manual
 script:
 - npm install
 - npm run build:prod
 - ansible-playbook ansible-deploy.yml --extra-vars "hosts=dvs-front-prod projectDir=${PROJECT_PATH} projectName=xianglin-cloud-ui/${PROJECT_NAME} webRootPath=/opt/"

上面这个.yml文件,我们首先定义了三个阶段，deploy_dev部署到dev环境，并且拉去的是dev分支代码; deploy_test部署到test环境，拉去的是master分支代码，deploy_production拉取production分支代码，执行完后需要手动操作

代码分割工程化

Thu, 07 Aug 2025 00:00:00 +0800

什么是 Bundle Splitting？

Bundle Splitting（代码分割）是一种将前端资源拆分成更小、独立的模块的技术。传统上，前端资源（如 JavaScript、CSS 和图片等）被打包成单个文件，通常称为“bundle”。这种方式存在一个问题，即无论用户需要哪些功能，都必须下载整个 bundle。而 Bundle Splitting 技术通过将代码拆分为更小的模块，按需加载，可以有效解决这个问题。

Bundle Splitting 的优点

减少初始加载时间通过将代码拆分为多个小块，可以减少初始加载时间。当用户首次访问网页时，只需下载当前页面所需的资源，而无需等待整个应用程序的加载完成。这可以极大地提高页面的响应速度，并减少用户的等待时间。
提升用户体验通过将代码分割成模块，可以使应用程序更具响应性。当用户与应用进行交互时，只需加载所需的代码块，而不是整个应用。这将减少不必要的资源消耗，并使用户感觉应用更加流畅和快速。
优化缓存策略拆分代码还能优化缓存策略。当应用程序发生更改时，只需重新加载发生变化的模块，而不必重新下载整个应用。这减少了不必要的网络请求，提高了应用的更新效率，并减轻了服务器的负载。
并行加载资源通过将代码拆分为多个模块，可以实现并行加载资源。浏览器能够同时下载多个文件，从而减少整体加载时间。这对于大型应用程序和复杂的前端框架特别有益，能够更好地利用浏览器的并行下载能力，提高资源的加载效率。
代码复用和维护通过将代码分割成模块，可以更好地实现代码的复用和维护。不同的模块可以根据需求进行加载和升级，使得代码结构更加清晰、模块化。这也有助于团队合作，不同开发者可以并行工作在不同的模块上，提高开发效率和代码质量。

Bundle Splitting 的缺点

增加了网络请求拆分代码会增加应用程序的网络请求次数。每个模块都需要进行一次独立的网络请求，这可能会导致一些额外的延迟和性能损失。在网络条件较差的情况下，这可能会对用户体验产生一定影响。
增加了开发复杂性使用 Bundle Splitting 技术需要对应用程序的依赖关系进行深入分析和管理。开发人员需要仔细考虑代码的拆分点，以及如何在运行时动态加载模块。这增加了开发复杂性，并要求开发人员具备较高的技术水平和经验。
潜在的代码冗余当模块之间存在共享的代码片段时，可能会出现潜在的代码冗余问题。如果不合理地进行代码拆分，可能会导致多个模块中存在相同的代码，增加了资源的下载和维护成本。因此，在进行代码拆分时，需要仔细考虑代码复用和代码冗余的问题。
需要额外的工具和配置 Bundle Splitting 需要使用额外的工具和配置来实现代码的拆分和动态加载。这可能需要对构建工具进行配置，如 Webpack、Rollup 等，以及对模块加载器进行调整。这增加了一些学习成本和开发成本，尤其是对于新手来说。

Bundle Splitting 的适用场景

Bundle Splitting 技术适用于大型的 Web 应用程序，特别是那些具有复杂功能和大量依赖的应用。以下是一些适合使用 Bundle Splitting 的场景：

大型单页应用：对于由多个模块组成的单页应用，使用 Bundle Splitting 可以提高初始加载速度，提升用户体验。
按需加载：对于需要动态加载不同功能模块的应用，Bundle Splitting 可以根据用户的需求按需加载模块，减少不必要的资源消耗。
公共库和框架：对于使用公共库或框架的应用，可以将这些库和框架拆分成单独的模块，以便在多个页面中共享和复用。
国际化支持：对于需要支持多种语言的应用，可以将不同语言的资源文件拆分成独立的模块，根据用户的语言偏好进行加载。
代码分支管理：对于大型团队开发的项目，使用 Bundle Splitting 可以更好地实现代码的分支管理和并行开发，提高开发效率。

Bundle Splitting 在知名项目中的应用

示例 1：React.lazy 和 Suspense

React.js 是一个广泛使用的 JavaScript 库，用于构建用户界面。React 提供了 React.lazy 和 Suspense API 来实现 Bundle Splitting。

前端性能监控

Thu, 07 Aug 2025 00:00:00 +0800

大纲

我们会从以下三个方向来讲解埋点与监控的知识：

什么是埋点？什么是监控？
JS 中实现监控的核心方案
写一个“相对”完整的监控实例

一、什么是埋点？什么是监控？

在日常沟通中，我们经常会把【埋点】和【监控】放到一起说，但是它们在本质上是有一定的区别的：

1. 埋点

埋点主要用于收集用户行为数据。在日常开发中，我们会通过 在前端代码中插入代码或脚本的方式 来实现埋点功能。

埋点的主要作用就是：捕获特定用户行为（如点击、浏览、提交表单、页面跳转等）以及关键业务数据（如下单金额、商品类别等）

在日常开发中，埋点的实现方案大致可以分为以下三大类：

手动埋点：在代码中手动加入记录代码来捕获特定事件。
自动埋点：利用 DOM 事件代理等技术来捕获页面上所有事件，从而减少手动配置。
可视化埋点：通过工具界面标记需要采集的元素和事件，可以不用手写代码。

2. 监控

而监控则主要关注 系统的性能和稳定性。在日常开发中，我们会通过 采集页面加载时间、资源请求、错误日志等数据 的方式来实现前端监控。

监控的主要作用就是：及时发现并定位页面性能瓶颈或代码异常，目的是为了保障系统不出 bug

在日常开发中，监控一般需要完成以下三大部分：

性能监控：如：首屏加载时间、页面交互耗时、资源加载耗时等。
错误监控：捕获 JavaScript 错误、网络请求失败、资源加载异常等。
用户体验监控：收集白屏、卡顿等影响用户体验的问题等。

区别总结

维度	前端埋点	前端监控
目标	捕获用户行为数据	监控系统性能、错误、稳定性
数据类型	用户点击、表单提交、页面跳转等	页面加载时间、错误日志、卡顿情况等
实现方式	手动埋点、自动埋点、可视化埋点	错误捕获、性能指标采集
核心关注点	用户行为、业务数据	系统Bug、性能优化

二、JS 中实现监控的核心方案

根据上面所说，我们知道埋点和监控的目的存在不同，但是它们的思路确是有很多一致性的，其核心都是：获取关键的数据，发送（上报）给服务端，依据数据来解决其不同的目的。

所以，无论是埋点也好，还是监控也罢，我们都需要 获取关键位置数据。

1. 跟踪用户事件（点击、滚动等）

定义通用跟踪函数（后续事件会通过该函数完成上报）：trackEvent 函数接收事件类型和事件详情，并上报到服务端。

// 用于记录或发送跟踪数据到服务器的函数
function trackEvent(eventType, details) {
 console.log(`Event: ${eventType}`, details); // 在控制台打印事件类型和详情
 // 上报到服务端。
 fetch('/测试接口地址', { method: 'POST', body: JSON.stringify({ eventType, details }) });
}

捕获按钮点击事件：获取 id 为 myButton 的按钮，并在其 click 事件上添加监听器。在按钮被点击时调用 trackEvent 函数，记录点击事件的类型（button_click）、按钮 ID 和时间戳。

前端组件化开发

Thu, 07 Aug 2025 00:00:00 +0800

背景

不知道你有没有遇到过以下场景:

页面逻辑越来越多,代码越来越庞大,写到后面难以 hold 住所有逻辑,很容易牵一发而动全身.
你负责的页面好好的突然出现问题,查到最后是别人代码影响.
同样的逻辑在多个地方重复书写,每次一改要改一批文件

随着前端项目复杂度的急剧增加, 上面列出的几种场景就是传统开发中会出现的问题. 也是前端组件化出现的原因.

项目复杂度增加, 一个页面一个文件需要处理的内容过多.
重复性劳动多, 效率低
质量差, 不可控

组件化初探

正是由于出现了这样的问题, 为了在越来越复杂的前端项目中提高开发效率和保证开发质量, 各路大神们开始通过各种方式来尝试解决问题.

曾经非常火的 jQuery 就基于自己建立了 jQuery 插件机制. 你可以将一些常用逻辑进行封装变成 jQuery 插件, 还可以将插件开源进行共享. 比如纯手写会吐血的日期时间选择器,轮播, 多级菜单等等. 你可以在这里浏览更多jQuery插件.

jQuery 插件的用法通常是:

$(".select").pluginName(config)

除了 jQuery 插件模式, 还有一种常见模式是对象模式. 这种模式现在仍然有很多优秀的库在被我们直接或者间接使用. 比如: swiper

对象模式的写法:

<!-- Slider main container -->
<div class="swiper-container">
 <!-- Additional required wrapper -->
 <div class="swiper-wrapper">
 <!-- Slides -->
 <div class="swiper-slide">Slide 1</div>
 <div class="swiper-slide">Slide 2</div>
 <div class="swiper-slide">Slide 3</div>
 ...
 </div>
</div>

<script src="path/to/swiper.min.js"></script>
<script>
 var mySwiper = new Swiper ('.swiper-container', {
 direction: 'vertical',
 loop: true,
 })
 </script>

对象模式通过配置创建对象, 通常创建对象的参数中有一项是元素/元素选择器, 通过js代码将逻辑与这个元素紧密绑定.

单页面架构

Thu, 07 Aug 2025 00:00:00 +0800

传统的多页面应用构建方式：

纯服务端渲染，前后端不分离，使用jsp,jade,’ejs’,’tempalte’等技术在后台先拼接成对应的HTML结构，然后转换成字符串，在每个对应的路由返回对应的数据（文件）即可

Jade模版服务端渲染，代码实现：

const express= require('express')
const app =express()
const jade = require('jade')
const result = ***
const url path = ***
const html = jade.renderFile(url, { data: result, urlPath })//传入数据给模板引擎
app.get('/',(req,res)=>{
 res.send(html)//直接吐渲染好的`html`文件拼接成字符串返回给客户端
}) //RestFul接口

app.listen(3000,err=>{
 //do something
})

使用jQuery等传统库绘制的前端页面

传统前后端不分离，服务端渲染的优缺点：

优点：

SEO友好，因为返回给前端的是渲染好的HTML结构，里面的内容都可以被爬虫抓取到。
对于一些应用性能等要求不高的项目，比如某个公司的静态网页，内容很少的情况下，直接一把梭就好，不用再搭建工程化的环境等
对于后端程序员（全干工程师）来说，不用去特意学习前端框架，公司也不用特意去招聘前端
兼容性好，传统服务端渲染多页面应用吐出来的都是字符串，HTML结构

缺点：

如果项目很大，不利于维护，据我所知，目前很多云计算公司，还有不少都是使用非单页面应用，例如一个几十万行的项目是用jQuery写的，如果注释和文档不是非常齐全，那么真的会无从下手
性能和用户体验，不能跟单页面应用相比
后期迭代，升级空间不大，目前大部分写得比较好的库，都建立vue,react等框架基础上，他们都有一套自己的运行机制，有自己的生命周期，并且不像传统的应用，还加上了一层虚拟DOM以及diff算法
现在类似Ant-Design-pro这样的开箱即用的库已经很多，单页面应用的学习和开发成本已经很低很低，如果还在使用传统的技术去开发新的应用，对于开发人员多内心来说也是一种折磨。

这里并不是说多页面应用不好，只能说各有各自的好，单页面应用如果通过大量的极致优化手段，是可以从不少方面跟原生一拼。

目前的单页面应用：

只有一张Web页面的应用，是一种从Web服务器加载的富客户端，单页面跳转仅刷新局部资源，公共资源(js、css等)仅需加载一次，常用于PC端官网、购物等网站
其实只有一个空的DIV标签，其他都是js动态生态的内容

单页面应用实现步骤：

代码实现：

首先是一个静态模板文件 index.html

<!DOCTYPE html>
<html lang="en">

<head>
 <meta charset="UTF-8">
 <meta name="viewport" content="width=device-width, initial-scale=1.0">
 <meta http-equiv="X-UA-Compatible" content="ie=edge">
 <title>Document</title>
</head>

<body>
 <div id="root"></div>
</body>
<script>

</script>

</html>

在vue react框架的入口文件中指定对应的渲染元素：

import React from 'react;
import ReactDOM from 'react-dom';

ReactDOM.render(
<App/>,
document.querySelector("#root")
)

引入react-router或者 react-router-dom，dva等路由跳转的库
配置路由跳转

<HashRouter>//这里使用HashRouter
 <ErrorBoundary>//React错误边界
 <Switch>
 <Route path="/login" component={Login} />
 <Route path="/home" component={Home} />
 <Route path="/" component={NotFound} />//404路由或者重定向都可以
 </Switch>
 </ErrorBoundary>
</HashRouter>

单页面应用所谓路由跳转，其实最终结果就是：

浏览器的url地址发生变化，但是其实并没有发送请求，也没有刷新整个页面
根据我们配置的路由信息，每次点击切换路由，会切换到不同的组件显示，类似于选项卡功能的实现,但是同时url地址栏会变化
分为HashRouter和BrowserRouter两种模式

自己实现一个粗略的路由跳转：

自己实现传统的`Hash`模式跳转：

hash 就是指 url 后的 # 号以及后面的字符。例如www.baidu.com/#segmentfault,那么#segmentfault就是hash值

状态管理工程化

Thu, 07 Aug 2025 00:00:00 +0800

状态管理是一个前端界老生常谈的话题了，所有前端框架的发展历程中都离不开状态管理的迭代与更替，对于react来说呢，整个状态管理的发展也随着react架构的变更和新特性的加入而不停的做调整，作为一个一起伴随react成长了快5年的开发者，经历过reflux、redux、mobx，以及其他redux衍生方案dva、mirror、rematch等等后，我觉得它们都不是我想要的状态管理的终极形态，所以为了打造一个和react结合得最优雅、使用起来最简单、运行起来最高效的状态管理方案，踏上了追梦旅途。

为何需要状态管理

为何需要在前端引用里引入状态管理，基本上大家都达成了共识，在此我总结为3点：

随着应用的规模越来越大，功能越来越复杂，组件的抽象粒度会越来越细，在视图中组合起来后层级也会越来越深，能够方便的跨组件共享状态成为迫切的需求。
状态也需要按模块切分，状态的变更逻辑背后其实就是我们的业务逻辑，将其抽离出来能够彻底解耦ui和业务，有利于逻辑复用，以及持续的维护和迭代。
状态如果能够被集中的管理起来，并合理的派发有利于组件按需更新，缩小渲染范围，从而提高渲染性能

已有状态管理方案现状

redux

遵循react不可变思路的状态管理方案，无论从git的star排名还是社区的繁荣度，首推的一定是redux这个react界状态管理一哥，约束使用唯一路径reducer纯函数去修改store的数据，从而达到整个应用的状态流转清晰、可追溯。

image.png

mbox

遵循响应式的后期之秀mbox，提出了computed、reaction的概念，其官方的口号就是任何可以从应用程序状态派生的内容都应该派生出来，通过将原始的普通json对象转变为可观察对象，我们可以直接修改状态，mbox会自动驱动ui渲染更新，因其响应式的理念和vue很相近，在react里搭配mobx-react使用后，很多人戏称mobx是一个将react变成了类vue开发体验的状态管理方案。

image.png

当然因为mbox操作数据很方便，不满足大型应用里对状态流转路径清晰可追溯的诉求，为了约束用户的更新行为，配套出了一个mobx-state-tree，总而言之，mobx成为了响应式的代表。

其他

剩下的状态管理方案，主要有3类。

一类是不满足redux代码冗余啰嗦，接口不够友好等缺点，进而在redux之上做2次封装，典型的代表国外的有如rematch，国内有如dva、mirror等，我将它们称为redux衍生的家族作品，或者是解读了redux源码，整合自己的思路重新设计一个库，如final-state、retalk、hydux等，我将它们称为类redux作品。

一类是走响应式道路的方案，和mobx一样，劫持普通状态对象转变为可观察对象，如dob，我将它们称为类mobx作品。

剩下的就是利用react context api或者最新的hook特性，主打轻量，上手简单，概念少的方案，如unstated-next，reactn、smox、react-model等。

我心中的理想方案

上述相关的各种方案，都各自在一定程度上能满足我们的需求，但是对于追求完美的水瓶座程序猿，我觉得它们终究都不是我理想的方案，它们或小而美、或大而全，但还是不够强，不够友好，所以决定开始自研状态管理方案。

我知道小和美、全、强本身是相冲突的，我能接受一定量的大，gzip后10kb到20kb都是我接受的范围，在此基础上，去逐步地实现美、全、强，以便达到以下目的，从而体现出和现有状态管理框架的差异性、优越性。

让新手使用的时候，无需了解新的特性api，无感知状态管理的存在，使其遁于无形之中，仅按照react的思路组织代码，就能享受到状态管理带来的福利。
让老手可以结合对状态管理的已有认知来使用新提供的特性api，还原各种社区公认的最佳实践，同时还能向上继续探索和提炼，挖掘状态管理带来的更多收益。
在react有了hook特性之后，让class组件和function组件都能够享有一致的思路、一致的api接入状态管理，不产生割裂感。
在保持以上3点的基础上，让用户能够使用更精简且更符合思维直觉的组织方式书写代码，同时还能够获得巨大的性能提升收益。

为了达成以上目标，立项concent，将其定义为一个可预测、零入侵、渐进式、高性能的增强型状态管理方案，期待能把他打磨成为一个真真实实让用户用起来感觉到美丽、全面、强大的框架。

说人话就是：理解起来够简单、代码写起来够优雅、工程架构起来够健壮、性能用起来够卓越…… ^_^

concent.png

可预测

react是一个基于pull based来做变化侦测的ui框架，对于用户来说，需要显式的调用setState来让react感知到状态变化，所以concent遵循react经典的不可变原则来体现可预测，不使用劫持对象将转变为可观察对象的方式来感知状态变化（要不然又成为了一个类mobx……）, 也不使用时全局pub&sub的模式来驱动相关视图更新，同时还要配置各种reselect、redux-saga等中间件来解决计算缓存、异步action等等问题（如果这样，岂不是又迈向了一个redux全家桶轮子的不归路….. ）

吐槽一下：redux粗放的订阅粒度在组件越来越多，状态越来越复杂的时候，经常因为组件订阅了不需要的数据而造成冗余更新，而且各种手写mapXXXToYYY很烦啊有木有啊有木有，伤不起啊伤不起……

零入侵

上面提到了期望新手仅按照react的思路组织代码，就能够享受到状态管理带来的福利，所以必然只能在setState之上做文章，其实我们可以把setState当做一个下达渲染指令重要入口（除此之外，还有forceUpdate）。

setState，下达更新指令

仔细看看上图，有没有发现有什么描述不太准确的地方，我们看看官方的setState函数签名描述:

代码语言：txt

AI代码解释

setState<K extends keyof S>(
 state: ((prevState: Readonly<S>, props: Readonly<P>) => (Pick<S, K> | S | null)) | (Pick<S, K> | S | null),
 callback?: () => void
): void;

通过签名描述，我们可以看出传递给setState的是一个部分状态(片段状态)，实际上我们在调用setState也是经常这么做的，修改了谁就传递对应的stateKey和值。

工程化 on Last Stand

前端模块化

一、模块化的理解

1.什么是模块?

2.模块化的进化过程

Webpack与Vite

前言

定位

运行原理

构建方式

http2

热更新

任务自动化

什么是npm scripts？

为什么使用npm scripts？

如何定义和使用npm scripts？

1. 设置基本的开发任务

前端构建工具详解

YUI Tool + Ant

Grunt / Gulp

前端任务自动化（npm scripts实现）

什么是npm scripts？

为什么使用npm scripts？

如何定义和使用npm scripts？

1. 设置基本的开发任务

代码规范工程化

1. ESlint - 检查你的 JavaScript 代码

1.1. ESLint 及其作用

1.2. ESLint 快速上手

版本控制

什么是版本控制

为什么要做版本控制

代码一致性

可追溯性

可维护性

团队协作

版本控制工具Git

Git的安装

WIndows

图形化工具

安装

使用

包管理

一、剖析 package.json

1.1 必备属性

npm包命名规则

查看包是否被占用

1.2描述信息

基本描述

持续集成/持续部署（CI/CD）

传统应用发布模式

缺点

CI/CD

GitLab内置CI/CD

运行流水线任务

配置.gitlab-ci.yml

代码分割工程化

什么是 Bundle Splitting？

Bundle Splitting 的优点

Bundle Splitting 的缺点

Bundle Splitting 的适用场景

Bundle Splitting 在知名项目中的应用

示例 1：React.lazy 和 Suspense

前端性能监控

大纲

一、什么是埋点？什么是监控？

1. 埋点

2. 监控

区别总结

二、JS 中实现监控的核心方案

1. 跟踪用户事件（点击、滚动等）

前端组件化开发

背景

组件化初探

单页面架构

传统的多页面应用构建方式：

传统前后端不分离，服务端渲染的优缺点：

优点：

缺点：

目前的单页面应用：

什么是`npm scripts`？

为什么使用`npm scripts`？

如何定义和使用`npm scripts`？

什么是`npm scripts`？

为什么使用`npm scripts`？

如何定义和使用`npm scripts`？

版本控制工具`Git`

`Git`的安装

`WIndows`

自己实现传统的`Hash`模式跳转：