1:前端框架选择
业务适用性：（需要充分理解业务，用户需求，当下需要解决的首要问题，后面的风险。目标分解后进行具体的技术选型、模型设计、架构设计）
- React适用于构建大型、复杂的单页应用，toB管理系统等
- Vue2 options API 适用于中小型的单页应用。Vue3 composition API 和TS的支持也可以开发大型项目，toC移动端应用等
团队适用性
- 新建项目时，对比技术生态，还
要考虑团队开发成员对技术栈的熟悉程度。选择大多数人都熟悉的技术栈，有助于提升项目产出效率和质量。 - 收益：是否能解决当前的某些痛点
- 考虑风险：不能将一个实验阶段的技术使用在生产环境中
跨端处理
- APP开发，使用ReactNative
- 小程序：Vue+uni-app
兼容性
- PC端：Vue3放弃对IE的支持，React和Vue2都不支持IE8以下的浏览器版本
- H5端：React没什么兼容问题，Vue3响应式底层使用Proxy实现，在IOS端最低支持0版本
从0搭建前端项目一
- 技术栈：Vue3.0 + Vite + TypeScript + Element Plus + Vue Router + axios + Pinia
- 规范化：Eslint + Airbnb JavaScript Style
- 提交代码规范：husky + lint-staged
- 包管理：yarn
架构设计
定义
前端架构设计指设计一系列相关的抽象模式（工具和流程的集合），用于指导完成前端项目各个方面的工作
目的
解决已存在或未来可能发生的技术问题，增加前端项目的可管理性、稳定性、可扩展性。提升开发效率、提升产品质量、降低开发难度、降低费用成本的目的。
原则
- 合适原则：做架构设计时应该从实际场景出发
- 简单原则：用最简单的方案解决问题
- 演化原则：架构设计应满足当前的业务需要，还能够应变后续架构升级和调整、变化的需要
工程化
统一规范（无规矩不成方圆）
严格按照Vue开发风格指南执行
- 项目组织规范：
- package.json：描述当前的版本、包名、依赖、环境约束、项目配置等
- dist：项目构建结果输出目录。api/component/store/router/component/mock
- 代码规范
- Eslint：（规范制定和检查）
- Prettier:格式化代码
- VSCode:插件
Eslint与Prettier冲突
安装两个插件：eslint-config-prettier、eslint-plugin-prettier
- eslint-config-prettier:作用是关闭eslint与prettier相互冲突的规则
- eslint-plugin-prettier：作用是赋予eslint用prettier格式化代码的能力。
开发/测试
开发阶段
- 脚手架：创建前端应用的目录结构，生成样板代码
- 公共库：可复用的、维护状态的UI组件、工具模块等公共资源
- 包管理器：引用第三方库/组件，后续可以跟踪管理依赖
- 编辑器：提供语法高亮、智能提示、引用跳转等功能，提升开发体验
- 构建工具：提供语法校验、编译、打包、DevServer等功能，简化工作流
- 调试套件：提供预览、DevTools、Mock、性能分析等调试功能
测试阶段
- 单元测试框架：提供针对组件、逻辑的测试支持
- 静态扫描工具：代码质量、构建产物质量、最佳实践、开发规约等做静态检查
- 自动化测试工具：针对UI效果和业务流程，提供测试支持
- 性能测试工具：监测、统计相对准确的性能数据
构建/部署
前端项目构建，其实就是在做依赖打包、文件压缩、代码分割、增量更新与缓存、资源定位、图片处理、 ECMAScript 与 Babel 、 CSS 预编译与 PostCSS 、持续构建和集成、类库打包、构建优化、SSR极限优化等等工作。
部署
在部署过程中，要考虑目标服务器、路径信息是否与项目一一对应，并且可供负责部署到生产环境的开发人员进行配置，部署的操作流程应尽量简单。
考虑团队协作和安全方面的因素，最佳的方式应该是搭建一个可供严格审查、队列控制、操作简化的部署平台，并且有专人负责掌握流程进度
监控
Web 监控平台闭环：采集 - 上报 - 解析 - 计算 - 多维分析 - 实时预警。
-
页面的性能情况：包括各阶段加载耗时，一些关键性的用户体验指标等
-
用户的行为情况：包括PV、UV、访问来路，路由跳转等
-
接口的调用情况：通过http访问的外部接口的成功率、耗时情况等
-
页面的稳定情况：各种前端异常等
-
数据上报及优化：如何将监控捕获到的数据优雅的上报
架构思想
-
了解业务：全面调研当前业务和竞品的现状，充分理解当前渲染链路和节点，确认当前存在的问题
-
寻找方案：预估未来发展的方向，尽可能多的了解相关解决方案或创新自己的方案，比如：SSR，ER，预渲染，预加载，静态化等
-
评估方案：和相关同学讨论或开会，评估所有可行的方案及其合适度、复杂度、前瞻性和 ROI。选出至少一个候选方案，比如：SSR
-
Demo 开发：基于现有开发能力为所有候选方案开发对应 Demo，提前探路并验证风险和可行性，帮助产出更合适的方案设计
-
方案设计：梳理清楚 SSR 完整链路上相关节点和合作方，多写、多画、多思考、多讨论相关架构和设计，深入细节产出 RFC 文档
-
RFC 评审：充分评审设计、实现和产物细节，可多次评审直至所有成员达成共识。确定相关开发和团队分工，保证方案完善可执行
-
落到实处：推进项目开发，多与开发团队沟通，并至少参与一部分编码工作，打通所有相关开发和运维链路，保障产物简单好用
-
沉淀传承：沉淀文档，通过会议、分享或文章帮助其他人理解 SSR 方案和架构，用好 SSR。做好答疑，并推动方案实施
-
不断演进：关注 SSR 的发展，演进已有链路，比如，个性化的 SSR，结合 ER 的 SSR 等
前端工程化服务
前端代码Review
- 代码质量：代码是否简洁、易读、易维护，是否编码风格和规范一致
- 功能实现：代码是否实现预期功能，是否有潜在的bug或逻辑错误
- 性能优化：代码是否进行必要的性能优化
- 大量的网络请求：使用缓存、懒加载、预加载方式解决
- 大型JS文件：代码分割、懒加载减少文件大小
- 阻塞渲染的CSS和JS文件：使用异步加载、延迟加载解决
- 安全性：代码是否存在可能的安全风险
- 跨站脚本攻击：是否对用户输入进行转义（vue中的v-html）
- 跨站请求伪造：是否所有的post请求使用CSRF令牌，防止攻击者伪造用户请求
- 点击劫持：是否使用适当的HTTP头，如X-Frame-Options
- 输入验证、敏感信息泄漏：是否在客户端和服务端进行输入验证，图形、验证码加入随机真人校验机制
- 依赖的安全性：第三方依赖是否有安全漏洞
- 可读性：代码是否易于理解，是否有足够的注释和文档、TS类型声明、变量、函数、类、文件的语义化命名
- 可复用性：代码是否有高度的模块化和复用性（封装为函数、组件、类、指令、模块）
- 兼容性：代码是否兼容不同的浏览器和设备
- 浏览器兼容性：是否支持不同的浏览器（某些浏览器可能不支持的JS特性和CSS属性）
- 设备兼容性、响应式设计：是否支持所有设备，不同的操作系统、屏幕大小、分辨率等
- 国际化和本地化，是否支持多种语言和地区（正确使用日期、时间、数字的格式）
前后端协作规范
- 需求分析。参与者有前后端、测试、产品、项目，对需求宣贯，开发和测试的反馈，确保大家对需求有一致的认知
- 前后端开发讨论，讨论应用的一些开发设计，沟通技术点、难点、分工问题。
- 设计接口文档。前后端一起设计，确保符合要求
- 并行开发。前后端并行开发，后端提供接口文档对接口进行mock，模拟对接后端接口
- 联调之前，要求后端做好接口测试
- 真实环境联调。
接口规范
- RESTful：API设计规范，基于HTTP本身的机制实现
- 接口文档规范：方法名称、URL，请求参数，响应参数，异常情况、错误代码
