学习分享，共勉

题外话，毕竟我工作多年，深知技术改革和创新的方向，Flutter作为跨平台开发技术、Flutter以其美观、快速、高效、开放等优势迅速俘获人心

开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

?juejin.im/post/684490…

2.5、统一脚手架

适用场景：有比较多独立中小项目。好处：

• 可以减少开发人员配置脚手架带来的时间损耗（特殊功能可以fork脚手架后再自行定制）；

• 统一项目结构，方便管理，也降低项目交接时带来的需要熟悉项目的时间；

• 方便统一技术栈，可以预先引入固定的组件库；

意义：

提高开发人员在多个项目之间的快速切换能力，提高项目可维护性，统一公司技术栈，避免因为环境不同导致奇怪的问题。

2.6、Node中间层

适用场景：需要SEO且前端使用React、vue，或前端介入后端逻辑，直接读取后端服务或者数据库的情况。

• SEO：仁者见仁智者见智，虽然很多公司已经不做了，但通常认为，还是有一定意义的（特别是需要搜索引擎引流的时候），因此React或者Vue的同构是必须的。并且同构还可以降低首页白屏时间；

• 前端读取后端服务/数据库：好处是提高前端的开发效率和对业务的支持能力，缺点是可能导致P0级故障。

意义：

让前端可以侵入后端领域，质的提升对业务的支持能力。

2.7、埋点系统

强烈推荐前端做自己的埋点系统。这个不同于后端的日志系统。

前端埋点系统的好处：

• 记录每个页面的访问量（日周月年的UV、PV）；

• 记录每个功能的使用量；

• 捕捉报错情况；

• 图表化显示，方便给其他部门展示；

埋点系统是前端高度介入业务，把握业务发展情况的一把利剑，通过这个系统，我们可以比后端更深刻的把握用户的习惯，以及给产品经理、运营等人员提供准确的数据依据。当有了数据后，前端人员就可以针对性的优化功能、布局、页面交互逻辑、用户使用流程。

埋点系统应和业务解耦，开发人员使用时注册，然后在项目中引入。然后在埋点系统里查看相关数据（例如以小时、日、周、月、年为周期查看）。

意义：

数据是money，数据是公司的生命线，数据是最好的武器。

2.8、监控和报警系统

监控和报警系统应基于埋点系统而建立，在如以下场景时触发：

• 当访问量有比较大的变化（比如日PV/UV只有之前20%以下）时，自动触发报警，发送邮件到相关人员邮箱；

• 比如报错量大幅度上升（比如200%或更高），则触发报警；

• 当一段时间内没有任何访问量（不符合之前的情况），则触发报警；

• 每过一段时间，自动汇总访问者/报错触发者的相关信息（例如系统、浏览器版本等）；

建设这个系统的好处在于，提前发现一些不容易发现的bug（需要埋点做的比较扎实）。有一些线上bug，因为用户环境特殊，导致无法被开发人员和测试人员发现。但其中一部分bug又因为不涉及资金，并不会导致资损（因此也不会被后端的监控系统所发现），这样的bug非常容易影响项目里某个链路的正常使用。

意义：

提高项目的稳定性，提高对业务的把控能力。降低bug数，降低资损的可能性，提前发现某些功能的bug（在工单到来之前）。

2.9、安全管理

前端的安全管理，通常要依赖于后端，至于只跟单纯有关系的例如dom.innerHTML= 'xxx '这种太基础，就不提了。

安全管理的很难从架构设计上完全避免，但还是有一定解决方案的，常见安全问题如下：

• XSS注入：对用户输入的内容，需要转码（大部分时候要server端来处理，偶尔也需要前端处理），禁止使用eval函数；

• https：这个显然是必须的，好处非常多；

• CSRF：要求server端加入CSRF的处理方法（至少在关键页面加入）；

意义：

减少安全漏洞，避免用户受到损失，避免遭遇恶意攻击，增加系统的稳定性和安全性。

2.10、Eslint

Eslint的好处很多，强烈推荐使用：

• 降低低级bug（例如拼写问题）出现的概率；

• 增加代码的可维护性，可阅读性；

• 硬性统一代码风格，团队协作起来时更轻松；

总的来说，eslint推荐直接配置到脚手架之中，对我们提高代码的可维护性的帮助会很大。可以考虑在上传到gitlab时，硬性要求eslint校验，通过的才允许上传。

意义：

提高代码的可维护性，降低团队协作的成本。

2.11、灰度发布

灰度发布是大型项目在发布时的常见方法，指在发布版本时，初始情况下，只允许小比例（比如1~5%比例的用户使用），若出现问题时，可以快速回滚使用老版本，适用于主链路和访问量极大的页面。

好处有以下几点：

• 生产环境比开发环境复杂，灰度发布时可以在生产环境小范围尝试观察新版本是否可以正常运行，即使出问题，也可以控制损失。

• 对于大版本更新，可以先灰度一部分，观察埋点效果和用户反馈（即所谓的抢先试用版）。假如效果并不好，那么回滚到老版本也可以及时止损；

• 当我们需要验证某些想法或问题的时候，可以先灰度一部分，快速验证效果如何，然后查漏补缺或者针对性优化；

