面试

一、什么是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的，都是可靠性传输协议。都是应用层协议。 联系： WebSocket在建立握手时，数据是通过HTTP传输的。但是建立之后，在真正传输时候是不需要HTTP协议的。 下面一张图说明了 HTTP 与 WebSocket 的主要区别： ...

本文详细介绍 iOS 中三种布局方式（Frame、Auto Layout、UIStackView）的原理和对比，视图更新的三个阶段（约束、布局、绘制），UIView 与 CALayer 的关系和区别，以及 updateConstraints、layoutSubviews、setNeedsLayout、layoutIfNeeded、setNeedsDisplay 等相关方法的作用、调用时机和区别。 iOS 布局方式 iOS 提供了三种主要的布局方式，按出现时间排列： 布局方式 引入版本 核心思想 API Frame 布局 iOS 2 直接指定视图的位置和大小 frame、bounds、center Auto Layout iOS 6 通过约束描述视图间关系，系统自动计算 frame NSLayoutConstraint、Anchor API UIStackView iOS 9 线性排列子视图，自动管理约束 UIStackView Frame 布局 直接通过设置 frame 属性来确定视图的位置和大小，是最基础的布局方式。 let label = UILabel() label.frame = CGRect(x: 20, y: 100, width: 200, height: 44) view.addSubview(label) 优点：性能最好（无需约束求解），逻辑直观，完全可控。 缺点：需要手动计算所有数值，难以适配不同屏幕尺寸和动态内容，维护成本高。 适用场景：简单固定布局、性能敏感的场景（如 UITableViewCell 内大量视图手动布局）、需要频繁更新 frame 的动画。 Auto Layout Auto Layout 是基于 约束（Constraint） 的布局系统。开发者不直接设置 frame，而是描述视图之间的关系（如"A 的左边距 B 右边 16pt"），系统通过求解约束方程组自动计算出每个视图的 frame。 ...

说到设计模式，大家想到的就是六大原则，23种模式。这么多模式，并非都要记住，但作为前端开发，对于前端出现率高的设计模式还是有必要了解并掌握的，浅浅掌握9种模式后，整理了这份文章。 那么，我们先了解六大原则 六大原则： 依赖倒置原则(Dependence Inversion Principle)：高层(业务层)不应该直接调用底层(基础层)模块 开闭原则(Open Close Principle)：单模块对拓展开放、对修改关闭 单一原则(Single Responsibility Principle)：单模块负责的职责必须是单一的 迪米特法则(Law of Demeter)：对外暴露接口应该简单 接口隔离原则(Interface Segregation Principle)：单个接口(类)都应该按业务隔离开 里氏替换原则(Liskov Substitution Principle)：子类可以替换父类 六大原则也可以用六个字替换：高内聚低耦合。 高层不直接依赖底层：依赖倒置原则 内部修改关闭，外部开放扩展：开闭原则 聚合单一功能：单一原则 低知识接口，对外接口简单：迪米特法则 耦合多个接口，不如隔离拆分：接口隔离原则 合并复用，子类可以替换父类：里氏替换原则 我们采用模式编写时，要尽可能遵守这六大原则 23 种设计模式分为“创建型”、“行为型”和“结构型” 前端九种设计模式 一、创建型 创建型从功能上来说就是创建元素，目标是规范元素创建步骤 1.构造器模式：抽象了对象实例的变与不变(变的是属性值，不变的是属性名) // 需求：给公司员工创建线上基本信息 // 单个员工创建，可以直接使用创建 const obj = { name:'张三', age:'20', department:'人力资源部门' } // 可员工的数量过于多的时候，一个个创建不可行，那么就可以使用构造器模式 class Person { constructor(obj){ this.name = obj.name this.age = obj.age this.department = obj.department } } const person1 = new Person(obj) 2. 工厂模式：为创建一组相关或相互依赖的对象提供一个接口，且无须指定它们的具体类 即隐藏创建过程、暴露共同接口。 // 需求：公司员工创建完信息后需要为每一个员工创建一个信息名片 class setPerson { constructor(obj) { this.pesonObj = obj } creatCard() { //创建信息名片 } otherFynction(){ } } class Person { constructor(obj) { return new setPerson(obj) } } const person = new Person() const card = person.creatCard({ name:'张三', age:'20', department:'人力资源部门' }) 3. 单例模式：全局只有一个实例，避免重复创建对象，优化性能 // 需求：判断一款应用的开闭状态，根据不同状态给出不同提示 class applicationStation { constructor() { this.state = 'off' } play() { if (this.state === 'on') { console.log('已打开') return } this.state = 'on' } shutdown() { if (this.state === 'off') { console.log('已关闭') return } this.state = 'off' } } window.applicationStation = new applicationStation() // applicationStation.instance = undefined // applicationStation.getInstance = function() { // return function() { // if (!applicationStation.instance) { // 如果全局没有实例再创建 // applicationStation.instance = new applicationStation() // } // return applicationStation.instance // }() // } // application1和application2拥有同一个applicationStation对象 const application1 = window.applicationStation const application2 = window.applicationStation 二、结构型 结构型从功能上来说就是给元素添加行为的，目标是优化结构的实现方式 ...

