作为一个架构师，第一要义是对业务滚瓜烂熟，第二要义是对技术深度理解和广泛涉猎。而其灵魂就是把简单的需求想复杂、再把复杂的需求简单化。
对业务滚瓜烂熟才能把简单想到复杂，只有想到了复杂才能做好拓展性，也许当前不做但是未来会做，那么未来会做就要留着能支持未来的拓展性。
而把复杂简单化，举例：我们封装一个复杂的多场景通用组件，不可避免代码逻辑复杂，阅读性差，但是这不影响你把它封装得简单易用。以最复杂的方式封装，以最简单的方式调用。
而具体到实践中：四个要义，通用、易用、可拓展、高性能，一个终极之安全性，一个奥义之合规
通用
是否需要通用？何谓通用？如何通用？
- 并不是所有东西都需要通用，你一定要清楚，它是否需要通用，我一贯的判断：超过三个场景下同样的需求就应当通用
- 而通用的理解就是字面理解，大家都能用，到处都能用，其他项目也能用就是通用。
- 如何通用呢？不同的需求有不同的实现，但万变不离其宗，就是封装然后全局化。例如：
1、axios全局封装（通用api）
2、vuex全局封装（通用数据和状态）
3、utils全局工具（通用工具和方法）
4、css全局控制（通用颜色，字体，大小，高宽等等）
5、assts全局静态文件（通用图片和icon文件）
6、directive全局指令（例如权限管理等全局指令）
7、eslint全局代码规范（统一的代码规范和格式化规则）
8、通用的开发文档、流程、手册、注释规则等。
易用
易用也就是字面理解，简单好用。我很讨厌一个项目封装得乱七八糟，除了架构师其他人谁来都很难上手。一个好的架构可以在精简和易用中做抉择选择易用。兴许你这么封装是可以减少很多代码，但是你这么封装如果绕来绕去很难理解，就不建议你这么干，这会得不偿失。
- 1、composition Api，Vue3也好、React也好，都在强调这个概念。
- 2、善用全局注册替代局部调用
a\this.$utils注册全局工具代替局部导入工具
b\this.$axios注册全局数据请求代替局部导入请求
c\filter全局注册，filter有时候很鸡肋，但有时候很好用
d\directive全局注册
e\components通用组件全局注册 - 3、最高级的也是学不来的，那就是脑子。兴许同样一个人封装同样一个功能的组件，这个人的用起来只需要一个参数一个方法回调就能用，而另一个需要N个参数好几个方法才能满足需求。这个我没法说，多看大佬封装的组件，多看看现在流行的UI框架的源码。
可拓展
可拓展是一个很玄乎的东西！如何算一个可拓展的架构呢？可能每个人都理解得不一样，实际中是否真的具备可拓展性，也很难说！只能谈谈个人理解。
- 1、TypeScript，他可以让我们的代码更严谨，更严谨的代码更具有拓展性。如今很多框架底层都已经是TS了，这就是最有力的证据，没有一个框架不考虑拓展性。
- 2、结合义务的拓展性，吃透业务后往往就能想到当前业务的缺陷，那么针对这个缺陷留下一个打补丁的口子，就是赋予了其拓展性。举个例子，当前的选择控件翻页后不记住上页选择，那么以后很可能需要记住。我们设计的时候就可以把选中数据单独存放和处理，和渲染数据分开，这就是留住了口子。
高性能
大多数人都能按照流程创建一个前端项目，但是大多数人创建的项目随着项目日渐充实就会出现严重的性能问题。所以光能搭建一个项目并不是一个架构师，能搭建一个庞大的项目还能高速运转才算一个入门级架构师。
- 关于前端性能：可以上谷歌浏览器自带的灯塔上做测试个针对性改进。从几个方面出发。
1、渲染速度
2、是否流畅没有卡顿
3、首屏加载速度
4、用户体验 - 具体到性能优化
1、图片压缩
2、代码性能考核
3、webpack极致优化
4、cdn部署
5、减少服务器请求
架构之终极——安全性
关于安全性，更多是后端架构所看重的，但前端一样不能忽视。你的项目可以慢，可以不好用，可以不好维护，但是不可以有很大的安全漏洞。因为前面的只是阻碍你的前进脚步，而安全性却能决定你的生死。
架构之奥义——合规
很多人肯定不知道这个合规的含量有多重，因为大多数项目还没到政府去管控监视的地位。一万个项目里甚至都不会出一个！但是如果你是这万一的一，你不合规，就一定会被为此付出代价。
- 具体到合规，需要注意的东西太多，可以网上查资料。每个端的项目规则还不尽相同。