面试

1、普通流（常规流） 文档流（流式布局）分为 普通流、定位流、浮动流，不同流内的块级元素和行内元素的布局方式不同，布局方式用 FC（格式化上下文，含有 块级格式化上下文、内联格式化上下文、层叠格式化上下文、灵活格式化上下文等）来命名； 普通流中的布局规则默认为块级盒子从上到下，垂直排列；内联盒子从左到右，水平排列等；（书写模式（writing-mode）会对流布局产生影响； 2、position 属性有： static：默认值，元素依然按照 普通流 的定位规则定位； relative absolute sticky fixed 使用 position 会脱离常规流，成为定位流，并有其自己的定位规则； 3、float 属性有： left right none inherit 使用 float 会脱离常规流，成为浮动流，并有其自己的定位规则； 4、table 使用 HTML 标签来布局； <table> <tr> <th></th> <th></th> </tr> <tr> <td></td> <td></td> </tr> </table> 5、flex 2009 年 W3C 提供的方案，注意只有 IE 10+ 支持 flex； 重要的概念：flex 容器，flex 项目，主轴，交叉轴； 设置某个元素的属性 display: flex;，此元素就成了 flex 容器，flex 容器内的元素是 flex 项目； flex 容器的属性： flex-direction flex-wrap flex-flow justify-content align-items align-content flex 项目的属性 flex （flex-grow、flex-shrink、flex-basis） order align-self 6、grid 二维布局方式，相对于使用 HTML 结构实现的 table 布局，grid 布局都是在 CSS 中完成的； ...

一、插槽的几种使用方式 1. 普通插槽 举例来说，这里有一个 <FancyButton> 组件，可以像这样使用： <FancyButton> Click me! <!-- 插槽内容 --> </FancyButton> 而 <FancyButton> 的模板是这样的： <button class="fancy-btn"> <slot></slot> <!-- 插槽出口 --> </button> <slot> 元素是一个 插槽出口 (slot outlet)，标示了父元素提供的 插槽内容 (slot content) 将在哪里被渲染。 最终渲染出的 DOM 是这样： <button class="fancy-btn">Click me!</button> 2. 具名插槽 有时在一个组件中包含多个插槽出口是很有用的。举例来说，在一个 <BaseLayout> 组件中，有如下模板： <div class="container"> <header> <!-- 标题内容放这里 --> </header> <main> <!-- 主要内容放这里 --> </main> <footer> <!-- 底部内容放这里 --> </footer> </div> 对于这种场景， <slot> 元素可以有一个特殊的 attribute name，用来给各个插槽分配唯一的 ID，以确定每一处要渲染的内容： ...

聊聊 for of 说起 for of 相信每个写过 JavaScript 的人都用过 for of ，平时我们用它做什么呢？大多数情况应该就是遍历数组了，当然，更多时候，我们也会用 map() 或者 filer() 来遍历一个数组。 但是就像我们标题里面说的，它跟 Generator 能扯上什么关系呢？ 首先我们想一个问题，为什么使用 for of 或者 map()/filer() 方法就可以遍历一个数组 (或者类数组对象: Strings , Maps , Sets , arguments ) 呢？ 为什么不能用他们来遍历一个对象呢？ 你能学到什么 对 for of 更深入的理解 iterator 到底是何方神圣? 数组也是对象，为什么不能用 for of 来遍历对象呢？ 如何实现对象的 for of? Generator 又是何方神圣？他有什么用呢？ 类数组对象的玄机 在真正揭开谜底之前，站在 for of 的角度想一下，现在让你去遍历一个数组，你需要知道什么信息呢？ 对应下标的值 是否遍历结束的标志 带着这样的思考，我们打印一个数组来看看这里面的玄机： const numbersArray = [1, 2, 3]; console.dir(numbersArray); 数组 (或者类数组对象: Strings , Maps , Sets , arguments ) 的原型中都实现了一个方法 Symbol.iterator，问题来了，那么这个 Symbol.iterator 又有什么用呢？ 拿出来试一下就知道了： ...

