为什么说 AI 时代，前端开发者对前端工程化的要求更高了❓❓❓

前端工程化在前端领域地位极高，因为它系统性地解决了前端开发中效率、协作、质量、维护性等一系列核心问题，可以说是现代前端技术体系的基石。

前端工程化带来的价值可以从这四个方面看：

总的来说，前端工程化让开发者从单纯的 “切图仔” 成长为能够参与大型系统开发的工程师。通过引入规范与工具，不仅显著提升了团队协作效率，还有效减少了开发过程中的冲突与返工，成为现代前端团队协作的 “润滑剂”。

什么是前端工程化

前端工程化 大约在 2018 年前后在国内被广泛提出，其核心是将后端成熟的软件工程理念、工具与流程系统性地引入前端开发。

它旨在通过规范、工具链与协作流程，提升开发效率、保障交付质量、降低维护成本。前端工程化不只是技术选型，更是一种体系化、流程化的开发方式。

其核心包括代码规范、自动化构建、模块化设计、测试体系和持续集成等关键环节。通过工程化，前端从“写页面”转向“做工程”，实现了从个体开发到团队协作的转变。

它不仅优化了前端的生产方式，也推动了大型系统开发中前端角色的重要性。如今，前端工程化已成为现代前端开发不可或缺的基础能力。

为什么 AI 时代，前端工程化更重要

在 AI 时代，前端工程化不仅没有“过时”，反而变得更重要，甚至成为人机协作高效落地的关键基石。原因可以从以下几个方面理解。

虽然 AI 可以辅助生成代码、文档甚至 UI，但它并不能替代工程化体系，原因有：

最差的情况下有可能会删除或者修改你之前已经写好的代码，如果缺少这些工程化的手段，你甚至不知道它已经修改你的代码了，最终等到上线的时候无数的 bug 产生。

通过标准化输出让 AI 更智能，清晰的项目结构、代码规范、模块划分能让 AI 更准确地补全、修改或重构代码。例如 ESLint、TypeScript 的规则为 AI 提供了明确的限制条件，有助于生成更高质量的代码。

在生成的代码需要规范，生成完成之后更需要检验，大概的流程也有如下几个方面：

没有工程化，AI 产出的代码难以被真正“上线使用”。

AI 时代，对一些 CRUD 的简单要求减少了，但是对工程化提出了更高要求。

前端工程化

接下来我们将分为多个小节来讲解一下前端工程化的不同技术充当着什么角色。

技术选型

在前端工程化中，技术选型看似是一道“选择题”，本质上却关系到项目的开发效率、团队协作和未来的可维护性。对于框架选择而言，建议优先考虑两个关键因素：

统一规范

统一规范又分为代码规范、git 规范、项目规范和 UI 规范。

代码规范

统一代码规范带来的好处是显而易见的，尤其在团队开发中更显重要：

当团队成员都严格遵循统一的代码规范时，整个项目的代码风格将保持高度一致，看别人的代码就像在看自己的代码一样自然顺畅。

为了实现这一目标，我们可以借助工具化手段来强制和规范编码行为，例如使用 ESLint 检查 JavaScript/TypeScript 的语法和代码质量，Stylelint 统一 CSS/SCSS 的书写规范，而 Prettier 则负责自动格式化各类代码，使其保持整洁一致。

这些工具不仅能在编码阶段就发现潜在问题，还能集成到 Git Hook 或 CI 流程中，确保所有提交的代码都符合团队标准。统一规范减少了 code review 中对格式问题的争论，让团队更专注于业务逻辑的优化。

更重要的是，长期在规范的约束下编程，有助于开发者养成良好的工程素养和职业习惯，提升整体开发质量和协作效率。工具是手段，习惯是目标，工程化规范最终是为了让每一位开发者都能写出“团队级”的代码。

除了上面提到的，还有很多相同功能的工具这里就不细说了。

Git 规范

Git 规范主要指团队在使用 Git 进行代码版本管理时，对分支策略、提交信息、代码合并方式等的统一约定，其目标是提升协作效率、降低沟通成本、保障版本可控。

分支管理规范可以遵循如下 Git Flow 模型：

main        # 生产环境分支

develop     # 开发集成分支

