背景
静态资源和动态资源是很常见的技术的名词，但背后的逻辑你是否清楚，让我们一起review一下。
1. 静态资源和动态资源分别是什么？
首先静态资源和动态资源都是服务端这边的概念，因为我们访问互联网本质都是访问对应的服务端
对于服务端来说：
- 静态资源是：提前准备好的，写死了的，直接文件IO就可以response的属于静态资源。
- 动态资源是：不是写死的，需要读库的 或 需要调下游接口的 或 需要脚本处理的属于动态资源
前端角度看哪些是静态资源？
- 通过前端工程npm run build编译好的js、css、html文件，都属于静态资源
- 提前准备好的文件（比如自己开发的源代码），都属于静态资源
- 图片、视频等资源文件，都属于静态资源
前端角度看哪些是动态资源？
- 需要调接口才能得到的内容，并且内容不是提前准备好的，属于动态资源
2. 从架构角度看动、静态资源
1. 请求SSR架构的服务的html属于静态资源还是动态资源？
结论：属于动态资源
因为：html没有提前准备好，没有提前静态化。是来一个请求，就动态编译生成html的
2. 请求SSG架构的服务的html属于静态资源还是动态资源？
结论：属于静态资源
因为：html被提前静态化了。无需实时编译
3. 引发对性能优化的思考
SSR架构的存在问题，以及如何解决
SSR架构性能好是最大的特色之一，但被人诟病的一个最大问题也是性能问题，原因：
-
SSR架构的性能好，其实是针对前端来说的
-
对于前端用户来说，访问SSR的服务，可以直接得到完整的html（CSR架构的html是空的，没有dom内容，dom内容需等js后续生成的），
-
并且如果你的首屏需要被多个接口阻塞时，SSR可以在服务端把请求处理完
-
服务端处理请求非常非常快，举个栗子：同一个接口前端ajax需要1s，服务端请求可能只需20ms，因为服务端可以抹掉网络连接的阻塞，可能和目标下游服务器就在同一个机房
-
-
SSR架构对于服务端来说，性能非常差
- 这个怎么理解呢？ 其实是和服务端接口来做对比的，比如接口的QPS可以很容易超过1000，但SSR的处理QPS可能只有10，因为html是动态生成的，需要大量的时间来编译得到html，所以对于接口来说，SSR的性能很差很差
-
解决办法
-
做成SSG（静态化）
-
原理：提前编译好html，节省编译html的时间，让 请求动态资源 变成 请求静态资源。
-
但也不是没副作用的，副作用是：会丢失动态化能力，比如我本来可以在服务端根据用户的ip，显示对应的语言的html。做成SSG之后，只能默认显示一种语言。并且也无法在服务端把阻塞请求处理完
-
-
不过有办法可以解决上面SSG架构的缺陷（动静结合！）
-
原理：在多加一层bff层，由这一层来处理动态化部分
-
比如 把阻塞请求处理完，通过{{ }}占位标识，替换掉对应html内的数据。
-
比如 根据用户ip显示多语言的问题，需要我们提前用ssg编译好多份html（对应多语言），然后由bff来处理。。（确实做的有点复杂了，不过假如要追求极致性能的话，这是一种选择）
-
-
码字不易，点赞鼓励！！
本文正在参加「」