一. 项目介绍 – 后台管理系统

项目预览地址：http://152.136.185.210
- 账号1：coderwhy 密码：123456
- 账号2：coderdemo 密码：123456
技术栈介绍：
- 开发工具 : Visual Studio Code
- 编程语言 : TypeScript 4.x + JavaScript
- 构建工具 : Vite 3.x / Webpack5.x
- 前端框架 : Vue 3.x + setup
- 路由工具 : Vue Router 4.x
- 状态管理 : Vuex 4.x / Pinia
- UI 框架 : Element Plus
- 可视化 : Echart5.x
- 工具库 : @vueuse/core + dayjs + countup.js等等
- CSS 预编译 : Sass / Less
- HTTP 工具 : Axios
- Git Hook 工具 : husky
- 代码规范 : EditorConfig + Prettier + ESLint
- 提交规范 : Commitizen + Commitlint
- 自动部署 : Centos + Jenkins + Nginx

二. 创建Vue项目

方式一：Vue CLI
- 基于webpack工具
- 命令：vue create
方式二：create-vue
- 基于vite工具
- 命令：npm init vue@latest
项目配置:
- 配置项目的icon
- 配置项目的标题
- 配置项目别名等（vite默认配置）
- 配置tsconfig.json

三. 配置项目环境

安装volar和volar + TS插件：

配置vue文件模块（增加vue文件的类型提示）：

typescript

  declare module "*.vue" {
    import { DefineComponent } from "vue"
    const component: DefineComponent
    export default component
  }

四. 配置项目代码规范

1. 集成editorconfig配置

EditorConfig 有助于为跨各种编辑器和 IDE 处理同一项目的多个开发人员保持一致的编码风格
官方文档：https://editorconfig.org/

推荐配置一般如下：

yaml

# http://editorconfig.org

root = true

[*] # 表示所有文件适用
charset = utf-8 # 设置文件字符集为 utf-8
indent_style = space # 缩进风格（tab | space）
indent_size = 2 # 缩进大小
end_of_line = lf # 控制换行类型(lf | cr | crlf)
trim_trailing_whitespace = true # 去除行尾的任意空白字符
insert_final_newline = true # 始终在文件末尾插入一个新行

[*.md] # 表示仅 md 文件适用以下规则
max_line_length = off
trim_trailing_whitespace = false

VSCode需要安装一个插件：EditorConfig for VS Code

2. 使用prettier工具

Prettier 是一款强大的代码格式化工具，支持JavaScript、TypeScript、CSS、SCSS、Less、JSX、Angular、Vue、GraphQL、JSON、Markdown等语言，基本上前端能用到的文件格式它都可以搞定，是当下最流行的代码格式化工具

安装prettier
shell
```
npm i prettier -D
```
创建.prettierrc文件并配置如下（加不加后缀.json都可）：
- useTabs：是否使用tab缩进，false则为使用空格缩进
  - 如果配置的空格缩进，我们使用tab缩进产生的制表符，会自动转化为空格
- tabWidth：tab是空格的情况下，是几个空格，选择2个
- printWidth：当行字符的长度，推荐80，也有人喜欢100或者120
- singleQuote：是否使用单引号，false则为使用双引号
- trailingComma：在多行输入的尾逗号是否添加，设置为none，比如对象类型的最后一个属性后面是否加一个
- semi：语句末尾是否要加分号，默认值true，选择false表示不加
json
```
// .prettierrc || .prettierrc.json

{
  "useTabs": false,
  "tabWidth": 2,
  "printWidth": 80,
  "singleQuote": true,
  "trailingComma": "none",
  "semi": false
}
```
注意：
- vite帮我们创建的vue项目，默认的是.prettierrc.json。后缀.json写不写都可以读到的
- 默认创建的配置项为{}，表示使用prettier默认的配置项

创建.prettierignore忽略文件，对以下文件不进行格式化