iOS开发中，理解各种生命周期是非常重要的基础知识。本文将详细介绍应用生命周期、UIViewController生命周期、UIView生命周期，以及其他常见的生命周期。 应用生命周期（App Lifecycle） 应用状态 iOS应用有五种运行状态： 状态 描述 Not Running 应用未启动或已被系统终止 Inactive 应用在前台运行但未接收事件（如来电、锁屏时的过渡状态） Active 应用在前台运行并接收事件，这是应用的正常运行状态 Background 应用在后台执行代码，通常只有短暂的执行时间 Suspended 应用在后台但不执行代码，系统会在内存不足时自动终止该状态的应用 状态转换图 stateDiagram-v2 [*] --> Not_Running Not_Running --> Inactive : 启动 Inactive --> Active Active --> Background Background --> Inactive Background --> Suspended Suspended --> [*] UIApplicationDelegate 方法（iOS 12及之前） 在iOS 12及之前的版本中，应用生命周期主要通过UIApplicationDelegate协议来管理： // 应用启动完成 func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { // 初始化配置、第三方SDK等 return true } // 应用即将进入非活动状态 func applicationWillResignActive(_ application: UIApplication) { // 暂停正在进行的任务、禁用定时器 // 游戏应该在此暂停 } // 应用已进入后台 func applicationDidEnterBackground(_ application: UIApplication) { // 释放共享资源、保存用户数据 // 可以请求额外的后台执行时间 } // 应用即将进入前台 func applicationWillEnterForeground(_ application: UIApplication) { // 撤销进入后台时所做的更改 } // 应用已变为活动状态 func applicationDidBecomeActive(_ application: UIApplication) { // 重启被暂停的任务 // 如果应用之前在后台，可以刷新UI } // 应用即将终止 func applicationWillTerminate(_ application: UIApplication) { // 保存数据、清理资源 // 注意：如果应用从Suspended状态被终止，此方法不会被调用 } UISceneDelegate 方法（iOS 13+） 从iOS 13开始，Apple引入了Scene-based生命周期，支持多窗口场景。 ...

