第二章 开发环境搭建与工程化配置
好，咱们正式开始动手了。这一章我会带你搭好开发环境，把工程化的架子立起来。说实话，很多新手项目最后崩就崩在环境上——代码规范没人管、Git提交乱七八糟、构建脚本跑不通。我见过太多这样的案例了。
所以这一章，咱们一步到位。从Node.js配置开始，到Vite初始化，再到ESLint+Prettier的代码规范，最后是Git工作流。你跟着走一遍，后面写代码会舒服很多。
2.1 Node.js与包管理器配置
先说说Node.js。这东西是前端开发的基石，没有它，Vite、Webpack这些都跑不起来。我个人习惯用nvm来管理Node版本，为什么？因为不同项目可能依赖不同版本的Node，你总不能每次都卸载重装吧？
推荐做法：使用nvm（Node Version Manager）管理多版本Node。
安装nvm后，你可以这样操作：
# 安装指定版本
nvm install 18.18.0
# 切换版本
nvm use 18.18.0
# 查看当前版本
node -v
包管理器这块，我推荐用pnpm。为什么不是npm或yarn？说白了，pnpm的硬链接机制能帮你省下大量磁盘空间。我在一个大型项目中试过，node_modules从1.2GB降到了400MB。你想想看，这差距有多大。
小技巧：安装pnpm后，建议配置一下镜像源，国内用户用淘宝源会快很多。
# 安装pnpm
npm install -g pnpm
# 设置淘宝镜像
pnpm config set registry https://registry.npmmirror.com
嗯，这里要注意一点：pnpm的workspace功能非常强大，后面我们做monorepo时会用到。现在先记住它的安装命令就好。
2.2 Vite项目初始化
Vite，说实话，是我用过最爽的构建工具。冷启动快到飞起，HMR几乎无感。我记得第一次用Vite替换Webpack时，项目启动时间从40秒降到了2秒。那种感觉，嗯，你试过就知道了。
初始化一个Vue3 + TypeScript项目：
pnpm create vite my-vue-app --template vue-ts
cd my-vue-app
pnpm install
项目结构大概长这样：
| 目录/文件 | 作用 |
|---|---|
| src/ | 源代码目录 |
| public/ | 静态资源目录 |
| vite.config.ts | Vite配置文件 |
| tsconfig.json | TypeScript配置 |
| package.json | 项目依赖与脚本 |
我个人习惯在初始化后，立刻改一下vite.config.ts，加上路径别名。这样后面写import的时候就不用写一长串相对路径了。
// vite.config.ts
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
import { resolve } from 'path'
export default defineConfig({
plugins: [vue()],
resolve: {
alias: {
'@': resolve(__dirname, 'src')
}
}
})
注意：改完vite.config.ts后，记得重启开发服务器，否则别名不会生效。我曾经因为这个排查了半天，结果发现是忘了重启。
2.3 ESLint + Prettier 代码规范
代码规范这事，说白了就是团队之间的「共同语言」。你想想看，一个项目里有人用单引号，有人用双引号，有人缩进2格，有人缩进4格——这代码还能看吗？
我建议用ESLint做代码质量检查，Prettier做代码格式化。两者配合，一个管「对不对」，一个管「好不好看」。
安装配置：
pnpm add -D eslint prettier eslint-plugin-vue @typescript-eslint/parser @typescript-eslint/eslint-plugin
pnpm add -D eslint-config-prettier eslint-plugin-prettier
然后创建.eslintrc.cjs：
module.exports = {
root: true,
env: {
browser: true,
es2021: true,
node: true
},
extends: [
'eslint:recommended',
'plugin:vue/vue3-recommended',
'plugin:@typescript-eslint/recommended',
'prettier'
],
parser: 'vue-eslint-parser',
parserOptions: {
parser: '@typescript-eslint/parser',
ecmaVersion: 'latest',
sourceType: 'module'
},
rules: {
'vue/multi-word-component-names': 'off',
'@typescript-eslint/no-explicit-any': 'warn'
}
}
再创建.prettierrc：
{
"semi": false,
"singleQuote": true,
"tabWidth": 2,
"trailingComma": "none",
"printWidth": 100
}
避坑指南：我曾经遇到过ESLint和Prettier规则冲突的情况，比如ESLint要求分号，Prettier要求无分号。解决办法就是加上eslint-config-prettier，它会关掉所有与Prettier冲突的ESLint规则。
最后在package.json里加个脚本：
"scripts": {
"lint": "eslint src --ext .vue,.ts,.tsx --fix",
"format": "prettier --write src/**/*.{vue,ts,tsx,css}"
}
2.4 Git工作流与分支策略
Git工作流，说白了就是团队协作的「交通规则」。没有规则，大家各开各的车，早晚要撞上。我经历过最惨的一次，是三个人同时改了同一个文件，合并时冲突了200多行，光解决冲突就花了一下午。
我推荐用Git Flow模型，但根据企业项目做了简化：
| 分支名称 | 用途 | 来源 |
|---|---|---|
| main | 生产环境代码，只接受合并请求 | release分支 |
| develop | 开发主分支，日常开发的基础 | main分支 |
| feature/* | 功能开发分支，比如feature/login | develop分支 |
| release/* | 发布准备分支，只修bug不加功能 | develop分支 |
| hotfix/* | 紧急修复分支，直接修复生产问题 | main分支 |
实际操作中，我习惯这样：
# 从develop拉取新功能分支
git checkout develop
git pull
git checkout -b feature/login
# 开发完成后合并回develop
git checkout develop
git merge --no-ff feature/login
git branch -d feature/login
关键点：合并时一定要用--no-ff参数。这样能保留分支历史，方便以后回溯。我曾经因为没用这个参数，导致一个功能分支的提交记录全混在一起，查bug时根本分不清哪次提交改了什么东西。
提交信息也有讲究。我推荐用Conventional Commits规范：
feat: 新增用户登录功能
fix: 修复登录页面样式错乱问题
docs: 更新API文档
refactor: 重构用户模块的权限校验逻辑
为什么要这么写？因为后面我们可以用工具自动生成CHANGELOG，还能根据提交类型自动触发CI流程。你想想看，这多省事。
小建议：在项目根目录创建.gitignore文件，把node_modules、dist、.env这些文件排除掉。我见过有人把node_modules提交到仓库，结果clone下来花了半小时，还占了几百兆空间。
好了，环境搭建这块就到这。你跟着走一遍，应该能搭出一个干净、规范、可维护的开发环境。下一章我们开始写真正的业务代码，到时候这些配置就会派上用场了。