面试

Codable 是 Swift 4 引入的序列化方案，官方定位是替代 Objective-C 时代的 NSCoding、以及各种第三方字典转模型框架（MJExtension、YYModel、JSONModel 等）。与运行时反射方案不同，Codable 通过"编译器自动合成 + 标准库协议抽象 + 具体格式实现"三层解耦，在编译期就把类型与序列化逻辑绑定好，兼具类型安全、性能和扩展性。 本文基于以下 Swift 源码展开分析： 协议定义：swift/stdlib/public/core/Codable.swift 编译器合成：swift/lib/Sema/DerivedConformanceCodable.cpp、DerivedConformanceCodingKey.cpp Foundation 实现：swift-corelibs-foundation/Sources/Foundation/JSONEncoder.swift、JSONDecoder.swift、PropertyListEncoder.swift 整体架构 在开始深入之前，先建立整体印象。Codable 可以拆成三层角色： 用户类型层：业务中的 struct / class / enum，声明遵循 Codable 标准库与编译器层：标准库定义 Encodable / Decodable / Encoder / Decoder 等协议，编译器为符合条件的类型合成 encode(to:) 和 init(from:) 格式实现层：Foundation 或第三方提供具体 Encoder / Decoder，负责把容器操作落到 JSON、Plist、BSON 等格式上 flowchart LR subgraph L1[用户类型层] A[struct / class / enum声明遵循 Codable] end subgraph L2[标准库与编译器层] B[Encodable / Decodable协议要求] C["编译器合成encode(to:) / init(from:)"] D[Encoder / Decoder容器协议] B --> C C --> D end subgraph L3[格式实现层] E[JSONEncoder / JSONDecoderPropertyListEncoder / 第三方实现] F[Data / 字符串 / 其他格式] E --> F end A -->|conforms to| B D -->|由具体类型实现| E 核心思想是：标准库只定义"如何描述一个可编码类型"和"编码器需要提供什么能力"，具体的格式（JSON、Plist、BSON…）由 Foundation 或第三方实现。用户类型只需要遵循协议，剩下的由编译器在 SIL 层自动生成。 ...

React Native 是 Meta 2015 年开源的跨平台框架，用 JavaScript/TypeScript 写一份业务代码，在 iOS 和 Android 上渲染出真正的原生控件（UIView / android.view.View），而不是像 Flutter 那样自绘，也不是像 H5 那样跑在 WebView 里。经过 2018~2024 年的"新架构"大重构，RN 在 0.76 让 New Architecture（Fabric + TurboModules + JSI + Codegen + Bridgeless）成为默认，并在 0.82（2025 年 10 月）彻底告别旧的 Bridge 时代——这是 RN 十年来最大的一次范式迁移。 对 iOS 开发者而言，RN 的定位很特殊：UI 仍然是 UIKit，但控制 UI 的大脑换成了 JS。这让它一方面拥有"原生 Look & Feel“的天然优势（iOS 26 Liquid Glass 不用等框架跟进），另一方面又背负着”JS/原生边界抖动“的原罪。在 AI Coding 时代，RN 凭借 Web 生态庞大的训练语料和 Expo 工具链成为 LLM 生成代码正确率最高的移动框架，但 JSI 的 C++ 层和 Bridgeless 的新调试链路也让"AI 修 Bug"变得比以前更难。 ...

概述 SOLID 是面向对象设计的五大基本原则的首字母缩写，由 Robert C. Martin（Uncle Bob）在 2000 年代初期提出。这五个原则是构建可维护、可扩展软件的基础，在 iOS 开发中同样适用。 字母 原则 英文名称 S 单一职责原则 Single Responsibility Principle O 开放封闭原则 Open-Closed Principle L 里氏替换原则 Liskov Substitution Principle I 接口隔离原则 Interface Segregation Principle D 依赖倒置原则 Dependency Inversion Principle 单一职责原则（Single Responsibility Principle, SRP） 定义 A class should have one, and only one, reason to change. 一个类应该只有一个引起它变化的原因。 原则解读 单一职责原则要求每个类只负责一项职责。这里的"职责"可以理解为"变化的原因"——如果你能想到多于一个的原因去改变一个类，那么这个类就有多于一个的职责。 核心思想：将不同的关注点分离，使每个模块只专注于做好一件事。 解决的问题 1. 代码耦合度高 当一个类承担多个职责时，这些职责会相互依赖、相互影响。修改其中一个职责的代码，可能会无意中破坏另一个职责的功能。 2. 难以复用 如果一个类混合了多个职责，当你只想使用其中一个职责时，不得不引入整个类及其所有依赖。 3. 维护困难 职责混杂的类通常代码量大、逻辑复杂，理解和修改都很困难。不同职责的代码交织在一起，修改一处可能产生意想不到的连锁反应。 4. 测试复杂 ...