类型擦除（Type Erasure）是一种编程技术，用于在运行时隐藏具体的类型信息，使得不同类型可以通过统一的接口进行操作。在iOS开发中，Objective-C和Swift都有类型擦除的概念，但实现方式和应用场景有所不同。 Swift中的类型擦除 Swift是一门强类型语言，类型信息在编译时被严格检查。但在某些场景下，我们需要隐藏具体类型信息，这时就需要使用类型擦除技术。 存在类型与不透明类型 在理解类型擦除之前，需要先理解 Swift 类型系统中两个关键概念：存在类型（Existential Type） 和不透明类型（Opaque Type）。它们是协议在类型层面的两种使用方式，也是理解 any 和 some 关键字的基础。 存在类型（Existential Type） “存在类型"这个术语来自类型论中的存在量词（∃）。它表达的语义是：“存在某个类型 T 遵循了协议 P，但我不知道也不关心 T 具体是什么。” 当你把一个协议当作类型来使用时（而非泛型约束），你就在使用存在类型： protocol Animal { func makeSound() -> String } struct Dog: Animal { func makeSound() -> String { "Woof!" } } struct Cat: Animal { func makeSound() -> String { "Meow!" } } // animals 数组中的每个元素都是存在类型 // 编译器不知道每个元素的具体类型，只知道"存在某个类型遵循了 Animal" var animals: [any Animal] = [Dog(), Cat()] 存在类型的核心特征： 运行时多态：具体类型在运行时才确定，同一个变量可以在不同时刻持有不同的具体类型 有性能开销：Swift 通过存在容器（Existential Container）来存储值，方法调用需要通过见证表间接派发 类型信息被隐藏：调用方只能通过协议接口与值交互，无法访问具体类型的特有成员 在 Swift 5.6 之前，直接把协议写成类型（如 let x: Animal）就是存在类型，但语法上没有任何标记。Swift 5.6 引入 any 关键字使其变得显式，目的是提醒开发者这里存在运行时开销。Swift 5.7 起，对于带有关联类型的协议，必须使用 any 才能作为存在类型。 ...

网络分层模型 OSI七层模型 OSI（Open Systems Interconnection）是国际标准化组织提出的网络通信参考模型： 层级 名称 功能 协议/设备举例 7 应用层 为应用程序提供网络服务 HTTP, FTP, DNS, SMTP 6 表示层 数据格式转换、加密/解密 SSL/TLS, JPEG, ASCII 5 会话层 建立、管理和终止会话 RPC, SQL 4 传输层 端到端的可靠数据传输 TCP, UDP 3 网络层 路由选择与IP寻址 IP, ICMP, ARP 2 数据链路层 帧的封装与MAC寻址 Ethernet, Wi-Fi 1 物理层 比特流的物理传输 光纤, 双绞线 TCP/IP四层模型 实际工程中更常用的是TCP/IP四层模型，它将OSI的上三层合并为应用层，下两层合并为网络接口层： graph TB subgraph "TCP/IP四层模型" A["应用层HTTP, DNS, FTP, SMTP"] B["传输层TCP, UDP"] C["网络层IP, ICMP, ARP"] D["网络接口层Ethernet, Wi-Fi"] end subgraph "OSI七层模型" E["应用层"] F["表示层"] G["会话层"] H["传输层"] I["网络层"] J["数据链路层"] K["物理层"] end A --- E A --- F A --- G B --- H C --- I D --- J D --- K 数据封装与解封装 数据在发送方从上到下逐层封装，每一层都将上层传来的数据视为载荷（Payload），在其前面添加本层的头部信息（部分层还会添加尾部信息），然后交给下一层处理。接收方则从下到上逐层解封装，每一层剥离本层头部后将载荷交给上层。 ...