/dist/*
/build/*
.local
.output.js
/node_modules/**

**/*.svg
**/*.sh

/public/*

VSCode需要安装prettier的插件
VSCode中的配置
- settings => format on save => 勾选上
- settings => editor default format => 选择 prettier
测试prettier是否生效
- 测试一：在代码中保存代码
- 测试二：配置一次性修改的命令
- 在package.json中配置一个scripts：
  json
```
"scripts": {
  "start": "craco start",
  "build": "craco build",
  "test": "craco test",
  "eject": "react-scripts eject",
+ "prettier": "prettier --write ."
}
```
- npm run prettier执行prettier对代码进行格式化，但是这样每次手动执行命令很麻烦，所以我们借助于prettier插件来帮助我们自动完成

3. 使用ESLint检测

在前面创建项目的时候，我们就选择了ESLint，所以Vue会默认帮助我们配置需要的ESLint环境
VSCode需要安装ESLint插件：

我们需要解决eslint和prettier配置冲突的问题：

安装插件：
- vue cli在创建项目时，如果选择prettier，那么这两个插件会自动安装
- vite的话，只需要安装eslint-plugin-prettier，另外一个插件可以不用安装，vite插件项目的时候帮我们安装了@vue/eslint-config-prettier
- react这两个依赖全部安装
shell
```
npm i eslint-plugin-prettier eslint-config-prettier -D
```

在.eslintrc.cjs添加prettier插件（react项目中也需要配置）：

json

/* eslint-env node */

require('@rushstack/eslint-patch/modern-module-resolution')

module.exports = {
  root: true,
  extends: [
    'plugin:vue/vue3-essential',
    'eslint:recommended',
    '@vue/eslint-config-typescript',
    '@vue/eslint-config-prettier',
+   'plugin:prettier/recommended'
  ],
  parserOptions: {
    ecmaVersion: 'latest'
  }
}

我们还会遇到像变量定义但未使用的警告：

按照如下操作即可解决：

步骤一：复制警告提示中的红框位置的code：@typescript-eslint/no-unused-vars

步骤二：在.eslintrc.cjs中添加规则：@typescript-eslint/no-unused-vars: off

/* eslint-env node */
require('@rushstack/eslint-patch/modern-module-resolution')

module.exports = {
  root: true,
  extends: [
    'plugin:vue/vue3-essential',
    'eslint:recommended',
    '@vue/eslint-config-typescript',
    '@vue/eslint-config-prettier',
    'plugin:prettier/recommended'
  ],
  parserOptions: {
    ecmaVersion: 'latest'
  },
  rules: {
+   '@typescript-eslint/no-unused-vars': 'off'
  }
}

VSCode的``settings.json文件中eslint的配置（vue项目不用配置，react`项目配置）
json
```
"eslint.lintTask.enable": true,
"eslint.alwaysShowStatus": true,
"eslint.validate": [
  "javascript",
  "javascriptreact",
  "typescript",
  "typescriptreact"
],
"editor.codeActionsOnSave": {
  "source.fixAll.eslint": true
},
```
- 当前测试2022.11.12，最新的vscode已不需要增加下面的配置，当然我们可以单独添加"eslint.alwaysShowStatus": true这一条，会在vscode编辑器窗口下方显示eslint的运行状态
如果是react创建的项目，只能手动来配置eslint
- 安装eslint
shell
```
npm i eslint -D
```
- 初始化eslint
shell
```
npx eslint --init
```
1. 只检查语法
2. 检查语法同时找到（显示）对应的问题（错误）（选择这个）
3. 检查语法、找到问题、强制格式化代码（因为我们项目前面已经安装了prettier，所以这里不需要eslint来帮我们格式化代码，所以选择第二个即可）
- 选择ESModule（第一个）
- 这里我们项目用的react
- 这个项目我们使用TS
- 可以两个都选择（绿色勾号表示已选择，空格键进行选择），项目里有些文件是跑在node上的，如craco.config.js，我们之后在单独对其进行配置，这里我们先只选择浏览器
- 之后生成的eslint配置文件（.eslintrc）以什么格式进行显示，目前我们选择js
- 这里我们选择yes，安装推荐的依赖
- 这里我们目前用的npm
- 之后项目的根目录文件夹下会多出一个eslint的配置文件
- 但是会报如下警告
- 因为我们前面只配置了跑在浏览器环境上的配置，并没有配置跑在node环境中的配置：
  - 解决方式一：
    - 在.eslintrc.js文件中的关闭rules中的no-undef项
      js
      // .eslintrc.js module.exports = { // ... rules: { + 'no-undef': 'off' } }
  - 解决方式二：
    - 在.eslintrc.js文件中的配置env
      js
      // .eslintrc.js module.exports = { env: { browser: true, es2021: true, + node: true }, // ... }
- craco.config.js文件中不让我们用require，因为前面选择ESModule的原因
- 我们直接关闭该选项即可
  js
```
// .eslintrc.js