前言 iOS 上的 WebView 目前以 WKWebView 为事实标准。它对外表现得像一个 UIView 子类，但内部其实对接着整个 WebKit 引擎——一个由多个独立进程协作的庞大系统。日常开发中遇到的那些困扰：为什么 Web 页白屏不会把 App 带崩？为什么 Cookie 和 App 自身的 NSHTTPCookieStorage 总是对不上？为什么 JS 调用 Native 永远是异步？为什么 NSURLProtocol 拦不到 WKWebView 的请求？这些问题单看 API 都得不到答案，必须下潜到 WebKit 源码里才能看清楚。 好在 WebKit 是 Apple 官方开源的项目，仓库在 github.com/WebKit/WebKit。本文基于其 Source/ 目录下的公开源码，按"源码地图 → 多进程架构 → 各进程职责 → 全链路串联 → 工程启示"的顺序，把 WKWebView 从创建到渲染一帧的底层机制梳理清楚。 一、先看源码地图 阅读源码前，先在脑子里建立目录结构。以 WebKit/WebKit 仓库的 Source/ 目录为例： Source/ ├── JavaScriptCore/ # JS 引擎（解释器、JIT 编译器、GC） ├── WebCore/ # 渲染引擎核心（DOM、CSSOM、Layout、Paint） ├── WebKit/ # 多进程框架 + Cocoa 层 API │ ├── UIProcess/ # 主进程侧（App 进程） │ │ ├── API/Cocoa/ # WKWebView.mm、WKProcessPool.mm 等 │ │ ├── API/ios/ # WKWebViewIOS.mm │ │ ├── ios/ # WKContentView.mm、WebPageProxyIOS.mm │ │ └── ... │ ├── WebProcess/ # 渲染进程侧（WebContent） │ ├── NetworkProcess/ # 独立网络进程 │ ├── GPUProcess/ # 独立 GPU 进程 │ └── Shared/ # 跨进程共享的数据结构、IPC 消息定义 └── WTF/ # 基础容器、线程、字符串工具库 日常 iOS 开发能看到的 WKWebView，对应的实现就在 Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm。它是一个 Objective-C++ 文件，内部只是持有一个 C++ 的 WebPageProxy 对象，几乎所有实际工作都转发给它。为什么要这样设计？原因就藏在下一节要讲的多进程架构里。 ...

定义 命令模式（Command Pattern）是一种行为型设计模式，它将请求封装成对象，从而可以用不同的请求对客户进行参数化，对请求排队或记录请求日志，以及支持可撤销的操作。 命令模式的核心思想是：将"请求"封装成一个对象，使得可以用不同的请求、队列或日志来参数化其他对象，同时支持可撤销操作。 为什么需要命令模式 命令模式要解决的核心问题是：将请求（操作）封装成对象，使得可以对请求进行存储、传递、撤销等操作。 问题场景：假设我们正在开发一个文本编辑器，需要支持撤销/重做功能。 最直接的方式可能是这样： class TextEditor { var text: String = "" func insertText(_ newText: String, at position: Int) { let index = text.index(text.startIndex, offsetBy: position) text.insert(contentsOf: newText, at: index) } func deleteText(from start: Int, length: Int) { let startIndex = text.index(text.startIndex, offsetBy: start) let endIndex = text.index(startIndex, offsetBy: length) text.removeSubrange(startIndex..<endIndex) } } // 用户操作 let editor = TextEditor() editor.insertText("Hello", at: 0) editor.insertText(" World", at: 5) editor.deleteText(from: 5, length: 6) // 如何实现撤销？需要记住每次操作的类型、参数、以及如何逆向执行 // 这变得非常复杂... 这种方式有什么问题？ ...