共 119 道 Agent 面试题。答案默认折叠，便于先自行作答。 1. 如何设计一个企业级 AI Agent 平台？ 难度：3.5 · 类型：QA 题目要点 企业级 AI Agent 平台的设计重点不是“接一个大模型接口”，而是围绕业务任务构建完整体系：前端提供可解释、可配置、可监控的交互体验；中间层负责 Agent 编排、工具调用和知识增强；底层统一管理模型、数据和企业系统；治理层保障权限、安全、审计、评测和成本控制。真正可落地的平台，一定是在智能能力和工程确定性之间取得平衡。 参考答案 企业级 AI Agent 平台不能只设计成一个“聊天入口”，更应该设计成一个可治理、可扩展、可观测的智能任务执行平台。它的核心目标是让企业可以安全地把大模型能力接入真实业务流程，例如客服、知识检索、数据分析、代码辅助、审批流、运营自动化等场景。 从架构上看，可以分为四个关键层次：前端体验层、Agent 编排层、能力接入层和企业治理层。 前端体验层不应该只有 Chat UI，而要支持多种交互形态。对于普通用户，可以提供对话式入口、任务面板、历史记录、引用来源、执行进度和人工确认节点；对于业务管理员，需要有 Agent 配置台，可以配置角色、Prompt、工具权限、知识库、工作流、触发条件和发布版本；对于运维和安全人员，则需要看到调用链路、成本消耗、失败原因、审计日志和风险拦截记录。 Agent 编排层是平台的核心。这里不能简单地把用户输入直接发给模型，而是要经过意图识别、上下文构建、计划拆解、工具选择、执行反馈和结果汇总。复杂任务通常需要支持多 Agent 协作，例如一个 Agent 负责理解需求，一个 Agent 负责查知识库，一个 Agent 负责调用业务系统，还有一个 Agent 负责校验输出质量。对于企业场景，工作流式 Agent 和自主规划式 Agent 往往要结合使用：高风险业务用确定性流程约束，低风险探索任务可以给 Agent 更高自主度。 能力接入层主要解决模型、知识和工具的问题。模型层需要做统一网关，屏蔽不同模型厂商差异，支持模型路由、降级、限流、重试和成本统计。知识层通常采用 RAG 架构，需要处理文档解析、切片、向量化、权限过滤、召回排序和答案引用，避免 Agent 编造来源。工具层则要把企业内部系统封装成标准 Tool，例如 CRM、工单、审批、BI、代码仓库、飞书、邮件、数据库等，同时每个工具都要有清晰的输入输出 Schema、权限边界和幂等设计。 企业级平台最容易被低估的是治理能力。Agent 一旦可以调用工具，就不再只是“生成文本”，而是在执行真实操作，所以必须有权限控制、数据脱敏、敏感词策略、操作审计、人工确认和回滚机制。例如查询类工具可以自动执行，但转账、删除、发公告、修改生产配置这类操作必须进入 human-in-the-loop 流程。平台还需要支持租户隔离、部门权限、知识库权限继承和操作留痕。 前端设计上，要重点解决“可解释”和“可控”。用户不能只看到一个最终答案，而应该能看到 Agent 做了哪些步骤、用了哪些知识、调用了哪些工具、哪些地方失败了、是否需要用户确认。对于长任务，要有状态机式的任务视图，而不是让用户一直等在输入框前。对于企业用户来说，信任感往往来自透明度，而不是更拟人的回复。 另外，平台需要内置评测体系。Agent 发布前要经过离线评测，例如准确率、召回率、幻觉率、工具调用成功率、越权风险和响应时延；上线后要持续收集用户反馈、人工纠错、失败样本和成本数据，再反向优化 Prompt、知识库、工具描述和模型路由。没有评测闭环的 Agent 平台，很难在企业里长期稳定运行。 ...

