RWD：Ethan Marcote 的文章是大家认为 RWD 的起源。他提出的 RWD 方案是通过 HTML 和 CSS 的媒体查询技术，配合流体布局实现。RWD 倾向于只改变元素的外观布局，而不大幅度改变内容。Jeffrey Zeldman 总结说，我们就把 RWD 定义为一切能用来为各种分辨率和设备性能优化视觉体验的技术。
AWD：Adaptive Design 是 Aaron Gustafson 的书的标题。他认为 AWD 在包括 RWD 的 CSS 媒体查询技术以外，也要用 Javascript 来操作 HTML 来更适应移动设备的能力。AWD 有可能会针对移动端用户减去内容，减去功能。AWD 可以在服务器端就进行优化，把优化过的内容送到终端上。
一图胜千言。
从定义上而言，RWD 是一套代码，适用于所有屏幕。而 AWD 则是多端多套代码。本文不会过多去纠结响应式与自适应区别，我觉得这两者的本质都是致力于适配不同设备，更好地提升用户体验。
渐进增强 vs. 优雅降级
-
渐进增强（progressive enhancement）：针对低版本浏览器进行构建页面，保证最基本的功能，然后再针对高级浏览器进行效果、交互等改进和追加功能达到更好的用户体验。
-
优雅降级（graceful degradation）：一开始就构建完整的功能，然后再针对低版本浏览器进行兼容。
**区别：**优雅降级是从复杂的现状开始，并试图减少用户体验的供给，而渐进增强则是从一个非常基础的，能够起作用的版本开始，并不断扩充，以适应未来环境的需要。降级（功能衰减）意味着往回看；而渐进增强则意味着朝前看，同时保证其根基处于安全地带。
渐进增强/优雅降级通常是 AWD 会牵扯到的另一个技术术语。本质上而言即是随着屏幕的大小的改变，功能会一点一点增强。
也通常会用在一些高级 CSS3 属性上，我们对一些 CSS 属性进行特性检测，甚至不进行特性检测直接使用。后果是在支持它的网页上该属性正常展示，而不支持它的网页该属性不生效，但也不影响用户的基本使用。
典型的例子是 CSS3 逐渐被大众认可并被使用，PC端页面开始由 IE678 向兼容性更好的IE9+，chrome，firefox浏览器转变的时期。我们可以对页面元素直接使用阴影，圆角等属性。对于不支持它的低版本 IE 而言，没有什么损失，而对于支持它的高级浏览器而言，带给了用户更好的交互视觉体验，这就是渐进增强。
移动端屏幕适配方案
下面会针对一些具体的案例，展开讲讲。第一个是高保真还原设计稿，也就是如何适配移动端繁杂的屏幕大小。
通常而言，设计师只会给出单一分辨率下的设计稿，而我们要做的，就是以这个设计稿为基准，去适配所有不同大小的移动端设备。
在此之前，有一些基础概念需要理解。
提示：一些概念性的东西，大部分人很难一次性记住，或者记了又忘，我觉得记忆这个东西比较看技巧，比如关联法，想象法，把这些生硬的概念与一些符合我们常识的知识关联在一起记忆，往往能够事半功倍。
设备独立像素
以 iPhone6/7/8为例，这里我们打开 Chrome 开发者工具：
这里的 375 * 667 表示的是什么呢，表示的是设备独立像素（DIP），也可以理解为 CSS 像素，也称为逻辑像素：
设备独立像素 = CSS 像素 = 逻辑像素
如何记忆呢？这里使用 CSS 像素来记忆，也就是说。我们设定一个宽度为 375px 的 div，刚好可以充满这个设备的一行，配合高度 667px ，则 div 的大小刚好可以充满整个屏幕。
物理像素
OK，那么，什么又是物理像素呢。我们到电商网站购买手机，都会看一看手机的参数，以 JD 上的 iPhone7 为例：
可以看到，iPhone7 的分辨率是 1334 x 750，这里描述的就是屏幕实际的物理像素。
物理像素，又称为设备像素。显示屏是由一个个物理像素点组成的，1334 x 750 表示手机分别在垂直和水平上所具有的像素点数。通过控制每个像素点的颜色，就可以使屏幕显示出不同的图像，屏幕从工厂出来那天起，它上面的物理像素点就固定不变了，单位为pt。
设备像素 = 物理像素
DPR（Device Pixel Ratio） 设备像素比
OK，有了上面两个概念，就可以顺理成章引出下一个概念。DPR（Device Pixel Ratio） 设备像素比，这个与我们通常说的视网膜屏（多倍屏，Retina屏）有关。
设备像素比描述的是未缩放状态下，物理像素和设备独立像素的初始比例关系。
简单的计算公式：
DPR = 物理像素 / 设备独立像素
我们套用一下上面 iPhone7 的数据（取设备的物理像素宽度与设备独立像素宽度进行计算）：
iPhone7’s DPR = iPhone7’s 物理像素宽度 / iPhone7’s 设备独立像素宽度 = 2
提示：750 / 375 = 2
或者是 1334 / 667 = 2
可以得到 iPhone7 的 dpr 为 2。也就是我们常说的视网膜屏幕。
视网膜（Retina）屏幕是苹果公司"发明"的一个营销术语。苹果公司将 dpr > 1 的屏幕称为视网膜屏幕。
在视网膜屏幕中，以 dpr = 2 为例，把 4(2x2) 个像素当 1 个像素使用，这样让屏幕看起来更精致，但是元素的大小本身却不会改变：
OK，我们再来看看 iPhone XS Max：
它的物理像素如上图是 2688 x 1242，
它的 CSS 像素是 896 x 414，很容易得出 iPhone XS Max 的 dpr 为 3。
上面三个概念（CSS像素、设备独立像素、DPR）是我觉得比较重要的，还有一些其他比较重要的概念 PPI、DPI 不影响后续的内容，可以自行去加深理解。
OK，到这里我们就完成了一个小的里程碑。我们通常说的H5手机适配也就是指的这两个维度：
-
适配不同屏幕大小，也就是适配不同屏幕下的 CSS 像素
-
适配不同像素密度，也就是适配不同屏幕下 dpr 不一致导致的一些问题
适配不同屏幕大小
适配不同屏幕大小，也就是适配不同屏幕下的 CSS 像素。最早移动端屏幕 CSS 像素适配方案是CSS媒体查询。但是无法做到高保真接近 100% 的还原。
适配不同屏幕大小其实只需要遵循一条原则，确保页面元素大小的与屏幕大小保持一定比例。也就是：按比例还原设计稿。
假设我们现在拿到标注为 375*667 的大小的设计稿，其中一个元素的标注如下：
以页面宽度为基准的话，那么，
-
元素的宽度为：
209/375 = 55.73% -
元素的高度为：
80/375 = 21.33% -
元素的上左右边距依次计算…
这样，无论屏幕的 CSS 像素宽度是 320px 还是 375px 还是 414px，按照等量百分比还原出来的界面总是正确的。
然而，理想很丰满，现实很骨感。实现上述百分比方案的核心需要一个全局通用的基准单位，让所有百分比展示以它为基准，但是在 CSS 中，根据CSS Values and Units Module Level 4的定义：
提示：百分比值总要相对于另一个量，比如长度。每个允许使用百分比值的属性，同时也要定义百分比值参照的那个量。这个量可以是相同元素的另一个属性的值，也可以是祖先元素的某个属性的值，甚至是格式化上下文的一个度量（比如包含块的宽度）。
具体来说：
-
宽度（width）、间距（maring/padding）支持百分比值，但默认的相对参考值是包含块的宽度；
-
高度（height）百分比的大小是相对其父级元素高的大小；
-
边框（border）不支持百分值；
-
边框圆角半径（border-radius）支持百分比值，但水平方向相对参考值是盒子的宽度，垂直方向相对参考值是盒子的高度；
-
文本大小（font-size）支持百分比值，但相对参考值是父元素的font-size的值；
-
盒阴影（box-shadow）和文本阴影（text-shadow）不支持百分比值；
首先，支持百分比单位的度量属性有其各自的参照基准，其次并非所有度量属性都支持百分比单位。所以我们需要另辟蹊径。
rem 适配方案
在 vw 方案出来之前，最被大众接受的就是使用 rem 进行适配的方案，因为 rem 满足上面说的，可以是一个全局性的基准单位。
rem（font size of the root element），在 CSS Values and Units Module Level 3中的定义就是， 根据网页的根元素来设置字体大小，和 em（font size of the element）的区别是，em 是根据其父元素的字体大小来设置，而 rem 是根据网页的跟元素（html）来设置字体大小。
flexible
基于此，淘宝早年推行的一套以 rem 为基准的适配方案：lib-flexible。其核心做法在于：
-
根据设备的 dpr 动态改写
<meta>标签，设置 viewport 的缩放 -
给
<html>元素添加 data-dpr 属性，并且动态改写 data-dpr 的值 -
根据
document.documentElement.clientWidth动态修改<html>的 font-size ，页面其他元素使用 rem 作为长度单位进行布局，从而实现页面的等比缩放
提示：关于头两点，其实现在的 lib-flexible 库已经不这样做了，不再去缩放 Viewport，字体大小的设定也直接使用了 rem
hotcss
hotcss 不是一个库，也不是一个框架。它是一个移动端布局开发解决方案。使用 hotcss 可以让移动端布局开发更容易。本质的思想与 flexible 完全一致。
对于 rem 方案的一些总结
使用 flexible/hotcss 作为屏幕宽度适配解决方案，是存在一些问题的：
- 动态修改 Viewport 存在一定的风险的，譬如通过 Viewport 改变了页面的缩放之后，获取到的
innerWidth/innerHeight也会随之发生变化，如果业务逻辑有获取此类高宽进行其他计算的，可能会导致意想不到的错误；
提示：到今天，其实存在很多在 flexible 基础上演化而来的各种 rem 解决方案，有的不会对 Viewport 进行缩放处理，自行处理 1px 边框问题。
-
flexible/hotcss 都并非纯 CSS 方案，需要引入一定的 Javascript 代码
-
rem 的设计初衷并非是用于解决此类问题，用 rem 进行页面的宽度适配多少有一种 hack 的感觉
-
存在一定的兼容性问题，对于安卓 4.4 以下版本系统不支持 viewport 缩放（当然，flexible 处理 Android 系列时，始终认为其 dpr 为 1，没有进行 viewport 缩放）
vw 适配方案
严格来说，使用 rem 进行页面适配其实是一种 hack 手段，rem 单位的初衷本身并不是用来进行移动端页面宽度适配的。
到了今天，有了一种更好的替代方案，使用 vw 进行适配 。
百分比适配方案的核心需要一个全局通用的基准单位，rem 是不错，但是需要借助 Javascript 进行动态修改根元素的 font-size，而 vw/vh（vmax/vmin） 的出现则很好弥补 rem 需要 JS 辅助的缺点。
根据 CSS Values and Units Module Level 4：vw等于初始包含块（html元素）宽度的1%，也就是
-
1vw等于window.innerWidth的数值的 1% -
1vh等于window.innerHeight的数值的 1%
再以上面设计稿图的元素为例，那么，
-
元素的宽度为：
209/375 = 55.73% = 55.73vw -
元素的高度为：
80/375 = 21.33% = 21.33vw -
元素的上左右边距依次计算…
根据相关的测试，可以使用 vw 进行长度单位的有：
-
容器大小适配，可以使用 vw
-
文本大小的适配，可以使用 vw
-
大于 1px 的边框、圆角、阴影都可以使用 vw
-
内距和外距，可以使用 vw
简单的一个页面，看看效果，完全是等比例缩放的效果：
CodePen Demo（移动端打开）：使用 vw 进行页面适配。
自动转换插件
当我们使用 rem 作为长度单位的时，通常会有借助 Sass/Less 实现一个转换函数，像是这样：
// 假设设计稿的宽度是 375px，假设取设计稿宽度下 1rem = 100px$baseFontSize: 100;
@function px2rem($px) { @return $px / $baseFontSize * 1rem;}
同理，在 vw 方案下，我们只需要去改写这个方法：
// 假设设计稿的宽度是 375px@function px2rem($px) { @return $px / 375 * 100vw;}
当然，我们还可以借助一些插件包去实现这个自动转换，提高效率，譬如 postcss-px-to-viewport。
vw polyfill
vw 现在毕竟还是存在兼容问题的，看看兼容性：
其实已经覆盖了绝大部分设备，那么如果业务使用了且又真的出现了兼容问题，应该怎么处理呢？有两种方式可以进行降级处理：
-
CSS Houdini：通过CSS Houdini针对vw做处理，调用CSS Typed OM Level1 提供的 CSSUnitValue API。
-
CSS Polyfill：通过相应的Polyfill做相应的处理，目前针对于 vw 单位的 Polyfill 主要有：vminpoly、Viewport Units Buggyfill、vunits.js和 Modernizr
对于 vw 方案的一些总结
vw 确实看上去很不错，但是也是存在它的一些问题：
-
也没能很好的解决 1px 边框在高清屏下的显示问题，需要自行处理
-
由于 vw 方案是完全的等比缩放，在完全等比还原设计稿的同时带来的一个问题是无法很好的限定一个最大最小宽度值，由于 rem 方案是借助 Javascript 的，所以这一点 rem 比 vw 会更加的灵活
当然，两个方案现阶段其实都可以使用甚至一起搭配使用，更多详情可以读读：
-
再聊移动端页面的适配
-
Responsive And Fluid Typography With vh And vw Units
-
使用VH和VW实现真正的流体排版
1px线
上面说到使用 vw 适配屏幕大小方案，其中有一个缺点就是在 Retina 屏下，无法很好的展示真正的 1px 物理像素线条。
设计师想要的 retina 下 border: 1px，其实是 1 物理像素宽，而不是 1 CSS 像素宽度，对于 CSS 而言：
-
在 dpr = 1 时，此时 1 物理像素等于 1 CSS 像素宽度；
-
在 dpr = 2 时，此时 1 物理像素等于 0.5 CSS 宽度像素，可以认为
border-width: 1px这里的 1px 其实是 1 CSS像素宽度，等于 2 像素物理宽度，设计师其实想要的是border-width: 0.5px; -
在 dpr = 3 时，此时 1 物理像素等于 0.33 CSS 宽度像素，设计师其实想要的是 border: 0.333px
然而，并不是所有手机浏览器都能识别 border-width: 0.5px，在 iOS7 以下，Android 等其他系统里，小于 1px 的单位会被当成为 0px 处理，那么如何实现这 0.5px、0.33px 呢？
这里介绍几种方法：
-
渐变实现
-
使用缩放实现
-
使用图片实现（base64）
-
使用SVG实现（嵌入 background url）
Retina 屏幕下 1px 线的实现。
图片适配及优化
图像通常占据了网页上下载资源绝的大部分。优化图像通常可以最大限度地减少从网站下载的字节数以及提高网站性能。
通常可以，有一些通用的优化手段：
-
消除多余的图像资源
-
尽可能利用 CSS3\SVG 矢量图像替代某些光栅图像
-
谨慎使用字体图标，使用网页字体取代在图像中进行文本编码
-
选择正确的图片格式
-
为不同 DPR 屏幕提供最适合的图片尺寸
本文重点关注如何在不同的 dpr 屏幕下，让图片看起来都不失真。
首先就是上述的第二点，尽可能利用 CSS3\SVG 矢量图像替代某些光栅图像。某些简单的几何图标，可以用 CSS3 快速实现的图形，都应该尽量避免使用光栅图像。这样能够保证它们在任何尺寸下都不会失真。
其次，实在到了必须使用光栅图像的地步，也是有许多方式能保证图像在各种场景下都不失真。
无脑多倍图
在移动端假设我们需要一张 CSS 像素为 300 x 200 的图像，考虑到现在已经有了 dpr = 3 的设备，那么要保证图片在 dpr = 3 的设备下也正常高清展示，我们最大可能需要一张 900 x 600 的原图。
这样，不管设备的 dpr 是否为 3，我们统一都使用 3 倍图。这样即使在 dpr = 1，dpr = 2 的设备上，也能非常好的展示图片。
当然这样并不可取，会造成大量带宽的浪费。现代浏览器，提供了更好的方式，让我们能够根据设备 dpr 的不同，提供不同尺寸的图片。
srcset 配合 1x 2x 像素密度描述符
简单来说，srcset 可以根据不同的 dpr 拉取对应尺寸的图片：
上面 srcset 里的 1x，2x 表示 像素密度描述符，表示
-
当屏幕的 dpr = 1 时，使用
images/illustration-small.png这张图 -
当屏幕的 dpr = 2 时，使用
images/illustration-big.png这张图
srcset 属性配合 sizes 属性 w 宽度描述符
上面 1x，2x 的写法比较容易接受易于理解。
除此之外，srcset属性还有一个 w 宽度描述符，配合 sizes 属性一起使用，可以覆盖更多的面。
以下面这段代码为例子：
<imgsizes = “(min-width: 600px) 600px, 300px"src = "photo.png"srcset = “photo@1x.png 300w,photo@2x.png 600w,photo@3x.png 1200w,>
解析一下：
sizes = “(min-width: 600px) 600px, 300px" 的意思是，如果屏幕当前的 CSS 像素宽度大于或者等于 600px，则图片的 CSS 宽度为 600px，反之，则图片的 CSS 宽度为 300px。
也就是 sizes 属性声明了在不同宽度下图片的 CSS 宽度表现。这里可以理解为，大屏幕下图片宽度为 600px，小屏幕下图片宽度为 300px。（具体的媒体查询代码由 CSS 实现）
这里的 sizes 属性只是声明了在不同宽度下图片的 CSS 宽度表现，而具体使图片在大于600px的屏幕上展示为600px宽度的代码需要另外由 CSS 或者 JS 实现，有点绕。
srcset = “photo@1x.png 300w, photo@2x.png 600w, photo@3x.png 1200w 里面的 300w，600w，900w 叫宽度描述符。怎么确定当前场景会选取哪张图片呢？
1. 当前屏幕 dpr = 2 ，CSS 宽度为 375px。
当前屏幕 CSS 宽度为 375px，则图片 CSS 宽度为 300px。分别用上述 3 个宽度描述符的数值除以 300。
-
300 / 300 = 1
-
600 / 300 = 2
-
1200 / 300 = 4
上面计算得到的 1、 2、 4 即是算出的有效的像素密度，换算成和 x 描述符等价的值 。这里 600w 算出的 2 即满足 dpr = 2 的情况，选择此张图。
2. 当前屏幕 dpr = 3 ，CSS 宽度为 414px。
当前屏幕 CSS 宽度为 414px，则图片 CSS 宽度仍为 300px。再计算一次：
-
300 / 300 = 1
-
600 / 300 = 2
-
1200 / 300 = 4
因为 dpr = 3，2 已经不满足了，则此时会选择 1200w 这张图。
3. 当前屏幕 dpr = 1 ，CSS 宽度为 1920px。
当前屏幕 CSS 宽度为 1920px，则图片 CSS 宽度变为了 600px。再计算一次：
-
300 / 600 = .5
-
600 / 600 = 1
-
1200 / 600 = 2
因为 dpr = 1，所以此时会选择 600w 对应的图片。
具体的可以试下这个 Demo：CodePen Demo – srcset属性配合w宽度描述符配合sizes属性
此方案的意义在于考虑到了响应性布局的复杂性与屏幕的多样性，利用上述规则，可以一次适配 PC 端大屏幕和移动端高清屏，一箭多雕。
了解更多细节，推荐看看：
-
Google Web Fundamentals – Web Responsive Images
-
响应式图片srcset全新释义sizes属性w描述符
字体适配方案
字体大小
字体是很多前端开发同学容易忽略的一个点，但是其中也是有很多小知识点。
首先要知道，浏览器有最小字体限制：
-
PC上最小 font-size=12px
-
手机上最小 font-size=8px
如果小于最小字体，那么字体默认就是最小字体。
其次，很多早期的文章规范都建议不要使用奇数级单位来定义字体大小（如 13px，15px…），容易在一些低端设备上造成字体模糊，出现锯齿。
字体的选择展示
在字体适配上面，我们需要从性能和展示效果两个维度去考虑。
完整的一个字体资源实在太大了，所以我们应该尽可能的使用用户设备上已有的字体，而不是额外去下载字体资源，从而使加载时间明显加快。
而从展示效果层面来说，使用系统字体能更好的与当前操作系统使用的相匹配，得到最佳的展示效果。所以我们在字体使用方面，有一个应该尽量去遵循的原则，也是现在大部分网站在字体适配上使用的策略：
使用各个支持平台上的默认系统字体。
兼顾各个操作系统
常见的操作系统有 Windows、Windows Phone、Mac OS X、iPhone、Android Phone、Linux。当然对于普通用户而言，无须关注 Linux 系统。
下面就以 CSS-Trick 网站最新的 font-family 为例，看看他们是如何在字体选择上做到适配各个操作系统的
{font-family: system-ui,-apple-system,BlinkMacSystemFont,segoe ui,Roboto, Helvetica,Arial, sans-serif,apple color emoji,segoe ui emoji,segoe ui symbol;}
font-family 关键字
对于 CSS 中的 font-family 而言，它有两类取值。
-
一类是类似这样的具体的字体族名定义：
font-family: Arial这里定义了一个具体的字体样式，字体族名为Arial; -
一类是通用字体族名，它是一种备选机制，用于在指定的字体不可用时给出较好的字体，类似这样：
font-family: sans-serif。
其中，sans-serif 表无衬线字体族，例如， “Open Sans”, “Arial” “微软雅黑” 等等。
关于通用字体族名，在 CSS Fonts Module Level 3 – Basic Font Properties 中，定义了 5 个，也就是我们熟知的几个通用字体族名：
-
serif 衬线字体族
-
sans-serif 非衬线字体族
-
monospace 等宽字体，即字体中每个字宽度相同
-
cursive 草书字体
-
fantasy 主要是那些具有特殊艺术效果的字体
新增通用字体族关键字
而在 CSS Fonts Module Level 4 – Generic font families 中，新增了几个关键字：
-
system-ui 系统默认字体
-
emoji 用于兼容 emoji 表情符号字符
-
math 适用于数学表达式
-
fangsong 此字体系列用于中文的（仿宋）字体。
我们看看用的最多的 system-ui。
system-ui
简单而言，font-family: system-ui 的目的就是在不同的操作系统的 Web 页面下，自动选择本操作系统下的默认系统字体。
默认使用特定操作系统的系统字体可以提高性能，因为浏览器或者 webview 不必去下载任何字体文件，而是使用已有的字体文件。 font-family: system-ui 字体设置的优势之处在于它与当前操作系统使用的字体相匹配，对于文本内容而言，它可以得到最恰当的展示。
San Francisco Fonts
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Web前端开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上前端开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：前端）
最后
由于文档内容过多，为了避免影响到大家的阅读体验，在此只以截图展示部分内容，详细完整版的JavaScript面试题文档，或更多前端资料可以点此处免费获取。
ly: system-ui` 的目的就是在不同的操作系统的 Web 页面下，自动选择本操作系统下的默认系统字体。
默认使用特定操作系统的系统字体可以提高性能，因为浏览器或者 webview 不必去下载任何字体文件，而是使用已有的字体文件。 font-family: system-ui 字体设置的优势之处在于它与当前操作系统使用的字体相匹配，对于文本内容而言，它可以得到最恰当的展示。
San Francisco Fonts
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Web前端开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
[外链图片转存中…(img-AoEQfuNI-1712381416906)]
[外链图片转存中…(img-GkE6geAj-1712381416906)]
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上前端开发知识点，真正体系化！
[外链图片转存中…(img-op3nQwcO-1712381416907)]
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：前端）
最后
[外链图片转存中…(img-TtXqhgTY-1712381416907)]
[外链图片转存中…(img-jNTn4CNx-1712381416907)]
由于文档内容过多，为了避免影响到大家的阅读体验，在此只以截图展示部分内容，详细完整版的JavaScript面试题文档，或更多前端资料可以点此处免费获取。
175
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