← 第 2 轮 · 返回本次面经 · 已是最后一轮 → 本轮概述： 这一轮主要考察了小程序的低代码设计架构、Web Worker的使用、中台系统的微前端拆分策略等方面的知识。 本轮共 4 道题。答案默认折叠，便于先自行作答。 1. 讲一下你关于小程序的低代码设计架构 题目要点 小程序低代码架构本质是配置驱动的运行时体系，核心包括 DSL 协议设计、组件注册机制、运行时解析与数据驱动更新；必须围绕 setData 性能约束进行差量更新与渲染优化；工程重点不在编辑器，而在运行时引擎的性能治理与扩展能力设计。 参考答案 小程序的低代码架构，本质是在受限运行环境下实现“可配置驱动 UI 与逻辑”。核心不是拖拽能力，而是如何让页面结构、交互逻辑、数据流都由配置驱动，同时保证性能与可维护性。 一、整体架构分层 小程序低代码一般分为四层： 编辑层 → DSL 层 → 运行时引擎 → 渲染层 编辑层负责产出结构化配置；DSL 层定义组件树与属性协议；运行时负责解析与调度；渲染层落在小程序原生组件体系之上（如 WXML + setData 机制，在 微信小程序 中即运行于其渲染框架内）。 关键问题在于：小程序不是虚拟 DOM 模型，而是逻辑层与视图层分离，通过 JSON 数据桥接，因此架构必须围绕数据驱动。 二、DSL 设计 DSL 通常采用 JSON Schema 形式，核心包含： 组件类型 属性 props 样式 事件绑定 数据源 条件显示规则 低代码的关键在于“协议稳定性”，一旦 DSL 设计混乱，后续扩展成本会极高。因此会设计： 组件注册机制 属性校验规则 默认值策略 版本兼容策略 三、运行时引擎 运行时是核心。 ...

HTTP 协议中定义了多种 请求方法（HTTP Methods），用于客户端和服务器之间进行不同的操作。 一、常用的 HTTP 方法 方法 是否幂等 是否安全 说明 GET ✅ 幂等 ✅ 安全 获取资源。请求参数放在 URL 上。不会对资源产生副作用。 POST ❌ 非幂等 ❌ 不安全 提交数据（如表单、上传），可能导致资源变化或创建。 PUT ✅ 幂等 ❌ 不安全 用于整体更新某个资源（数据完全替换）。 PATCH ❌ 非幂等 ❌ 不安全 用于部分更新资源（只改动部分字段）。 DELETE ✅ 幂等 ❌ 不安全 删除指定资源。 二、幂等性和安全性解释 幂等（Idempotent）：同一个请求重复执行多次，结果应一样。例如多次 DELETE 相同资源结果相同。 安全（Safe）：不对服务器资源造成副作用。GET 只查询，不修改数据，因此是安全的。 三、其他常见 HTTP 方法 方法 说明 HEAD 类似 GET，但不返回响应体，只返回响应头。常用于检测资源是否存在、获取响应信息。 OPTIONS 用于客户端获取服务器支持哪些方法。也是 CORS 预检请求的一部分。 TRACE 回显服务器收到的请求，主要用于调试。很少使用，可能存在安全隐患。 CONNECT 用于建立隧道（如 HTTPS 的代理通信）。 四、使用场景示例 场景 方法 示例 获取用户列表 GET GET /api/users 创建用户 POST POST /api/users 更新用户信息 PUT / PATCH PUT /api/users/1 或 PATCH /api/users/1 删除用户 DELETE DELETE /api/users/1 总结：记住这几点 GET 用于查询（安全、幂等）。 POST 用于新增（不幂等）。 PUT/PATCH 用于修改资源（PUT 是整体替换，PATCH 是部分更新）。 DELETE 用于删除资源（幂等，但不安全）。 OPTIONS/HEAD 用于辅助请求。 常见考点 1. 语义理解 每个方法在 RESTful API 中代表的含义？ PUT 和 PATCH 的区别？ GET 和 POST 区别？是否可以用 POST 替代 GET？ 2. 幂等性与安全性 哪些方法是幂等的？（调用多次结果一致） 哪些方法是安全的？（不会对服务器资源产生副作用） 3. 浏览器行为 表单默认提交方式是什么？（GET 或 POST） GET 请求能携带 body 吗？（规范上不能，但部分浏览器允许） 4. 缓存行为 浏览器对 GET、POST 的缓存行为有什么区别？ 为什么 GET 更适合缓存？ 5. 跨域相关（CORS） 哪些方法属于“简单请求”？ 使用 PUT/PATCH/DELETE 会触发预检请求（OPTIONS），为什么？ 6. 请求体与响应体 哪些方法通常不携带请求体？（如 GET、DELETE） 哪些方法可以/需要携带请求体？（如 POST、PUT、PATCH） 7. 对比和实际使用中的陷阱 PUT/POST 混用的场景（如某些系统用 POST 实现更新） DELETE 是否要有请求体？（规范允许，但不推荐） 可能的延伸考察 RESTful API 设计规范 REST API 中，如何正确使用 GET/POST/PUT/DELETE 等方法？ 设计一个增删改查接口，如何对应到不同 HTTP 方法？ 状态码与方法配合 DELETE 成功一般返回什么状态码？（如 204 No Content） POST 创建资源后返回什么？（201 Created） 结合安全问题 POST/PUT 方法可能面临哪些安全风险？如 CSRF？ 为什么建议对非幂等方法加 CSRF 防护？