feature/*   # 功能分支

release/*   # 发布准备分支

hotfix/*    # 线上紧急修复分支

分支重要，提交信息规范也更重要，一份清晰规范的提交信息对后期维护、回滚、自动发布都非常重要，好的提交信息让其他协作人员知道你这个分支具体做了什么。

推荐使用 Conventional Commits 规范，格式如下：

<type>(): 

常见的  类型：

如下示例所示：

feat(login): 添加用户登录功能
fix(api): 修复接口返回字段错误
docs(readme): 完善项目使用说明

配套的工具推荐如下表所示：

Git 规范，是让代码“有条不紊”地流动在团队之间的交通规则，是高效协作和持续交付的基础设施。

项目规范

项目规范是对整个项目工程的结构、组织方式、开发约定的一套统一标准，它能帮助团队协作、代码维护、快速上手和高质量交付。

项目目录结构规范可以让项目保持统一、清晰的项目目录结构，有助于快速定位文件、分工协作，如下是一个简单的目录规范：

src/

├── assets/        # 静态资源（图片、字体等）

├── components/    # 可复用的基础组件

├── pages/         # 页面级组件

├── services/      # API 请求模块

├── utils/         # 工具函数

├── hooks/         # 自定义 hooks（React 项目）

├── styles/        # 全局样式

├── config/        # 配置文件（如常量、环境变量）

├── router/        # 路由配置

├── store/         # 状态管理（如 Vuex / Redux）

└── main.ts        # 应用入口

这只是一个很简答也很通用的目录结构，还有很多进阶的目录结构方案。

命名方式，这个可以根据不同的团队不同的风格来指定。

部署

借助自动化流程实现一键部署或者自动部署，常用的工具主要有以下：

流程通常如下：

Push → 检查代码规范 → 构建 → 运行测试 → 上传产物 → 通知部署 → 上线

可以参考一下 Action 配置：

name: Deploy Next.js to Alibaba Cloud ECS


on:

  push:

    branches:
- main

jobs:

  deploy:

    runs-on: ubuntu-latest


    steps:
- name: Checkout code

        uses: actions/checkout@v4.2.0

- name: Set up Node.js

        uses: actions/setup-node@v4.2.0

        with:

          node-version: "22.11.0"

- name: Install pnpm

        run: npm install -g pnpm@9.4.0

- name: Deploy to server via SSH

        uses: appleboy/ssh-action@v1.2.1

        with:

          host: ${{ secrets.SERVER_HOST }}

          username: ${{ secrets.SERVER_USERNAME }}

          port: ${{ secrets.SERVER_PORT }}

          password: ${{ secrets.SERVER_PASSWORD }}

          script: |
# 显示当前环境信息
echo "Shell: $SHELL"
echo "PATH before: $PATH"

# 加载环境配置文件
source ~/.bashrc
source ~/.profile

# 如果使用 NVM，加载 NVM 环境
export NVM_DIR="$HOME/.nvm"

            [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

# 添加常见的 Node.js 安装路径到 PATH
export PATH="$HOME/.nvm/versions/node/*/bin:/usr/local/bin:/usr/bin:/bin:$HOME/.npm-global/bin:$PATH"
echo "PATH after: $PATH"

# 查找 npm 的位置
which npm || echo "npm still not found in PATH"

# 使用绝对路径查找 npm
NPM_PATH=$(find /usr -name npm -type f 2>/dev/null | head -1)
if [ -n "$NPM_PATH" ]; then
echo "Found npm at: $NPM_PATH"
export PATH="$(dirname $NPM_PATH):$PATH"
fi

# 确保目标目录存在
mkdir -p /home/interview-guide
cd /home/interview-guide

# 如果本地仓库不存在，进行克隆
if [ ! -d "/home/interview-guide/.git" ]; then
echo "Cloning the repository..."
# 删除可能存在的空目录内容
rm -rf /home/interview-guide/*
# 使用 SSH 方式克隆
git clone git@github.com:xun082/interview-guide.git .
else
# 确保远程 URL 使用 SSH
git remote set-url origin git@github.com:xun082/interview-guide.git
# 获取最新代码
git fetch origin main
git reset --hard origin/main
fi

# 使用找到的 npm 路径或尝试直接运行
if [ -n "$NPM_PATH" ]; then
$NPM_PATH install -g pnpm@9.4.0
$NPM_PATH install -g pm2
else
npm install -g pnpm@9.4.0
npm install -g pm2
fi

# 安装依赖
pnpm install || npm install

# 构建项目
pnpm run build || npm run build

# 重启应用
pm2 restart interview-guide || pm2 start "pnpm start" --name interview-guide || pm2 start "npm start" --name interview-guide

这段 GitHub Actions 配置实现了将 Next.js 项目自动部署到阿里云 ECS 服务器的流程。它在检测到 main 分支有新的代码提交后，自动拉取代码、安装依赖并构建项目。随后通过 SSH 远程连接服务器，拉取或更新项目代码，并使用 PM2 启动或重启应用。整个流程自动化，无需人工干预，保障部署高效、可重复。

除了 PM2 之外，我们还可以使用 Docker 镜像部署。

🛡️ 监控

前端监控是指：对 Web 应用在用户真实环境中的运行状态进行实时采集与分析，以发现性能瓶颈、错误异常和用户行为，最终帮助开发团队提升系统稳定性和用户体验。

🚦 性能监控

性能监控的目标是衡量页面加载速度、交互流畅度等关键性性能指标。

常见指标：

它有助于定位性能瓶颈（如资源过大、阻塞脚本）、优化用户体验（如加载缓慢或白屏问题），并支持性能回归分析，及时发现上线后的性能退化。

❌ 错误监控

错误监控的目标是捕捉并上报运行时异常，辅助开发快速修复 Bug。

常见的错误类型主要有以下几个方面：

假设我们使用了 fetch 进行封装，那么我们就可以对错误进行统一处理，后续我们可以再具体调用的时候根据不同的场景来传入不同的错误提示告知用户：

错误上报

数据上报是指前端在运行过程中将采集到的监控信息（性能、错误、行为等）发送到服务端的过程。它是前端监控从“收集”到“分析”的桥梁。

上报的数据类型主要有以下几个方面：

数据上报需要重点考虑的几个关键因素:

建议：选择 异步非阻塞 且浏览器支持好的方式（优先 sendBeacon），并对数据做统一封装处理。

2. 何时上报（上报时机）
   • 立即上报：错误发生后马上发送（如 JS 报错）
   • 延迟上报：页面稳定后延迟几秒，防止干扰首屏加载
   • 页面卸载前上报：用 sendBeacon 上报用户停留数据等
   • 批量上报：积累一批数据后统一发送，减少请求频率
   • 定时上报：用户停留一段时间后定期上报（行为数据）