纵观JavaScript中所有必须需要掌握的重点知识中，函数是我们在初学的时候最容易忽视的一个知识点。在学习的过程中，可能会有很多人、很多文章告诉你面向对象很重要，原型很重要，可是却很少有人告诉你，面向对象中所有的重点难点，几乎都与函数息息相关。 包括之前几篇文章介绍的执行上下文，变量对象，闭包，this等，都是围绕函数的细节来展开。 很多人在学习中，很急切的希望自己快一点开始学习面向对象，学习模块，学习流行框架，然后迅速成为高手。但是我可以很负责的告诉你，关于函数的这些基础东西没理解到一定程度，那么你的学习进展一定是举步维艰的。 所以，大家一定要重视函数！ 当然，关于函数的重点，难点在前面几篇文章都已经说得差不多了，这篇文章主要总结一下函数的基础知识，并初步学习函数式编程的思维。 一、函数声明、函数表达式、匿名函数与自执行函数 关于函数在实际开发中的应用，大体可以总结为函数声明、函数表达式、匿名函数、自执行函数。 函数声明 我们知道，JavaScript中，有两种声明方式，一个是使用var的变量声明，另一个是使用function的函数声明。 在前端基础进阶（三）：变量对象详解中我有提到过，变量对象的创建过程中，函数声明比变量声明具有更为优先的执行顺序，即我们常常提到的函数声明提前。因此我们在执行上下文中，无论在什么位置声明了函数，我们都可以在同一个执行上下文中直接使用该函数。 fn(); // function function fn() { console.log('function'); } 函数表达式 与函数声明不同，函数表达式使用了var进行声明，那么我们在确认他是否可以正确使用的时候就必须依照var的规则进行判断，即变量声明。我们知道使用var进行变量声明，其实是进行了两步操作。 // 变量声明 var a = 20; // 实际执行顺序 var a = undefined; // 变量声明，初始值undefined，变量提升，提升顺序次于function声明 a = 20; // 变量赋值，该操作不会提升 同样的道理，当我们使用变量声明的方式来声明函数时，就是我们常常说的函数表达式。函数表达的提升方式与变量声明一致。 fn(); // 报错 var fn = function() { console.log('function'); } 上例子的执行顺序为： var fn = undefined; // 变量声明提升 fn(); // 执行报错 fn = function() { // 赋值操作，此时将后边函数的引用赋值给fn console.log('function'); } 因此，由于声明方式的不同，导致了函数声明与函数表达式在使用上的一些差异需要我们注意，除此之外，这两种形式的函数在使用上并无不同。 关于上面例子中，函数表达式中的赋值操作，在其他一些地方也会被经常使用，我们清楚其中的关系即可。 在构造函数中添加方法 function Person(name) { this.name = name; this.age = age; // 在构造函数内部中添加方法 this.getAge = function() { return this.age; } this. } // 给原型添加方法 Person.prototype.getName = function() { return this.name; } // 在对象中添加方法 var a = { m: 20, getM: function() { return this.m; } } 匿名函数 ...