state 基本定义 state是组件内部的状态（数据），不能够直接修改，必须要通过setState来改变值的状态，从而达到更新组件内部数据的作用。 props 基本定义 props是指组件间传递的一种方式，props自然也可以传递state。由于React的数据流是自上而下的，所以是从父组件向子组件进行传递；另外组件内部的this.props属性是只读的不可修改。 代码示例 // 父组件 import stateJj from './stateJj.js'; // 引入子组件 class stateJjFather extends React.Component { constructor(props) { super(props); // 设置state的默认值 且只能在constructor中设置 this.state = { mes: '给子组件的信息', obj： { }, arr: [] } } fun(e) { } render() { const {mes, obj, arr} = this.state; return ( <div> // 不写箭头函数 this指向会发生错误 也可以使用bind的方式绑定this <stateJj name={'给子组件的信息'} name1={mes} fun={(e) => this.fun(e)} obj={obj} arr={arr} /> </div> ); } } // 子组件 class stateJj extends React.Component { constructor(props) { super(props); this.props; // 这里面就有父组件传的值 // 设置 默认state this.state = { text: props.initialValue || 'placeholder' }; // ES6 类中函数必须手动绑定 this.handleChange = this.handleChange.bind(this); } handleChange(event) { this.setState({ text: event.target.value }); } render() { return ( <div> {mes} </div> ); } } // 设置props值的类型 stateJj.propTypes = { optionalArray: PropTypes.array, optionalBool: PropTypes.bool, optionalFunc: PropTypes.func, optionalNumber: PropTypes.number, optionalObject: PropTypes.object, optionalString: PropTypes.string, optionalSymbol: PropTypes.symbol, // 目前可以声明的所有变量类型 }; // 设置默认的props值 stateJj.defaultProps = { }; props的特性 只读性 props经常被用作渲染组件和初始化状态，当一个组件被实例化之后，它的props是只读的，不可改变的。如果props在渲染过程中可以被改变，会导致这个组件显示的形态变得不可预测。只有通过父组件重新渲染的方式才可以把新的props传入组件中。 ...

