前端工程化（一）：从流程封装到稳定交付

前端工程化不只是把命令写进 package.json

我最初理解前端工程化，是把前端的各种流程封装成可配置的模块，通过统一配置和命令减少重复操作。这个理解抓住了自动化的入口，但还不完整。

前端工程化真正要解决的是一组持续出现的问题：多人协作时如何保持一致，代码提交前如何发现质量问题，源码如何稳定地变成可运行产物，功能如何经过测试再发布，以及上线后出现异常时如何定位和修复。配置化和命令化只是实现这些目标的手段，最终目标是让项目稳定、可复现、可维护地交付。

一条完整的前端交付链路

一个前端功能从实现到上线，可以按下面的顺序理解：

开发 -> 检查 -> 构建 -> 测试 -> 发布 -> 监控 -> 维护

开发是根据需求实现功能。检查通过 lint、类型检查、依赖检查等手段发现规范问题和潜在缺陷。构建把源码转换、打包成可运行的产物；它不等同于把代码直接部署到测试环境。测试在隔离环境中验证功能、兼容性和回归风险。发布把通过验证的产物部署到线上。监控持续收集错误、性能和业务异常。维护则根据监控和用户反馈修复问题、处理回滚并继续迭代。

这条链路的关键在于每个环节都有明确职责。检查不是测试的替代品，构建也不是发布的同义词。职责分清之后，团队才知道问题应该在哪一层被发现和处理。

用真实项目理解工程化入口

在 个人网站 中，package.json 提供了统一的脚本入口。例如：

{
  "packageManager": "npm@10.8.2",
  "scripts": {
    "dev": "next dev -p 23556",
    "build": "next build",
    "lint": "next lint"
  }
}

build 对应构建环节，负责生成可运行产物；lint 对应规范检查，帮助团队在提交或 CI 阶段发现代码风格和潜在质量问题；项目中的 test:* 脚本则对应自动化测试和回归验证。这些脚本把常用动作固定成团队可以重复执行的入口，也让 CI 能够调用同一套命令。

这里有一个容易混淆的细节：lint 主要负责检查规范和潜在问题，自动格式化通常由 Prettier 或 ESLint 的 fix 能力完成。面试时把“检查”和“格式化”区分开，能够说明你理解工具的实际边界。

工具不是越多越工程化

工程化不等于使用了很多工具。判断一个工具是否有价值，要看它解决了什么风险，以及结果能否被验证。

例如，锁文件和固定的包管理器版本解决的是依赖安装不可复现的问题；TypeScript 检查解决的是一部分静态类型错误；构建分析解决的是产物体积和加载性能问题；E2E 测试解决的是关键用户流程回归问题。它们只有被放进稳定的流程，并且在失败时真正阻止不合格改动继续交付，才构成工程化能力。