对于大多数前端工程师来说，音视频技术是一个比较少涉足的领域， 本知识点主要介绍流媒体技术中的文本、图形、图像、音频和视频多种理论知识，涉及到播放器、web媒体技术、主流框架等内容。 一、音视频基础 1.1 视频 1.1.1 基础概念 码率 单位时间内取样率越大，精度就越高，处理出来的文件就越接近原始文件。 帧率 对视频来说，帧率对应这观看卡顿。帧率越高，流畅度越高，低帧率会造成视觉卡顿。 压缩率 经过压缩后文件的大小 / 原始文件的大小 * 100% = 压缩率。编码压缩越小越好，但压得越小，解压时间 分辨率 用于度量图像内数据量多少的一个参数，和视频清晰度息息相关。 1.1.2 视频容器格式 容器格式相信大家经常见到： MP4、AVI、FLV、TS/M3U8、WebM、OGV、MOV… 1.1.2 视频编码格式 H.264 目前最流行的编码格式。 H.265 新型的编码格式，高效的视频编码。用来以替代H.264/AVC编码标准。 VP9 VP9是WebM Project开发的下一代视频编码格式 。VP9支持从低比特率压缩到高质量超高清的所有Web和移动用例，并额外支持10/12位编码和HDR AV1 AOM（Alliance for Open Media，开放媒体联盟）制定的一个开源、免版权费的视频编码格式。AV1是google制定的VP9标准的继任者，也是H265强有力的竞争者。 1.2 音频 1.2.1 基础概念 采样率 音频采样率是指录音设备在一秒钟内对声音信号的采样次数，采样频率越高声音的还原就越真实越自然。 采样大小 一秒钟所采的样本数为比特率，每个样本中信息的比特数就是位深，即采样精度，单位为Bit。 比特率 指每秒传送的比特(bit)数，又称数据信号速率。单位为比特/秒、千比特/秒或兆比特/秒。比特率越高，表示单位时间传送的数据就越多。 压缩率 原始音频数据与通过PCM等压缩编码技术压缩后的数据大小的比率 1.2.2 音频容器格式 音频格式也比较常见：WAV、AIFF、AMR、MP3、Ogg… 1.2.3 音频编码格式 PCM 脉冲编码调制(Pulse Code Modulation,PCM)，PCM是数字通信的编码方式之一。 AAC-LC(MPEG AAC Low Complexity) 低复杂度编码解码器（AAC-LC — 低复杂度高级音频编码）是低比特率、优质音频 的高性能音频编码解码器。 AAC-LD （又名AAC低延迟或MPEG-4低延迟音频编码器），为电话会议和OTT服务量身打造的低延迟音频编解码器 LAC（Free Lossless Audio Codec） 免费无损音频编解码器。是一套著名的自由音频压缩编码，其特点是无损压缩。 2012年以来它已被很多软件及硬件音频产品（如CD等）所支持。 1.3 常见标签 1.3.1 <audio> 元素 1.3.1.1 基本用途 <audio> 元素用于在网页中嵌入音频内容。它可以播放音乐、播客、音效等。 ...

SIL（Swift Intermediate Language，Swift 中间语言）是 Swift 编译器在编译过程中生成的一种中间表示（Intermediate Representation，IR）。它位于 Swift 源码与 LLVM IR 之间，是 Swift 编译器架构中至关重要的一层。 SIL 的设计目标是： 对 Swift 语言的高级语义进行精确建模 在高层抽象的基础上执行强大的优化 保留足够的类型信息，用于诊断和安全检查 作为 Swift 特有优化的载体，弥补 LLVM IR 无法直接表达 Swift 语义的不足 SIL 并不是给开发者日常编写的语言，而是编译器的内部表示。理解它有助于深入理解 Swift 的编译过程、性能优化原理和内存管理机制。 Swift 编译流程概览 在了解 SIL 之前，需要先理解 Swift 的整体编译流程： flowchart TD A[Swift 源代码 .swift] --> B[词法分析 Lexer] B --> C[语法分析 Parser] C --> D[语义分析 Sema] D --> E[SILGen: 生成 Raw SIL] E --> F[SIL 优化 Guaranteed Passes] F --> G[SIL 优化 General Passes] G --> H[IRGen: 生成 LLVM IR] H --> I[LLVM 优化] I --> J[机器码 .o] J --> K[链接器 Linker] K --> L[可执行文件 / 动态库] 各阶段简述 词法分析（Lexer） 编译的第一步。Lexer 逐字符扫描 .swift 源文件，将其切分为一系列Token（词法单元），例如关键字 func、标识符 add、运算符 +、字面量 42、左右括号等。Token 是后续所有分析的最小输入单位。这一步会剥离注释和空白，但保留它们的位置信息以便后续生成精确的诊断信息（错误提示的行号和列号）。 ...