浏览器的垃圾回收（Garbage Collection, GC）机制是前端性能优化和内存管理的重要基础。 一、垃圾回收的基本概念 目的：自动回收不再使用的内存，避免内存泄漏，保证浏览器性能稳定。 GC 触发：当浏览器检测到内存不足或特定条件时，启动垃圾回收过程。 二、主要垃圾回收算法 1. 标记清除（Mark-and-Sweep） 浏览器从**根对象（Global、执行上下文中的变量）**开始，标记所有可达对象。 没被标记的对象被认为不可达，即不再被使用，进行回收。 是现代 JS 引擎普遍采用的算法。 2. 引用计数（Reference Counting） 每个对象维护引用计数，引用增加时计数+1，引用消失时计数-1。 计数为 0 的对象立即回收。 缺陷：无法处理循环引用，现代引擎一般不单独使用。 三、垃圾回收的触发时机 内存分配达到一定阈值时自动触发。 主动调用相关接口（如 Chrome DevTools 手动触发）。 页面卸载时进行清理。 四、内存泄漏常见原因 全局变量未释放 全局变量一直被引用，无法回收。 闭包导致的变量无法释放 闭包作用域内变量被外部引用。 定时器未清除 setInterval、setTimeout 未正确清除，导致引用保留。 DOM 节点引用未释放 JS 中持有对已删除 DOM 的引用。 事件监听未移除 绑定事件后，未及时解绑，导致内存无法回收。 五、性能优化建议 避免不必要的全局变量。 使用完定时器及时清除。 解绑不再使用的事件监听。 谨慎使用闭包，避免无用变量持久存在。 小心操作 DOM，及时释放引用。 常见考点 面试中考察点主要包括 GC 的原理、算法、触发时机、内存泄漏原因及避免方法： 浏览器垃圾回收的原理和常见算法？ 标记清除与引用计数的区别与优缺点？ 什么是内存泄漏？常见的内存泄漏类型？ 如何避免内存泄漏？ JS 引擎如何判断对象是否可回收？ 浏览器中 GC 触发的时机？ 如何用 Chrome DevTools 监测内存泄漏？ 事件监听和闭包如何导致内存泄漏？

前言 JavaScript 是一种非常灵活的编程语言，它允许开发者在代码中进行各种类型的操作和转换。其中，显式和隐式类型转换是 JavaScript 中一个重要而又常见的概念。你是否曾经遇到过 JavaScript 中奇怪的类型转换行为？当你使用加号连接两个不同类型的值时，为什么有时候会得到意料之外的结果？为了更好地理解 JavaScript 中的这些行为，我本篇文章将带大家深入探讨显式和隐式类型转换。 数据类型 首先简单了解下有哪些数据类型。 原始数据类型：String、Number、Boolean、Symbol、Undefined、Null、BigInt（本文不讨论BigInt、Symbol） 引用数据类型: Object（引用类型指向一个对象，不是原始值，指向对象的变量是引用变量） 类型转换 数据类型之间的转换可以分为下面三种： 原始数据类型之间的转换。 原始数据类型转换为对象。 对象转换为原始数据类型。 1.1 原始数据类型转Number console.log(Number('123')); // 123 console.log(Number(true)); // 1 console.log(Number(undefined)); // NaN console.log(Number(null)); // 0 我们可以直接调用Number()函数来进行转换。该函数会把undefined转换为NaN，将null转换为0。 而对于字符串，如果字符串中仅仅包含数字，则将转换为数字，若包含非数字字符，则返回NaN。我们也可以使用parseInt()来转换字符串。 console.log(parseInt('123')); // 123 console.log(parseInt('12.3')); // 12 console.log(parseInt('12ds8'));// 12 console.log(parseInt('ads25')); // NaN parseInt()只解析整数部分，忽略小数部分。parseFloat()可以将字符串转换为浮点数的函数。 1.2 原始数据类型转String console.log(String());//'' console.log(String(123));//'123' console.log(String(NaN));//NaN console.log(String(undefined));//undefined console.log(String(null));//null console.log(String(true));//true 我们可以使用String() 构造函数将任何类型的数据转换为字符串类型。它将接收到的参数转换为对应的字符串表示形式。 1.3 原始数据类型转Boolean console.log(Boolean());// false console.log(Boolean('Ywis'));// tru console.log(Boolean(123));// true console.log(Boolean(NaN));// false console.log(Boolean(undefined));// false console.log(Boolean(null));// false console.log(Boolean(true));// true 调用Boolean()函数进行转换。在将非布尔值类型转换为布尔值类型时，有一个总结： false：布尔值 false undefined：未定义的值 null：空值 0：数字 0 -0：负零 NaN：非数字值 ''：空字符串 除了以上七个值外，其他值（包括对象、数组、函数等）在转换为布尔值时都会返回 true。这种规则使得 JS 中的大多数值被视为真值（truthy）。 ...