灰度发布通常分为多个阶段：【1】1%；【2】510%；【3】3050%；【4】全量推送（100%）。灰度发布一定要允许配置某些IP/账号访问时，可以直接访问到灰度版本。

意义：

降低风险，提高发布灵活度。

2.12、前后端分离

这个并不是指常见的前后端分离，而是指在分配前后端管控的领域。

中小项目常见的情况是后端只提供接口和让某个url指向某个html，前端负责html、css、js等静态资源。

但大型项目并不建议这么做，建议前端负责除html以外的静态资源，而html交给后端处理，理由有很多：

• 后端进行渲染，方便统一插入一些代码和资源，例如埋点js，监控js，国际化文本资源，页面标识符等。这些通常是后端通过调用某些服务直接写入的；

• 当页面需要统一的头尾时（参考淘宝里我的淘宝页面），前端不应该关注这些跟当前页面无关的东西；

• 某些东西，如果通过html来管理，那么耦合度太高了，违背了解耦和分离的原则；

• 前端版本发布在后端引入某种功能模块后，可以从单独的页面控制前端发布内容，比更新html更方便，也利于灰度发布；

意义：

更规范的进行页面管理，降低页面和功能的耦合度，减少复杂页面的环境配置时间。

2.13、Mock

Mock也是常见前端系统之一，用于解决在后端接口未好时，生成返回的数据。

我个人不太建议开发一个专门的系统来Mock，更好的Mock手法是直接嵌入到脚手架之中。思路如下：

• 当在开发环境下，访问链接通常是localhost:8000/index.html，此时加入后缀 ?debug=true；

• 封装好的异步请求在发现当前链接有以上标志时，认为是测试环境，访问/userinfo 时，不去读取线上的数据（因为也读取不到），去本地环境读取 src/test_ajax/userinfo.json，并将内容返回给用户；

• 异步请求正常拿到数据，在页面中显示；

• 当线上接口可以获取到数据后，从network里找到返回的数据，放入/ src/test_ajax/userinfo.json中，此时再次本地调试的话，相当于使用的是线上的真实数据。

这种处理，可以降低mock的复杂度，随时更改mock时返回的数据，比单独开发一个mock系统性价比更高。

意义：

在前后端并行开发时，降低沟通交流成本，方便开发完毕后直接对接。

2.14、定期备份

备份是常被忽略的一件事情，但当我们遇见毁灭性场景时，缺少备份带来的损失是非常大的，常见场景：

• 服务器损坏，导致存在该服务器上的内容全部完蛋；

• 触发某致命bug或者错误操作（例如rm -f），导致文件和数据全部消失；

• 数据库出现错误操作或出现问题，导致用户数据、公司资产遭受严重损失；

总的来说，没人想遇见这样的场景，但我们必须考虑这种极端情况的发生，因此需要从架构层面解决这个问题。常见方法是定期备份、多机备份、容灾系统建设等。

意义：

避免在遭遇极端场景时，给公司带来不可估量的损失。

3、应用层设计

---

3.1、多页和单页

除了特殊场景，通常推荐使用多页架构。理由如下：

• 多页项目，页面和页面之间是独立的，不存在交互，因此当一个页面需要单独重构时，不会影响其他页面，对于有长期历史的项目来说，可维护性、可重构性要高很多；

• 多页项目的缺点是不同页面切换时，会有一个白屏时间，但通常来说，这个时间并不长，大部分现有大公司的线上网页，都是这样的，因此认为是可以接受的；

• 多页项目可以单次只更新一个页面的版本，而单页项目如果其中一个功能模块要更新（特别是公共组件更新），很容易让所有页面都需要更新版本；

• 多页项目的版本控制更简单，如果需要页面拆分，调整部分页面的使用流程，难度也会更低；

• 灰度发布更友好；

之前面试的一家，采用了单页的形式，之前因为种种原因，同时采用了ng和react。由于项目历史也比较久（3年以上），结果导致目前继续维护更新的难度很大，即使想部分重构，也很麻烦。

意义：

降低长期项目迭代维护的难度，

3.2、以应用为单位划分前端项目

在项目比较大的时候，将所有页面的前端文件放入到同一个代码仓库里，我之前参与过一家企业的前端项目开发，发现其就是这么做的。根据使用经验来看，存在很多问题：

• 会极大的增加代码的维护难度；

• 项目会变得很丑陋；

• 不方便权限管理，容易造成页面误更改或代码泄密；

• 任何人都有权利改任何他能看到的页面（在合并代码的时候，管理人员并不能确定他本次修改的页面是否是需求里他应该改的页面）；

• 发布成本高，即使改一个页面，也需要发布所有资源；

因此，我们应该避免这种现象的发生，个人推荐以应用为单位进行开发、发布。所谓应用即指一个业务涉及到的前后端代码，好处很多：

• 方便进行管理，当某个业务有需求变更时，可以只给研发人员该业务前端应用的developer权限；

• 在需要发布某业务时，只需要发布该业务的所属应用即可；

意义：

规范项目，增加代码的安全性，降低项目维护成本。