共 43 道 AI相关 面试题。答案默认折叠，便于先自行作答。 1. 如何实现 ChatGPT 类似的流式输出？ 难度：1.5 · 类型：QA 题目要点 流式输出的核心是服务端通过 SSE、fetch stream 或 WebSocket 持续返回增量内容，前端通过 ReadableStream 边读边渲染。实现时要注意网络 chunk 不等于完整消息，需要做缓冲和协议解析。前端渲染要做节流，避免频繁状态更新导致卡顿。Agent 场景下建议使用结构化事件协议，把文本增量、工具调用、状态、错误、完成信号分开处理。最后还要支持取消、错误恢复、最终 Markdown 校正和滚动体验，才能达到接近 ChatGPT 的交互质量。 参考答案 类似 ChatGPT 的流式输出，本质是：服务端不要等完整答案生成后再返回，而是把模型生成的 token 或文本片段持续写入 HTTP 响应；前端边读边渲染，并在完成、取消、异常时维护好状态。 实际项目里最常见的是 SSE 或 fetch + ReadableStream。如果只是服务端向前端单向推送，SSE 足够稳定；如果需要双向实时交互，比如语音、多人协作、实时 Agent 控制，可以用 WebSocket。在 ChatGPT 这类文本生成场景中，fetch 读取流也很常用，因为它支持 POST、请求体、鉴权、AbortController，控制能力比原生 EventSource 更强。 前端核心代码大致是这样： async function streamChat(messages: any[], onDelta: (text: string) => void) { const controller = new AbortController(); const response = await fetch('/api/chat/stream', { method: 'POST', headers: { 'Content-Type': 'application/json', }, body: JSON.stringify({ messages }), signal: controller.signal, }); if (!response.ok || !response.body) { throw new Error('stream request failed'); } const reader = response.body.getReader(); const decoder = new TextDecoder('utf-8'); let buffer = ''; while (true) { const { value, done } = await reader.read(); if (done) break; buffer += decoder.decode(value, { stream: true }); const events = buffer.split('\n\n'); buffer = events.pop() || ''; for (const event of events) { const line = event .split('\n') .find((item) => item.startsWith('data:')); if (!line) continue; const data = line.replace(/^data:\s*/, ''); if (data === '[DONE]') { return; } const payload = JSON.parse(data); if (payload.type === 'delta') { onDelta(payload.content); } } } controller.abort(); } 服务端返回时通常使用类似这样的协议： ...

共 114 道 CSS 面试题。答案默认折叠，便于先自行作答。 1. Tailwind 的响应式断点（如 md:）底层如何实现？ 难度：2 · 类型：QA 题目要点 Tailwind 的响应式断点基于构建期的变体系统实现。md: 在编译阶段被解析为 screen 变体，并根据 screens 配置生成对应的 @media (min-width) 包裹规则。所有响应式逻辑依赖原生 CSS media query，遵循 mobile-first 原则，通过规则生成管线支持多变体组合，不涉及运行时计算。 参考答案 这个问题的关键在于理解： md: 不是运行时逻辑，而是 构建期的变体（variant）展开机制。 在 Tailwind CSS 中，响应式系统建立在三个核心之上： screens 配置映射 变体解析机制 JIT 构建阶段规则生成 一、md: 本质是什么？ 当写： <div class="md:text-red-500"> Tailwind 在构建阶段会将其解析为： variant：md utility：text-red-500 然后生成如下 CSS： @media (min-width: 768px) { .md\:text-red-500 { color: #ef4444; } } 关键点： md: 只是一个前缀标记 构建阶段转换成 @media 冒号会被转义为合法 CSS 选择器 二、断点从哪里来？ 断点定义在配置文件中： ...

共 51 道 ES6 面试题。答案默认折叠，便于先自行作答。 1. 说说 Class 语法糖的底层实现 难度：3 · 类型：QA 题目要点 class 是基于函数构造器和原型链的语法封装，实例方法本质挂载在 prototype 上，继承通过 Object.create 构建原型链，同时通过构造函数原型链继承静态方法。super 依赖内部 [[HomeObject]] 机制定位父类方法。class 并未引入新的对象模型，而是在原型继承基础上增加语义约束与语法增强。 参考答案 这个问题的关键在于理解：class 并不是一种新的面向对象机制，而是对 原型继承（prototype-based inheritance） 的语法封装。底层仍然是函数构造器 + 原型链。 如果把 class 当作 Java 那种基于类的模型去理解，就会产生误解。 先看一个简单例子： class Person { constructor(name) { this.name = name; } say() { console.log(this.name); } static create(name) { return new Person(name); } } 它在底层大致等价于： function Person(name) { this.name = name; } Person.prototype.say = function () { console.log(this.name); }; Person.create = function (name) { return new Person(name); }; 一、实例方法的实现 ...