ChatGPT、Claude、Gemini——这些模型的核心都是同一个架构：Transformer。它在2017年由Google的论文"Attention Is All You Need"提出，彻底改变了自然语言处理（NLP）领域，随后席卷了计算机视觉、语音、蛋白质折叠等几乎所有AI领域。 我们从最直觉的角度出发，一步步搞清楚Transformer到底在做什么。 一、从序列到序列：Transformer要解决什么问题 1.1 语言的本质是序列 一句话是一个词的序列： "我 今天 很 开心" → [我, 今天, 很, 开心] 语言模型的核心任务是：给定前面的词，预测下一个词。 "我 今天 很" → ?（开心？难过？忙碌？） 但词与词之间的关系非常复杂。“它"指代谁？“银行"是河岸还是金融机构？这取决于上下文中其他词的信息。 1.2 RNN的困境 在Transformer之前，处理序列的主流方法是循环神经网络（RNN）。RNN像一个人从左到右逐词阅读，用一个"记忆状态"来记住看过的内容： graph LR X1["我"] --> H1["h₁"] H1 --> H2["h₂"] X2["今天"] --> H2 H2 --> H3["h₃"] X3["很"] --> H3 H3 --> H4["h₄"] X4["开心"] --> H4 问题在于： 长距离依赖困难：信息需要经过很多步才能从序列开头传到末尾，容易丢失 无法并行：必须逐步处理，前一步完成才能开始后一步，训练很慢 Transformer的核心洞察是：不需要逐步处理，让序列中的每个位置直接与所有其他位置交互。这就是"注意力（Attention）“机制。 二、词嵌入：给词语一个数学身份 2.1 从独热编码到词向量 计算机不认识"猫”、“狗"这样的文字。我们需要把词转换成数字。 最朴素的方式是独热编码（One-Hot Encoding）：假设词汇表有50,000个词，每个词用一个50,000维的向量表示，只有对应位置是1，其余全是0。 "猫" → [0, 0, ..., 1, ..., 0, 0] (第3721个位置是1) "狗" → [0, 0, ..., 0, 1, ..., 0, 0] (第5042个位置是1) 问题：在这种表示下，“猫"和"狗"的距离与"猫"和"经济学"的距离一样远——完全丢失了语义信息。 ...