module.exports = {
  rules: {
+   '@typescript-eslint/no-var-requires': 'off'
  }
}
```

注意：
eslint只会增加检测的黄色警告
prettier结合eslint才会出现红色报错
如果配置了没有效果，可尝试重启vscode

4. git Husky 和 eslint（后续）

虽然我们已经要求项目使用eslint了，但是不能保证组员提交代码之前都将eslint中的问题解决掉了：

也就是我们希望保证代码仓库中的代码都是符合eslint规范的；
那么我们需要在组员执行 git commit 命令的时候对其进行校验，如果不符合eslint规范，那么自动通过规范进行修复；

那么如何做到这一点呢？可以通过Husky工具：

husky是一个git hook工具，可以帮助我们触发git提交的各个阶段时：pre-commit、commit-msg、pre-push。做一些额外的操作

如何使用husky呢？

这里我们可以使用自动配置命令（基于已安装git和项目中已初始化git仓库）：

shell

npx husky-init && npm install # git bash
npx husky-init '&&' npm install # PowerShell中需要加引号（windows终端特性决定的）

上面这个命令会帮助我们做三件事：

1.安装husky相关的依赖：

2.在项目目录下创建 .husky 文件夹：

3.在package.json中添加一个脚本：

接下来，我们需要去完成一个操作：在进行commit时，执行lint脚本：

默认是npm test（经过测试的），我们这里改成npm run lint，之后每次提交代码的时候，就会先执行npm run lint命令

这个时候我们执行git commit的时候会自动对代码进行lint校验

5. git commit规范（后续）

5.1. 代码提交风格

通常我们的git commit会按照统一的风格来提交，这样可以快速定位每次提交的内容，方便之后对版本进行控制。

但是如果每次手动来编写这些是比较麻烦的事情，我们可以使用一个工具：Commitizen

Commitizen 是一个帮助我们编写规范 commit message 的工具；

1.安装Commitizen

shell

npm install commitizen -D

2.安装cz-conventional-changelog，并且初始化cz-conventional-changelog：

shell

npx commitizen init cz-conventional-changelog --save-dev --save-exact

这个命令会帮助我们安装cz-conventional-changelog：

并且在package.json中进行配置：

这个时候我们提交代码需要使用 npx cz：

第一步：选择type，本次更新的类型

Type	作用
feat	新增了一项新特性/功能 (A new feature)
fix	修复了一个 bug/问题 (A bug fix)
docs	只修改了文档 (Documentation onlu changes)
style	代码风格相关的修改，不影响代码运行结果（white-space, formatting, missing semi colons, etc）
refactor	既不修复错误也不添加功能的，代码重构(refactor)
perf	改善性能的代码更改(A code change that improves performance)
test	添加缺失的测试或纠正现有的测试(when adding missing tests)
build	影响构建系统或外部依赖项的更改（如 Webpack、Gulp 的更新配置等）
ci	对持续集成(CI)软件的配置文件或脚本的更改（e.g.：Github Actions、SauceLabs， package 中的 scripts 脚本命令）
chore	变更构建流程或辅助工具(比如更改测试环境)
revert	代码回退
types	类型定义相关的更改

🔔 提示

包管理工具（如 npm、yarn）的更新通常归为 chore 类型，除非它直接影响到构建流程或构建脚本（例如修改了 CI 流程、集成了新的构建步骤等），这时可以视作 build 类型。

第二步：选择本次修改的范围（作用域）
第三步：选择提交的信息
第四步：提交详细的描述信息（没有，跳过即可）
第五步：是否是一次重大的更改
第六步：是否影响某个open issue

提交完成，查看对应的提交记录
我们也可以在scripts中构建一个命令来执行 cz：

5.2. 代码提交验证

如果我们按照cz来规范了提交风格，但是依然有同事通过 git commit 按照不规范的格式提交应该怎么办呢？

我们可以通过commitlint来限制提交

安装 @commitlint/config-conventional 和 @commitlint/cli

shell

npm i @commitlint/config-conventional @commitlint/cli -D

在根目录创建commitlint.config.js文件，配置commitlint

// 如果module提示未定义，可在eslintrc.cjs文件中配置规则：'no-undef': 'off' 即可解决
module.exports = {
  extends: ['@commitlint/config-conventional']
}

使用husky生成commit-msg文件，验证提交信息：

shell

npx husky add .husky/commit-msg "npx --no-install commitlint --edit $1"

生成commit-msg文件，对我们的提交方式进行检测
之后，再通过git commit的方式提交，就不能提交成功了（cm是配置的commit -m的简写）
所以就只能通过npx cz的方式才能正常提交

五. 项目目录结构划分

.vscode > extension.json：项目开发推荐插件
node_modules：依赖包
public：其中的文件会被放到打包后的文件夹下的
src：源代码
.eslintrc.cjs：按照配置规则来检测代码
.gitignore：设置提交代码时，所忽略的一些文件
.prettierrc.json：代码格式化配置文件
env.d.ts：声明（定义）文件
index.html：入口文件html模板
package-lock.json：记录最终的版本等一些相关信息
package.json：记录项目相关的一些信息
RADEME.md：用来写一些文档信息
tsconfig.config.json：针对打包时相关的配置，推荐在此文件中修改，以及vite环境相关的ts文件如何进行编译，做了相关的选项
tsconfig.json：指定了编译项目所需的根目录下的文件以及编译选项，针对开发时相关的配置修改在此文件中修改（其实都欧克的）
vite.config.ts：给vite做一些配置

六. CSS样式的重置

对默认CSS样式进行重置:
- npm安装一个normalize.css
  shell
```
npm i normalize.css
```
- 手动创建一个reset.less
- 在css/index.less文件中引入下面文件，index.js入口文件中引入index.less即可
  - 引入之后，就会在webpack的依赖图中，到时候打包的时候，webpack就会帮我对引入的文件进行打包
- 默认是无法打包less文件的，这里需要安装less
  shell
```
npm i less -D
```

七. 全家桶 – 路由配置

安装vue-router：

shell

# 不需要加-D，因为生产环境中也需要用到
npm i vue-router

八. 全家桶 - 状态管理

状态管理的选择：
- vuex：目前依然使用较多的状态管理库
- pinia：强烈推荐, 未来趋势的状态管理库
安装pinia：
shell
```
npm i pinia
```

九. 网络请求封装axios

自己看文件，太多了不想列...

十. 区分 development 和 production 环境

Vite 在一个特殊的 import.meta.env 对象上暴露环境变量。

这里有一些在所有情况下都可以使用的内建变量：

import.meta.env.MODE: {string} 应用运行的模式
- 生产："production"，开发："development"
import.meta.env.PROD: {boolean} 应用是否运行在生产环境
import.meta.env.DEV: {boolean} 应用是否运行在开发环境 (永远与 import.meta.env.PROD 相反)
import.meta.env.SSR: {boolean} 应用是否运行在 server 上（即：是否是服务器端渲染）

Vite 使用 dotenv 从你的 环境目录中的下列文件加载额外的环境变量：

dotenv

.env                # 所有情况下都会加载
.env.local          # 所有情况下都会加载，但会被 git 忽略(相当于本地化)
.env.[model]        # 只在指定模式下加载
.env.[model].local  # 只在指定模式下加载，但会被 git 忽略(相当于本地化)

只有以 "VITE_" 为前缀的变量才会暴露给经过 Vite 处理的代码

dotenv

VITE_BASE_URL = 'http://xxx/xx/x'
VITE_TIME_OUT = 1000

注意：
vite创建的vue项目中，npm run preview可以直接在浏览器上跑打包后的生产文件
指定模式中的变量会覆盖全局模式中的同名变量

// 1.每次手动修改成开发环境或生产环境
// export const BASE_URL = 'http://coderwhy.dev:8000'
export const BASE_URL = 'http://codercba.prod:8000'

// 2.代码逻辑判断, 根据 Vite 默认提供的环境变量 判断当前环境
import.meta.env.MODE  // 当前运行的模式
import.meta.env.DEV   // 是否开发环境
import.meta.env.PROD  // 是否生产环境
import.meta.env.SSR   // 是否是服务器端渲染(server side render)

let BASE_URL = ''
if (import.meta.env.PROD) {
  BASE_URL = 'http://codercba.prod:8000'
} else {
  BASE_URL = 'http://coderwhy.dev:8000'
}

// 3.通过创建不同环境的 .env 文件，不同模式直接应用不同文件的环境变量
import.meta.env.VITE_URL

十一. Element-Plus集成

vue2：element ui、vant2
vue3：element-plus、vant3
react: ant design、material ui
Element Plus UI组件库
集成方案：
- 安装：https://element-plus.gitee.io/zh-CN/guide/installation.html
- 导入：https://element-plus.gitee.io/zh-CN/guide/quickstart.html

注意：
国内站点：https://element-plus.gitee.io/zh-CN/
el的组件的css变量名称和作用暂时还没有全被写入到组件文档中
所以目前暂时只能通过类，或者直接修改对应的css变量来修改
按照element-plus官方文档使用按需自动导入时，安装unplugin-vue-components 和 unplugin-auto-import这两款插件，并且在修改vite或webpack的配置之后，发现el组件没有正确的类型提示，文档中也没有说明怎么增加组件类型提示，只能我们手动添加前面两个插件所生成的文件名到tsconfig.json中的include中：
像ElMessage这类只能在js中使用的组件，是不会被自动导入的（包括其css），需要手动导入或使用别的方法
引入像ElMessage这类组件的css的话
手动引入
typescript
// 方式一：引入element-plus所有的样式
import 'element-plus/dist/index.css'

// 方式二：根据使用的组件进行按需引入
import 'element-plus/theme-chalk/el-message.css'
或者使用第三方插件帮助我们可按需导入组件库样式
typescript
npm i vite-plugin-style-import -D
                                                            
// vite.config.ts 中配置该插件
// 见官网地址：
// https://github.com/vbenjs/vite-plugin-style-import/blob/main/README.zh_CN.md
                                                            
// 如果打包过程中报错找不到consola模块，则还需要安装consola
npm i consola -D
自动导入插件只能导入在template中使用的组件
json
// tsconfig.json
{
  // ...
  "include": [
    "env.d.ts",
    "src/**/*",
    "src/**/*.vue",
+   "auto-imports.d.ts",
+   "components.d.ts"
  ]
}

十二. 别名（Alias）配置

为什么要配置别名

在 Vue3 + TS 项目中，导入路径很深时，代码可读性就会很差：

import MyComponent from '../../../components/MyComponent.vue'

通过配置路径别名（alias），可以简化为：

import MyComponent from '@/components/MyComponent.vue'

既能提升可读性，也方便在 IDE 中快速跳转和重构。

Vite 中配置别名

在项目根目录的 vite.config.ts 中，使用 resolve.alias：

vite.config.ts

import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
import path from 'path'
import { fileURLToPath, URL } from 'node:url'

export default defineConfig({
  plugins: [vue()],
  resolve: { 
    alias: {
      // ✅ 推荐写法
      '@': fileURLToPath(new URL('./src', import.meta.url))
    }
  }
})

TS 侧的同步配置

要让 TypeScript 也能识别 @ 路径别名，需在 tsconfig.json 或 tsconfig.app.json 中添加如下配置：

json

{
  "compilerOptions": { 
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"]
    }
  }
}

⚠️ 注意

"baseUrl": "." 是必须的，否则 paths 不生效。
"@/*": ["src/*"] 表示匹配目录下的所有子文件，而 "@": ["src"] 只匹配目录本身，无法访问子文件。

编辑器（WebStorm / VSCode）缓存与索引问题

修改完 tsconfig.json 或 vite.config.ts 后，如果 IDE 仍报红波浪线（找不到模块），通常是以下原因：

WebStorm / VSCode 缓存未刷新

IDE 在启动时会缓存路径映射表，如果你在运行期间修改了 paths 或 alias，IDE 不会立即重新索引。

解决办法：

WebStorm：菜单栏 → File → Invalidate Caches... → Invalidate and Restart
VSCode：执行命令面板 > TypeScript: Restart TS Server

Vite 服务已启动但 alias 未生效

Vite 仅在启动时解析配置文件（新版 vite 修改立即更新，较低版本的 vite 才有这个问题），修改 vite.config.ts 后需重启 dev 服务器：pnpm run dev，否则 Vite 使用的 alias 仍是旧缓存。

检查 tsconfig.json 多文件层级是否正确引用

部分项目结构中会有多个 tsconfig.*.json（如 tsconfig.app.json、tsconfig.node.json），确保主配置文件中有正确的 "extends" 与 "include"。

vite.config.ts 中常见的写法对比

写法	示例	可行性	原理
✅ 推荐写法（官方 Node ESM 方式）	`'@': fileURLToPath(new URL('./src', import.meta.url))`	✅✅✅	Node 官方推荐，在 ESM 模块下代替 `__dirname`，最通用安全。
✅ 基于路径解析	`'@': path.resolve(__dirname, './src')`	✅✅	适用于 CommonJS 模式（`vite.config.ts` 未强制 ESM），广泛兼容。
✅ 以 `/` 开头	`'@': '/src'`	✅	表示项目根目录下的绝对路径，Vite 会自动从根解析。
❌ 相对路径写法	`'@': './src'`	❌	实测无效。不会被识别为项目根目录

项目启动命令及路径解析逻辑

在 package.json 中的脚本：

json

{
  "scripts": {
    "dev": "vite",
    "build": "vue-tsc -b && vite build",
    "preview": "vite preview"
  }
}

当执行 pnpm run dev 时：

运行目录为项目根；
Vite 默认以项目根作为 root；
因此：
- /src ✅ 正确；
- ./src ❌ 不会被识别为项目根；
- path.resolve(__dirname, 'src') ✅ 正确；
- fileURLToPath(new URL('./src', import.meta.url)) ✅ 通用。

总结与建议

配置文件	推荐写法	原理	是否需重启
`vite.config.ts`	`'@': fileURLToPath(new URL('./src', import.meta.url))`	ESM 官方写法，最稳	✅ 重启 Vite
`tsconfig.json`	`"@/": ["src/"]`	TS 路径映射	✅ 重启 IDE
WebStorm 缓存	`Invalidate Caches / Restart`	重建索引	✅
VSCode 缓存	`TypeScript: Restart TS Server`	重载 TS 服务	✅

最佳实际配置模版（可直接用）

vite.config.ts

import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
import path from 'path'
import { fileURLToPath, URL } from 'node:url'

export default defineConfig({
  plugins: [vue()],
  resolve: { 
    alias: {
      // ✅ 推荐写法
      '@': fileURLToPath(new URL('./src', import.meta.url))
    }
  }
})

tsconfig.json 或 tsconfig.app.json

json

{
  "compilerOptions": { 
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"]
    }
  }
}

一. 项目介绍 – 后台管理系统 ​

二. 创建Vue项目 ​

三. 配置项目环境 ​

四. 配置项目代码规范 ​

1. 集成editorconfig配置 ​

2. 使用prettier工具 ​

3. 使用ESLint检测 ​

4. git Husky 和 eslint（后续） ​

5. git commit规范（后续） ​

5.1. 代码提交风格 ​

5.2. 代码提交验证 ​

五. 项目目录结构划分 ​

六. CSS样式的重置 ​

七. 全家桶 – 路由配置 ​

八. 全家桶 - 状态管理 ​

九. 网络请求封装axios ​

十. 区分 development 和 production 环境 ​

十一. Element-Plus集成 ​

十二. 别名（Alias）配置 ​

为什么要配置别名 ​

Vite 中配置别名 ​

TS 侧的同步配置 ​

编辑器（WebStorm / VSCode）缓存与索引问题 ​

vite.config.ts 中常见的写法对比 ​

项目启动命令及路径解析逻辑 ​

总结与建议 ​

最佳实际配置模版（可直接用） ​

一. 项目介绍 – 后台管理系统

二. 创建Vue项目

三. 配置项目环境

四. 配置项目代码规范

1. 集成editorconfig配置

2. 使用prettier工具

3. 使用ESLint检测

4. git Husky 和 eslint（后续）

5. git commit规范（后续）

5.1. 代码提交风格

5.2. 代码提交验证

五. 项目目录结构划分

六. CSS样式的重置

七. 全家桶 – 路由配置

八. 全家桶 - 状态管理

九. 网络请求封装axios

十. 区分 development 和 production 环境

十一. Element-Plus集成

十二. 别名（Alias）配置

为什么要配置别名

Vite 中配置别名

TS 侧的同步配置

编辑器（WebStorm / VSCode）缓存与索引问题

vite.config.ts 中常见的写法对比

项目启动命令及路径解析逻辑

总结与建议

最佳实际配置模版（可直接用）