前端基建 指的是业务团队内的前端工程师执行的一些基础建设，包括了 前端规范文档、前端脚手架、前端模板、前端组件库、前端工具库、前端BFF、前端CI/CD的构建部署、前端数据埋点 等等；
前端基建 仅服务于前端团队；
------------------------------------------------------------------------装载☞易师傅前端基建
1.前端规范
1).命名规范
### 1.类命名是名词，表示一个对象，采用大驼峰命名法：class Account
### 2.方法命名是动词或动宾短语，表示一个动作，采用小驼峰命名法：function translateArticle()
### 3.变量命名，采用小驼峰命名法：userName
### 4.常量命名，采用大写蛇形命名法：MAX_NUM
### 5.文件模块命名是名词，采用小驼峰命名法：exportExcel.js
### 6.组件命名是名词，采用大驼峰命名法：UserHome.vue（index.vue除外）
### 7.css类命名采用串行命名法：.header-logo
### 8.图片命名采用串行命名法：add-plus.png
### 9.目录命名采用串行命名法：user-list
### 10.路由路径命名小驼峰命名法：/pay/payInfo
### 11.项目命名采用串行命名法：flow-portal
2).目录规范（个人习惯）
config 项目所有的在运行前的配置中心
index.js 项目公共前缀，路由前缀，项目名称等等
dist 打包后目录（前端这些年约定俗成了）
public 不会被打包的目录，一个是webpack默认路径，另一个是大家都这么干
config(项目如果是外部js全局变量控制环境)
img（不被打包的静态图片）
js（不被打包的静态js）
index.html webpack入口html文件
src 源码目录
assets 静态文件目录，一般放图片
img
js（不需要被打包的不要放这里，放在外层的public下面）
businessComponents 业务组件
Menu(菜单组件)
list.js（菜单组合路由）
layout 页面上全局布局组件，比如路由嵌套的部分
One.vue（组件）
Two(文件夹)
index.vue
index.js 需要全局注册的统一出口
README.md（组件太多需要说明文件）
components 和业务无关的组件
AntDesgin.js(组件库入口)
Element.js（组件库入口）
index.js 需要全局导入和注册的统一出口
README.md（组件太多需要说明文件）
mixin 全局mixin部分，非全局部分的mixin不建议使用。容易引起代码混乱
pages 路由相关页面部分，原本大家用的是views
Home 首页
index.vue
Page2
ComTwo 页面组件更加复杂了
ComThree.vue 子组件的组件
index.vue 页面组件入口
ComOne.vue 页面组件
index.vue 页面组件入口
404.vue
power 项目业务上的权限管理中心
router 路由部分（不建议把菜单管理也放这里）
before.js(路由守卫js，名称随意，清晰明确即可)
index.js
service 接口管理中心
index.js
store 数据中心,不在和业务有关，主要是为了配置缓存使用
index.js
theme 主题样式中心，所有全局的css都在这里
index.css(scss,less) 保证你的输出是一个出口
tool（utils） 工具函数中心
App.vue 初始模板
CreateApp.js main.js里面会存在很多业务上的逻辑，那么这里封装下
main.js
.browserslistrc
.eslintrc.js eslint配置
.gitignore
babel.config.js babel配置
package.json
prettier.config.js prettier配置
README.md 项目初始约定，规范书写中心
vue.config.js vue打包配置中心，webpack等修改也在这里
3).编码规范
推荐安装插件
1.1 Prettier
它通过解析代码并使用自己的规则重新打印它，并考虑最大行长来强制执行一致的样式，并在必要时包装代码。如今，它已成为解决所有代码格式问题的优选方案；支持 JavaScript、Flow、 TypeScript、 CSS、 SCSS、 Less、 JSX、 Vue、 GraphQL、 JSON、 Markdown 等语言.这里我们需要让Prettier和Eslint结合，检测代码中潜在问题的同时，还能统一团队代码风格，从而促使写出高质量代码，来提升工作效率。我们要的不仅是检测问题，还有就是自动修复问题。
1.2 ESLint
ESLint最初是由Nicholas C. Zakas 于2013年6月创建的开源项目。它的目标是提供一个插件化的javascript代码检测工具。更详尽的参考ESlint中文网
4).git规范
一、分支分类
Git主分支（保留分支）：master、dev
主要分支：Master和Dev。前者用于正式发布，后者用于日常开发。
Git辅助分支（临时分支）：feature、release、fix
除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有三种：
功能（feature）分支
预发布（release）分支
修补bug（fixbug）分支
这三种分支都属于临时性需要，使用完以后，应该立即删除，只留下Master和Dev。
命名格式: 类别 + / + 日期/迭代版本号/功能名称
例： feat/2.1.1、fix/20201214
一些比较复杂的系统，需要子系统迭代的，就会用到功能名称，例：
feat/user_manage_1.1.1、fix/user_manage_20201214
二、提交信息
常见的分类有下面几种：
build：修改项目的的构建系统（xcodebuild、webpack、glup等）的提交
ci：修改项目的持续集成流程（Kenkins、Travis等）的提交
chore：构建过程或辅助工具的变化
docs：文档提交（documents）
feat：新增功能（feature）
fix：修复 bug
pref：性能、体验相关的提交
refactor：代码重构
revert：回滚某个更早的提交
release：发布新版本
style：不影响程序逻辑的代码修改、主要是样式方面的优化、修改
test：测试相关的开发
improvement：在现有功能上优化、改进
提交格式: 分类：具体描述信息（建议中文）
2.前端文档
大体从这几个方面着手
# 项目立项
### 项目背景
### 业务需求
### 代码规范
### 设计思路
# 概要设计
### 业务区分
### 公共组件
### 通用代码
#### Api
#### Store
#### Util
#### Scss
# 开发中间区
### 项目配置信息
### 模块设计思路
### 运行流程图
### webpack配置信息详解
### 代码运行思想
# 项目部署
### Git 配置信息
### 项目发布流程
# 开发日志
# 项目总结
3.模板与脚手架
vue3-admin-template
等等，github上有很多优秀模板
4.前端组件库&&工具类库
组件库：
Element UI
vuetify
Ant Design
Bottstrap
layui
Vant UI
Framework7
WEUI
工具类库
lodash
Moment
Day
Numeral
js-cookie
| 依赖库 | 名称 |
|---|---|
| cropperjs | 图片裁剪 |
| exif-js、lrz | 图片旋转问题 |
| html2canvas | dom转图片 |
| nprogress | 路由进度条 |
| v-viewer | 图片放大多功能 |
| caret-pos | 偏移量 |
等等
5.响应式设计
1）.vw 和 vh vw表示相对于视图窗口的宽度，vh表示相对于视图窗口高度，除了vw和vh外，还有vmin和vmax两个相关的单位。各个单位具体的含义如下：
单位 含义 vw 相对于视窗的宽度，1vw 等于视口宽度的1%，即视窗宽度是100vw vh 相对于视窗的高度，1vh 等于视口高度的1%，即视窗高度是100vh vmin vw和vh中的较小值 vmax vw和vh中的较大值
blog.csdn.net/weixin_5376… （# 关于将px转换为vw vh的解决方案）
2）. 百分比布局
百分比是相对于 包含块 的计量单位，通过对属性设置百分比来适应不同的屏幕
-
有父元素相对于父元素
-
无父元素相对于视口
-
或者继承于父元素
3）.rem布局 rem（font size of the root element）是指相对于根元素的字体大小的单位，rem只是一个相对单位
4）.媒体查询
@media screen and (min-width: 1200px) {
html {
font-size: 20px;
}
}
@media screen and (max-width: 1200px) {
html {
font-size: 10px;
}
5）.flex布局
6.前端自动化构建部署
CICD 简介并使用 Github Actions 自动部署单页应用
在前边的篇章中，我们在服务器中搭建了 Traefik 网关，并使用 docker-compose 部署前端并发布成功。
但前边的部署流程都是基于手动部署，那我们如何将部署进行自动化:
即每当我们将前端代码更新并 PUSH 到仓库后，CICD 将会拉取仓库代码并自动部署到服务器。
这就是 CICD 要做的事情。
CI，Continuous Integration，持续集成。CD，Continuous Deployment，持续部署。(或者 Continuous Delivery，持续交付)
CICD 与 git 集成在一起，可理解为服务器端的 git hooks: 当代码 push 到远程仓库后，对当前代码在构建服务器(即 CI 服务器，也称作 Runner)中进行自动构建、测试及部署等。
为了方便理解，我们将上篇文章中用于部署的服务器称为部署服务器，而 CI 中所指的服务器，称为构建服务器。
- 部署服务器: 对外提供服务的服务器，容器在该服务器中构建并启动。
- 构建服务器: 进行CI构建的服务器，一般用以构建、测试和部署，构建镜像以及自动部署服务。一般也可以是 Docker 容器。
在以前的篇章中，相当于构建服务器和部署服务器为同一个服务器，而在工作中，二者往往为独立服务器。
但是为了更好的 CICD，构建服务器会赋予控制部署服务集群的权限，在构建服务器中通过一条命令，即可将某个服务在部署服务器集群中进行部署。
在 CICD 中，构建服务器往往会做以下工作，这也是接下来几篇篇章的内容:
- 功能分支提交后，通过 CICD 进行自动化测试、语法检查、npm 库风险审计等前端质量保障工程，如未通过 CICD，则无法 Code Review，更无法合并到生产环境分支进行上线
- 功能分支提交后，通过 CICD 对当前分支代码构建独立镜像，并生成独立的分支环境地址进行测试。如对每一个功能分支生成一个可供测试的地址，一般是
<branch>.dev.shanyue.tech此种地址 - 功能分支测试通过后，合并到主分支，自动构建镜像并部署到生成环境中 (一般生成环境需要手动触发、自动部署)
如下图，当所有 Checks 通过后，Merge pull request 才会变绿允许进行合并。
由于近些年来 CICD 的全面介入，项目开发的工作流就是 CICD 的工作流，请看一个比较完善的 CICD Workflow。
- CI: 切出功能分支，进行新特性开发。此时为图中的
Verify、Package阶段 - CD: 合并功能分支，进行自动化部署。此时为图中的
Release阶段。
#CICD 工具与产品
- Gitlab CI
- Github Actions
- Jenkins(opens new window)
国内公司一般以 gitlab CI 作为 CICD 工具，此时需要自建 Gitlab Runner 作为构建服务器。
7.前端埋点（数据异常监控）
前端监控/数据埋点的目的是：
- 实现精准的点对点营销；
- 可以做相关的分类统计；
- 为用户画像的构建提供数据支持；
- 指导产品研发以及优化用户体验；
前端监控/数据埋点有哪些数据？
行为数据：时间、地点、人物、交互、交互的内容；质量数据：浏览器加载情况、错误异常等；环境数据：浏览器相关的元数据以及地理、运营商等；运营数据：PV、UV、转化率、留存率（很直观的数据）；
[UV]
是指通过互联网访问、浏览这个网页的自然人。访问您网站的一台电脑客户端为一个访客。00:00-24:00内相同的客户端只被计算一次。一天内同个访客多次访问仅计算一个UV。
IP（Internet Protocol）
独立IP是指访问过某站点的IP总数，以用户的IP地址作为统计依据。00:00-24:00内相同IP地址之被计算一次。
UV与IP区别
如：你和你的家人用各自的账号在同一台电脑上登录新浪微博，则
IP数+1，UV数+2。由于使用的是同一台电脑，所以IP不变，但使用的不同账号，所以UV+2
PV（Page View）
即页面浏览量或点击量，用户每1次对网站中的每个网页访问均被记录1个PV。用户对同一页面的多次访问，访问量累计，用以衡量网站用户访问的网页数量。
VV（Visit View）
用以统计所有访客1天内访问网站的次数。当访客完成所有浏览并最终关掉该网站的所有页面时便完成了一次访问，同一访客1天内可能有多次访问行为，访问次数累计。
PV与VV区别
如：你今天10点钟打开了百度，访问了它的三个页面；11点钟又打开了百度，访问了它的两个页面，则PV数+5，VV数+2.PV是指页面的浏览次数，VV是指你访问网站的次数。
埋点分类
代码埋点
通过代码的方式在页面中嵌入逻辑，比如捕获一个点击事件，在这个点击事件之前加入代码埋点⛑,上报给后台🥐。国内已经有很多成型的服务商了如友盟，百度统计等🌯，都提供了比较成型的方案，并可以在后台管理系统中查看比较详细的数据分析🧵，但是肯定会有领导想要把这些事情掌握在自己的手中，我们就只能通过自身开发来实现代码埋点。
- 优点：
- 控制精准，可以非常精确地选择什么时候发送数据。
- 传递多样化自定义属性、自定义事件，传递比较丰富的数据到服务端。
- 缺点：
- 埋点代价比较大，每一个控件的埋点都需要添加相应的代码，不仅工作量大，必须是技术人员才能完成。
- 更新的代价比较大，每一次更新埋点方案，都必须改代码。
可视化埋点
个人理解的可视化埋点应该是肯定需要第三方的服务商支持，不会有做专门业务的公司去做可视化埋点的解决方案。可视化埋点开发人员除集成采集可视化SDK 外，不需要额外去写埋点代码，而是由业务人员或运营人员通过访问分析平台的圈选功能🤔，来“圈”出需要对用户行为进行捕捉的控件，并给出事件命名🚘。圈选完毕后，这些配置会同步到各个用户的终端上😮，由采集SDK按照圈选的配置自动进行用户行为数据的采集和发送。
优点：
- 埋点代价小，更新代价小
- 埋点只需业务同学接入，开发只需对接可视化
SDK
缺点：
- 无法做到自定义获取数据
- 可视化埋点覆盖的功能有限
- 仅支持客户端行为
无痕埋点
无痕埋点又叫全埋点🥪，网上又很多文章写的都是无痕埋点是将所有事件的操作全部上报😀，但是我们在实现的过程中肯定是不会监听那么多的事件吧，但是好像也有第三方服务商sdk集成了所有事件。
优点：
- 由于采集的是全量数据，所以产品迭代过程中是不需要关注埋点逻辑的，也不会出现漏埋、误埋等现象。
- 无埋点方式因为收集的是全量数据，可以大大减少运营和产品的试错成本
- 如果集成sdk之后无需埋点，方便快捷
缺点：
- 缺点与可视化埋点相同，未解决个性化自定义获取数据的问题，缺乏数据获取的灵活性；
- 数据量过大，如果不使用第三方服务商，针对自身的服务器是个考验
举例：【 1.通过自定义指令存储点击量 2.使用路由拦截统计页面级别的 PV 3.第三方统计工具，如友盟、神策、Talkingdata、GrowingIO等 】
8.性能优化 借用大佬的图
这个基本上可以概括优化的各方面