3.3、基础组件库的建设

这个蛮基础的，对于组件库的建设，不建议研发人员较少时去做这件事情，专职前端开发人数少于10人时，建议使用比较靠谱的第三方UI库，例如Antd，这样性价比更高。

设计基础组件库的前提，是要求统一技术栈，这样才能最大化基础组件库的效益。组件库建议以使用以下参考标准：

• 使用ts；

• 可扩展性强；

• 适用程度高；

• 文档清楚详细；

• 版本隔离，小版本优化加功能，大改需要大版本更新；

• 和UI协调统一，要求UI交互参与进来；

总的来说，建设起来后，利大于弊，但是需要专人维护，因此还是有一定成本的。

意义：

统一不同/相同产品线之间的风格，给用户更好的体验，减少单次开发中写UI组件时浪费的时间和人力，提高开发效率。

3.4、技术栈统一

前端有三大主流框架，还有兼容性最强jQuery，以及各种第三方库，UI框架。因此项目需求如果复杂一些，很容易形成一个大杂烩。因此前端的技术栈必须统一，具体来说，建议实现以下举措：

• 三大框架选型其一，团队水平一般推荐Vue、水平较好推荐React，对外项目选React或者ng；

• 需要兼容IE8或更老版本时，建议使用jQuery；

• 组件库自建或者统一选择一个固定的第三方；

• 一些特殊第三方库统一使用一个版本，例如需要使用地图时，固定使用高德或百度或腾讯地图；

• 基础设施建设应避免重复造轮子，所有团队尽量共用，并有专门的前端平_台负责统一这些东西，对于特殊需求，可以新建，但应当有说服力；

总的来说，技术栈统一的好处很多，可以有效提高开发效率，降低重复造轮子产生的成本。

意义：

方便招人，简化团队成员培养成本，以及提高项目的可持续性。

3.5、浏览器兼容

常见的问题是IE6、7、8，以及部分小众浏览器（PC和手机）产生的奇怪问题。因此应该考虑统一解决方案，避免bug的重复产生。常见解决方案有：

• 配置postcss，让某些css增加兼容性前缀；

• 写一个wepback的loader，处理某些特殊场景；

• 规范团队代码，使用更稳定的写法（例如移动端避免使用fixed进行布局）；

• 对常见问题、疑难问题，总结解决方案并团队共享；

• 建议或引导用户使用高版本浏览器（比如chrome）；

意义：

避免浏览器环境产生的bug，以及排查此类bug所浪费的大量时间。

3.6、内容平_台建设

为了提高公司内部的沟通效率，总结经验，以及保密原因。应建设一个内部论坛+博客站点。其具备的好处如下：

• 可以记录公司的历史；

• 研发同学之间分享经验；

• 总结转载一些外界比较精品的文章，提高大家的眼界；

• 增加公司内部同学的交流，有利于公司的团队和文化建设；

• 对某些技术问题可以进行讨论，减少因没有达成共识带来的沟通损耗；

众所周知，大型互联网公司通常都有这样一个内部论坛和博客站点。其降低了公司的沟通和交流成本，也增加了公司的技术积累。

意义：

博客增强技术积累，论坛增强公司内部沟通能力。

3.7、权限管理平_台

当公司内部人员较多时，应有一个专门的平_台，来管理、规范用户的权限以及可访问内容。权限管理平_台有几个特点：

• 必然和Server端天然高耦合度，因此需要有专门的控制模块负责处理权限问题（负责Server端开发处理，或者前端通过中间层例如Node层介入处理）；

• 自动化流程控制，即用户创建、申请、审批、离职自动删除，都应该是由系统推进并提醒相关人士，必要时应能触发报警；

• 权限应有时效性，减少永久性权限的产生；

最后

---

开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

大厂面试问深度，小厂面试问广度，如果有同学想进大厂深造一定要有一个方向精通的惊艳到面试官，还要平时遇到问题后思考一下问题的本质，找方法解决是一个方面，看到问题本质是另一个方面。还有大家一定要有目标，我在很久之前就想着以后一定要去大厂，然后默默努力，每天看一些大佬们的文章，总是觉得只有再学深入一点才有机会，所以才有恒心一直学下去。

员较多时，应有一个专门的平_台，来管理、规范用户的权限以及可访问内容。权限管理平_台有几个特点：

• 必然和Server端天然高耦合度，因此需要有专门的控制模块负责处理权限问题（负责Server端开发处理，或者前端通过中间层例如Node层介入处理）；

• 自动化流程控制，即用户创建、申请、审批、离职自动删除，都应该是由系统推进并提醒相关人士，必要时应能触发报警；

• 权限应有时效性，减少永久性权限的产生；

最后

---

开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

大厂面试问深度，小厂面试问广度，如果有同学想进大厂深造一定要有一个方向精通的惊艳到面试官，还要平时遇到问题后思考一下问题的本质，找方法解决是一个方面，看到问题本质是另一个方面。还有大家一定要有目标，我在很久之前就想着以后一定要去大厂，然后默默努力，每天看一些大佬们的文章，总是觉得只有再学深入一点才有机会，所以才有恒心一直学下去。