定义 观察者模式（Observer Pattern）是一种行为型设计模式，它定义了对象之间的一对多依赖关系，当一个对象（主题/被观察者）的状态发生改变时，所有依赖于它的对象（观察者）都会收到通知并自动更新。 观察者模式也被称为发布-订阅模式（Publish-Subscribe Pattern）。 为什么需要观察者模式 观察者模式要解决的核心问题是：当一个对象的状态发生变化时，如何自动通知所有依赖它的对象。 问题场景：假设我们正在开发一个电商App，用户登录后需要更新多个页面的状态（首页显示用户名、购物车同步、个人中心更新等）。 最直接的方式可能是这样： class LoginService { func login(username: String, password: String) { // 登录成功后... let user = User(name: username) // 直接调用各个需要更新的对象 HomeViewController.shared.updateUser(user) CartViewController.shared.syncCart(for: user) ProfileViewController.shared.refreshProfile(user) // 如果还有其他需要通知的地方，继续添加... } } 这种方式有什么问题？ 紧耦合：LoginService必须知道所有需要通知的对象，依赖关系错综复杂 难以维护：每新增一个需要监听登录事件的页面，都要修改LoginService 违反开闭原则：对扩展不开放，每次扩展都要修改已有代码 单例滥用：为了让LoginService能访问到各个页面，不得不使用大量单例 观察者模式的解决思路： 被观察者（Subject）只负责"广播"状态变化，不关心谁在监听；观察者（Observer）自己注册感兴趣的事件： // 使用NotificationCenter实现 class LoginService { func login(username: String, password: String) { let user = User(name: username) // 只负责发送通知，不关心谁在监听 NotificationCenter.default.post( name: .userDidLogin, object: nil, userInfo: ["user": user] ) } } // 各个页面自己注册监听 class HomeViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() NotificationCenter.default.addObserver( self, selector: #selector(handleUserLogin), name: .userDidLogin, object: nil ) } @objc func handleUserLogin(_ notification: Notification) { if let user = notification.userInfo?["user"] as? User { updateUI(with: user) } } } 观察者模式的好处： ...

什么是 Bundle Splitting？ Bundle Splitting（代码分割）是一种将前端资源拆分成更小、独立的模块的技术。传统上，前端资源（如 JavaScript、CSS 和图片等）被打包成单个文件，通常称为“bundle”。这种方式存在一个问题，即无论用户需要哪些功能，都必须下载整个 bundle。而 Bundle Splitting 技术通过将代码拆分为更小的模块，按需加载，可以有效解决这个问题。 Bundle Splitting 的优点 减少初始加载时间 通过将代码拆分为多个小块，可以减少初始加载时间。当用户首次访问网页时，只需下载当前页面所需的资源，而无需等待整个应用程序的加载完成。这可以极大地提高页面的响应速度，并减少用户的等待时间。 提升用户体验 通过将代码分割成模块，可以使应用程序更具响应性。当用户与应用进行交互时，只需加载所需的代码块，而不是整个应用。这将减少不必要的资源消耗，并使用户感觉应用更加流畅和快速。 优化缓存策略 拆分代码还能优化缓存策略。当应用程序发生更改时，只需重新加载发生变化的模块，而不必重新下载整个应用。这减少了不必要的网络请求，提高了应用的更新效率，并减轻了服务器的负载。 并行加载资源 通过将代码拆分为多个模块，可以实现并行加载资源。浏览器能够同时下载多个文件，从而减少整体加载时间。这对于大型应用程序和复杂的前端框架特别有益，能够更好地利用浏览器的并行下载能力，提高资源的加载效率。 代码复用和维护 通过将代码分割成模块，可以更好地实现代码的复用和维护。不同的模块可以根据需求进行加载和升级，使得代码结构更加清晰、模块化。这也有助于团队合作，不同开发者可以并行工作在不同的模块上，提高开发效率和代码质量。 Bundle Splitting 的缺点 增加了网络请求 拆分代码会增加应用程序的网络请求次数。每个模块都需要进行一次独立的网络请求，这可能会导致一些额外的延迟和性能损失。在网络条件较差的情况下，这可能会对用户体验产生一定影响。 增加了开发复杂性 使用 Bundle Splitting 技术需要对应用程序的依赖关系进行深入分析和管理。开发人员需要仔细考虑代码的拆分点，以及如何在运行时动态加载模块。这增加了开发复杂性，并要求开发人员具备较高的技术水平和经验。 潜在的代码冗余 当模块之间存在共享的代码片段时，可能会出现潜在的代码冗余问题。如果不合理地进行代码拆分，可能会导致多个模块中存在相同的代码，增加了资源的下载和维护成本。因此，在进行代码拆分时，需要仔细考虑代码复用和代码冗余的问题。 需要额外的工具和配置 Bundle Splitting 需要使用额外的工具和配置来实现代码的拆分和动态加载。这可能需要对构建工具进行配置，如 Webpack、Rollup 等，以及对模块加载器进行调整。这增加了一些学习成本和开发成本，尤其是对于新手来说。 Bundle Splitting 的适用场景 Bundle Splitting 技术适用于大型的 Web 应用程序，特别是那些具有复杂功能和大量依赖的应用。以下是一些适合使用 Bundle Splitting 的场景： 大型单页应用：对于由多个模块组成的单页应用，使用 Bundle Splitting 可以提高初始加载速度，提升用户体验。 按需加载：对于需要动态加载不同功能模块的应用，Bundle Splitting 可以根据用户的需求按需加载模块，减少不必要的资源消耗。 公共库和框架：对于使用公共库或框架的应用，可以将这些库和框架拆分成单独的模块，以便在多个页面中共享和复用。 国际化支持：对于需要支持多种语言的应用，可以将不同语言的资源文件拆分成独立的模块，根据用户的语言偏好进行加载。 代码分支管理：对于大型团队开发的项目，使用 Bundle Splitting 可以更好地实现代码的分支管理和并行开发，提高开发效率。 Bundle Splitting 在知名项目中的应用 示例 1：React.lazy 和 Suspense React.js 是一个广泛使用的 JavaScript 库，用于构建用户界面。React 提供了 React.lazy 和 Suspense API 来实现 Bundle Splitting。 ...

一、前言 因为项目中使用到了 WebSocket ，面试官在深挖项目经验的时候，也难免提到 WebSocket 相关的知识点，通过这篇文章再做一下总结。 二、什么是WebSocket WebSocket 是一种在单个TCP连接上进行全双工通信的协议。WebSocket 使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。 在 WebSocket API 中，浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接， 并进行双向数据传输。 WebSocket本质上一种计算机网络应用层的协议，用来弥补http协议在持久通信能力上的不足。 WebSocket 协议在2008年诞生，2011年成为国际标准。现在最新版本浏览器都已经支持了。 它的最大特点就是，服务器可以主动向客户端推送信息，客户端也可以主动向服务器发送信息，是真正的双向平等对话，属于服务器推送技术的一种。 WebSocket 的其他特点包括： （1）建立在 TCP 协议之上，服务器端的实现比较容易。 （2）与 HTTP 协议有着良好的兼容性。默认端口也是80和443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器。 （3）数据格式比较轻量，性能开销小，通信高效。 （4）可以发送文本，也可以发送二进制数据。 （5）没有同源限制，客户端可以与任意服务器通信。 （6）协议标识符是ws（如果加密，则为wss），服务器网址就是 URL。 ws://example.com:80/some/path 为什么需要 WebSocket？ 我们已经有了 HTTP 协议，为什么还需要另一个协议？它能带来什么好处？ 因为 HTTP 协议有一个缺陷：通信只能由客户端发起，不具备服务器推送能力。 举例来说，我们想了解查询今天的实时数据，只能是客户端向服务器发出请求，服务器返回查询结果。HTTP 协议做不到服务器主动向客户端推送信息。 这种单向请求的特点，注定了如果服务器有连续的状态变化，客户端要获知就非常麻烦。我们只能使用“轮询”：每隔一段时候，就发出一个询问，了解服务器有没有新的信息。最典型的场景就是聊天室。轮询的效率低，非常浪费资源（因为必须不停连接，或者 HTTP 连接始终打开）。 在 WebSocket 协议出现以前，创建一个和服务端进双通道通信的 web 应用，需要依赖HTTP协议，进行不停的轮询，这会导致一些问题： 服务端被迫维持来自每个客户端的大量不同的连接 大量的轮询请求会造成高开销，比如会带上多余的header，造成了无用的数据传输。 http协议本身是没有持久通信能力的，但是我们在实际的应用中，是很需要这种能力的，所以，为了解决这些问题，WebSocket协议由此而生，于2011年被IETF定为标准RFC6455，并被RFC7936所补充规范。 并且在HTML5标准中增加了有关WebSocket协议的相关api，所以只要实现了HTML5标准的客户端，就可以与支持WebSocket协议的服务器进行全双工的持久通信了。 WebSocket 与 HTTP 的区别 WebSocket 与 HTTP的关系图： 相同点： 都是一样基于TCP的，都是可靠性传输协议。都是应用层协议。 ...