面试

AI编程工具正在重塑软件开发的工作方式。从简单的代码补全到自主完成复杂任务的编程Agent，这个领域在短短两三年内经历了巨大的变化。本文梳理AI编程工具的核心概念、工作原理和实践方法。 一、AI编程工具的演进 1.1 三代AI编程工具 graph LR G1["第一代代码补全Copilot (2021)"] --> G2["第二代对话式编程ChatGPT (2022)"] G2 --> G3["第三代编程AgentCursor/Devin (2024+)"] 代际 交互方式 能力范围 代表产品 第一代 行内补全，按Tab接受 单行/单函数级别 GitHub Copilot 第二代 对话框问答 代码片段级别 ChatGPT、Claude 第三代 Agent模式，自主执行 跨文件/跨系统级别 Cursor、Windsurf、Devin 1.2 当前主流工具对比 工具 类型 核心特点 GitHub Copilot IDE插件 最早的AI编程助手，集成在VS Code/JetBrains等主流IDE中 Cursor 独立IDE 基于VS Code深度定制，Agent模式、多文件编辑 Windsurf 独立IDE Codeium推出，强调"Flow"模式的流畅体验 Claude Code CLI工具 终端中运行的编程Agent，适合命令行工作流 Devin 云端Agent 全自主编程Agent，自带开发环境 Amazon Q Developer IDE插件 AWS深度集成，擅长云原生开发 二、AI编程工具的工作原理 2.1 代码补全的原理 代码补全是最基础的能力。以Copilot为例： graph LR CTX["上下文收集当前文件内容打开的相关文件光标位置"] --> PROMPT["构造Prompt"] PROMPT --> LLM["LLM（Codex/GPT-4）"] LLM --> SUGGEST["补全建议"] SUGGEST --> USER["用户Tab接受 / Esc拒绝"] 上下文收集是关键——模型看到的上下文越好，补全质量越高： ...

在iOS开发中，“代理"这个词通常有两层含义： 设计模式中的代理模式（Proxy Pattern）：提供目标对象的替代品或占位符，控制对目标对象的访问 iOS中的代理模式（Delegate Pattern）：一种基于协议的回调机制，用于对象间通信 虽然中文都叫"代理”，但它们是不同的设计模式，解决不同的问题。本文将两者都进行详细介绍。 一、Proxy Pattern（代理模式） 定义 代理模式（Proxy Pattern）是一种结构型设计模式，它为其他对象提供一种代理以控制对这个对象的访问。 核心思想：代理对象作为真实对象的"替身"，客户端通过代理间接访问真实对象。代理可以在访问前后添加额外逻辑，而调用者对此毫不知情。 Client → Proxy → RealSubject ↑ 控制访问 添加功能 延迟创建 关键特征： 代理对象与真实对象实现相同的接口 客户端不知道自己使用的是代理还是真实对象 代理对象持有真实对象的引用（通常是强引用） 模式结构 classDiagram class Subject { <<interface>> +request() } class RealSubject { +request() } class Proxy { -realSubject: RealSubject +request() } class Client { +useSubject() } Subject <|.. RealSubject Subject <|.. Proxy Proxy --> RealSubject : delegates to Client --> Subject : uses Proxy的类型 1. 虚拟代理（Virtual Proxy） 虚拟代理用于延迟创建开销大的对象，只有在真正需要时才创建： ...

Instruments 是 Xcode 内置的性能分析套件，基于 DTrace/Apple Trace 基础设施构建，可以对 iOS、iPadOS、macOS、watchOS、tvOS、visionOS 的应用与系统进行 CPU、内存、图形、能耗、网络、I/O 等各个维度的观测。 Xcode 26（WWDC25）对 Instruments 做了近年来最大规模的升级，重点包括： Power Profiler：全新的能耗分析工具，支持 Tethered 与 Passive 两种录制模式。 下一代 SwiftUI instrument：基于 Cause & Effect Graph 可视化状态变更到视图更新的因果链。 Processor Trace：基于 Apple Silicon 硬件特性的"全量指令级"采集（Xcode 16.3 引入，26 完善）。 CPU Counters 重做：引入 Bottleneck Analysis 方法论与 CPU Bottlenecks 模板。 Foundation Models instrument：为 FoundationModels 框架提供 Prompt / Asset Loading / Inference 分阶段观测。 Animation Hitches 重做：修正多显示器场景下的统计，数据量显著减少，处理更快。 UI 重设计：主菜单精简、Settings 页面重写、Track 次级菜单、Launch/Attach 环境变量配置。 一、Instruments 基础 1.1 启动 Instruments 的几种方式 方式 使用场景 Xcode Product → Profile（⌘I） 日常开发，自动以 Release 模式编译并附加符号 Xcode Debug Navigator 中的图表 粗略观测 CPU / Memory / Disk / Network / Energy 直接打开 Instruments.app 对已安装的 App、系统进程或已录制的 .trace 文件进行分析 命令行 xcrun xctrace record CI / 自动化性能回归 设备端 Developer Settings 的 Power Profiler 离线、无 Mac 场景采集能耗数据 Xcode 26 中，Product → Profile 会按默认 scheme 的 Profile 构建配置（通常是 Release + -O），这与 Debug 模式的数据差异很大，做性能评估时必须用 Profile 构建。 ...

Flutter 是 Google 推出的跨平台 UI 工具包，用 Dart 写一份代码即可编译到 iOS、Android、Web、macOS、Windows、Linux、嵌入式设备。它与 KMP/RN 的最大区别是"不映射到原生控件，也不跑在 WebView 里"——Flutter 自带一套 Impeller 渲染引擎，直接向 GPU（Metal / Vulkan）提交绘制命令，从按钮到滚动条的每一个像素都是自己画出来的。 这种"自绘"架构让 Flutter 拥有"双端像素级一致“的超能力，也带来了”iOS 原生设计语言永远慢半拍“的原罪。在 AI Coding 时代，Flutter 的统一性和 GenUI 生态让它成为 LLM 生成 UI 的理想容器，但端侧 AI、Liquid Glass 等 Apple 独占能力的缺失也让它在 iOS 26 时代面临新的挑战。 本文从架构出发，穿透到 Dart VM 编译链、Impeller 渲染管线、iOS 嵌入原理，再到 AI 时代的机遇与陷阱，是一篇写给 iOS 开发者的 Flutter 体系化导读。 一、Flutter 是什么 1.1 一句话定义 Flutter 是一套”声明式 UI + 自绘渲染 + AOT 原生代码“的跨平台框架： 声明式 UI：UI 是 build(context) => Widget 的纯函数结果，状态变 → 重新 build → diff → 更新。 自绘渲染：所有控件都是 Flutter 自己用 Impeller 绘制出来的，不使用 UIKit / SwiftUI 组件。 AOT 编译：发布时 Dart 代码被 gen_snapshot 编译为 ARM64 机器码，与 C++ 引擎一起链接到 Flutter.framework 内。 一句话记忆：Flutter 不是跑在 iOS 上，它是借 iOS 的一块 CAMetalLayer 画自己的东西。 ...

什么是DRY原则？ DRY（Don’t Repeat Yourself）原则是由 Andy Hunt 和 Dave Thomas 在《The Pragmatic Programmer》一书中提出的软件开发原则。 Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. 系统中的每一项知识都必须有一个单一、明确、权威的表示。 DRY 原则的核心不仅仅是"不要复制粘贴代码"，而是确保知识和逻辑在系统中只存在一处。 核心思想 知识的单一来源 DRY 原则强调的是"知识"的不重复，而非简单的"代码"不重复。知识包括： 业务规则：如"订单金额超过100元免运费" 数据结构定义：如用户模型的字段 算法逻辑：如价格计算公式 配置信息：如 API 地址、超时时间 // 违反 DRY：同一个业务规则在多处定义 class OrderService { func calculateShipping(orderAmount: Double) -> Double { if orderAmount > 100 { // 业务规则：100元以上免运费 return 0 } return 10 } } class CartViewController { func updateShippingLabel() { if cartTotal > 100 { // 重复的业务规则！ shippingLabel.text = "免运费" } else { shippingLabel.text = "运费：¥10" } } } class CheckoutViewModel { func getShippingFee() -> Double { return totalAmount > 100 ? 0 : 10 // 又是重复！ } } // 遵循 DRY：业务规则只定义一次 struct ShippingPolicy { static let freeShippingThreshold: Double = 100 static let standardShippingFee: Double = 10 static func calculateFee(for orderAmount: Double) -> Double { return orderAmount > freeShippingThreshold ? 0 : standardShippingFee } static func isFreeShipping(for orderAmount: Double) -> Bool { return orderAmount > freeShippingThreshold } } // 所有地方都使用这个单一来源 class OrderService { func calculateShipping(orderAmount: Double) -> Double { return ShippingPolicy.calculateFee(for: orderAmount) } } class CartViewController { func updateShippingLabel() { if ShippingPolicy.isFreeShipping(for: cartTotal) { shippingLabel.text = "免运费" } else { shippingLabel.text = "运费：¥\(ShippingPolicy.standardShippingFee)" } } } DRY vs WET WET 是 DRY 的反义词，常见的解释有： ...

启动类型概览 iOS应用启动分为三种类型： 启动类型 描述 特点 冷启动（Cold Launch） App完全不在内存中，需要从头开始加载 耗时最长，需要完整执行所有启动流程 热启动（Warm Launch） App在后台被挂起（Suspended），重新进入前台 最快，只需恢复App状态，不需要重新创建进程 预热启动（Pre-warm Launch） 系统预测用户可能启动App，提前在后台执行部分启动流程 iOS 15+引入，介于冷启动和热启动之间 graph LR subgraph "冷启动（耗时最长）" A1[创建进程] --> A2[加载dylib] A2 --> A3[Rebase/Bind] A3 --> A4[+load] A4 --> A5[main] A5 --> A6[首帧渲染] end subgraph "预热启动（iOS 15+）" B1[系统提前完成（后台）:创建进程 → 加载dylib → Rebase/Bind] --> B2[用户点击后执行:+load → main → 首帧渲染] end subgraph "热启动（最快）" C1[唤醒进程] --> C2[WillEnterForeground] C2 --> C3[DidBecomeActive] C3 --> C4[恢复UI] end 一、冷启动（Cold Launch） 冷启动是最完整的启动流程，也是启动优化的主要关注点。 冷启动流程概览 flowchart TD Start([App 冷启动流程]) --> PreMain subgraph PreMain["Pre-main 阶段"] direction TB A[加载可执行文件] --> B[加载动态库（包括 Swift Runtime）] B --> C[Rebase & Bind] C --> D[ObjC Runtime 初始化（类注册、Category 附加）] D --> D2[Swift Runtime 元数据注册（类型元数据、协议遵循表）] D2 --> D3[调用 +load 方法] D3 --> E[执行 Initializers（C++静态构造函数、__attribute__）] end PreMain --> MainPhase subgraph MainPhase["main 阶段"] direction TB F[main函数] --> G[UIApplicationMain] G --> H[AppDelegate回调] H --> I[首帧渲染（创建Window、RootViewController、首屏UI）] end MainPhase --> End([启动完成]) Pre-main 阶段 Pre-main阶段是指从用户点击App图标到main函数执行之前的过程，这个阶段主要由dyld（动态链接器）负责。 ...

ChatGPT能写文章、能回答问题，但你让它帮你订一张机票，它做不到。它能告诉你"你应该去携程搜一下"，但它没法真的打开网页、输入日期、比价、下单。 **AI Agent（智能体）**就是为了解决这个问题——让LLM不仅能"想"，还能"做"。Agent = LLM + 工具使用 + 自主规划 + 记忆。 一、从聊天机器人到智能体 1.1 纯LLM的局限 一个纯粹的LLM本质上是一个"无状态的文本生成器"： graph LR IN["输入文本"] --> LLM["LLM"] LLM --> OUT["输出文本"] 它有几个根本性的限制： 限制 表现 无法执行动作 不能调API、不能操作文件、不能访问数据库 无持久记忆 每次对话结束后就"忘了" 知识过时 无法获取训练数据之后的信息 无法自主规划 不能将复杂任务分解并逐步执行 单轮思考 一次生成就结束，不能自我检查和修正 1.2 Agent的定义 AI Agent是一个以LLM为"大脑"的自主系统，能够： 感知：理解用户的意图和当前环境状态 规划：将复杂目标分解为可执行的步骤 行动：调用外部工具完成具体操作 观察：获取行动的结果 反思：根据结果调整策略 graph TD USER["用户目标"] --> PERCEIVE["感知理解意图"] PERCEIVE --> PLAN["规划分解任务"] PLAN --> ACT["行动调用工具"] ACT --> OBSERVE["观察获取结果"] OBSERVE --> REFLECT["反思是否完成？"] REFLECT -->|未完成| PLAN REFLECT -->|已完成| RESULT["返回结果"] 二、Agent的核心组件 2.1 架构总览 graph TB subgraph Agent ["AI Agent"] LLM["LLM（大脑）"] PLAN["规划模块"] MEM["记忆系统"] TOOL["工具集"] end USER["用户"] --> LLM LLM --> PLAN PLAN --> LLM LLM --> MEM MEM --> LLM LLM --> TOOL TOOL --> LLM LLM --> USER 2.2 LLM：Agent的大脑 LLM负责理解、推理和决策。作为Agent大脑的LLM需要具备： ...

← 第 1 轮 · 返回本次面经 · 已是最后一轮 → 本轮概述： 该轮面试主要考察了浏览器的工作原理、缓存策略、跨域、Vue生命周期、组件通信等方面的知识。题目涉及理论知识和实际应用场景。 本轮共 14 道题。答案默认折叠，便于先自行作答。 1. 详细讲一下从url输入网址到页面渲染的过程 题库原题：简单描述从输入网址到页面显示的过程 题目要点 当输入URL到页面加载完成，发生了以下几个关键过程： DNS解析：浏览器将URL解析为对应的IP地址。这个过程涉及多级DNS服务器，从本地缓存开始，如果没有找到，则递归查询根域名服务器、顶级域名服务器，直到找到目标服务器的IP地址。 TCP连接：浏览器通过三次握手与服务器建立TCP连接。一旦连接建立，浏览器可以发送HTTP请求。 HTTP请求：浏览器构建HTTP请求报文，通过TCP连接发送到服务器。请求报文包含请求行、请求头和请求正文。 服务器处理请求：服务器接收HTTP请求，解析请求内容，执行相应的处理（如数据库查询、文件读取等），并构建HTTP响应报文。 HTTP响应：服务器将响应报文通过TCP连接发送回浏览器。响应报文包含状态码、响应头和响应正文。 浏览器解析渲染：浏览器接收到HTTP响应后，解析HTML文档构建DOM树，解析CSS构建CSSOM树，合并两者形成渲染树，然后开始渲染页面。 连接结束：当浏览器完成页面渲染或收到服务器关闭连接的信号时，浏览器会发送TCP连接关闭的信号，服务器收到后，双方断开连接。 参考答案 很多大公司面试喜欢问这样一道面试题，输入URL到看见页面发生了什么？ 简单来说，共有以下几个过程： DNS解析 发起TCP连接 发送HTTP请求 服务器处理请求并返回HTTP报文 浏览器解析渲染页面 连接结束 下面我们来看看具体的细节。 DNS解析 DNS解析实际上就是寻找你所需要的资源的过程。假设你输入www.baidu.com，而这个网址并不是百度的真实地址，互联网中每一台机器都有唯一标识的IP地址，这个才是关键，但是它不好记，乱七八糟一串数字谁记得住啊，所以就需要一个网址和IP地址的转换，也就是DNS解析。 DNS解析其实是一个递归的过程。 输入www.google.com网址后，首先在本地的域名服务器中查找，没找到去根域名服务器查找，没有再去com顶级域名服务器查找，，如此的类推下去，直到找到IP地址，然后把它记录在本地，供下次使用。大致过程就是.-> .com ->google.com. -> www.google.com.。 (最后这个.对应的就是根域名服务器，默认情况下所有的网址的最后一位都是.，为了方便用户，通常都会省略，浏览器在请求DNS的时候会自动加上) DNS优化 既然已经懂得了解析的具体过程，我们可以看到上述一共经过了N个过程，每个过程有一定的消耗和时间的等待，因此我们得想办法解决一下这个问题！ DNS缓存 DNS存在着多级缓存，从离浏览器的距离排序的话，有以下几种: 浏览器缓存，系统缓存，路由器缓存，ISP服务器缓存，根域名服务器缓存，顶级域名服务器缓存，主域名服务器缓存。 DNS负载均衡 比如访问baidu.com的时候，每次响应的并非是同一个服务器（IP地址不同），一般大公司都有成百上千台服务器来支撑访问。DNS可以返回一个合适的机器的IP给用户，例如可以根据每台机器的负载量，该机器离用户地理位置的距离等等，这种过程就是DNS负载均衡。 发起TCP连接 TCP提供一种可靠的传输，这个过程涉及到三次握手，四次挥手。 三次握手 第一次握手： 客户端发送syn包(Seq=x)到服务器，并进入SYN_SEND状态，等待服务器确认； 第二次握手： 服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（Seq=y），即SYN+ACK包，此时服务器进入SYN_RECV状态； 第三次握手： 客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。 握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。 四次挥手 数据传输完毕后，双方都可释放连接。最开始的时候，客户端和服务器都是处于ESTABLISHED状态，假设客户端主动关闭，服务器被动关闭。 第一次挥手： 客户端发送一个FIN，用来关闭客户端到服务器的数据传送，也就是客户端告诉服务器：我已经不 会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，客户端依然会重发这些数据)，但是，此时客户端还可以接受数据。 FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。 第二次挥手： 服务器收到FIN包后，发送一个ACK给对方并且带上自己的序列号seq，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。 ...

← 已是第一轮 · 返回本次面经 · 第 2 轮 → 本轮概述： 该轮面试主要考察了前端基础知识，包括BFC、浮动元素、作用域、异步编程、Webpack、Vue等多方面的内容。题目涉及理论知识和代码实现。 本轮共 18 道题。答案默认折叠，便于先自行作答。 1. BFC讲一下 题库原题：什么是BFC？ 题目要点 BFC（Block Formatting Context） 是 CSS 中一个重要的布局概念，它描述了一个块级元素的内部布局和外部布局之间的关系。BFC 主要用于处理元素的布局、浮动、边距合并等问题。 BFC 的作用 阻止外边距折叠： 外边距折叠：当两个块级元素垂直相邻时，它们的外边距会合并，形成一个更大的外边距。 BFC：在 BFC 内部的元素的外边距不会影响到外部 BFC 的元素，避免了外边距折叠的问题。 包含浮动元素： 浮动元素：通常会从其包含块中溢出。 BFC：具有 BFC 的元素可以包含其内部的浮动元素，确保其高度包括浮动元素的高度。 控制元素的布局： BFC：在 BFC 内部，元素的布局（如浮动、定位）会受到影响和控制，避免与外部元素发生冲突。 防止元素重叠： BFC：能够隔离不同的 BFC 区域，避免元素之间的重叠或干扰。 如何触发 BFC BFC 会在以下情况中被触发： 块级格式化上下文的创建： 元素的 display 属性值为 block 或 inline-block。 元素的 position 属性值为 absolute 或 fixed。 元素的 float 属性值为 left 或 right。 元素的 overflow 属性值为 hidden、scroll 或 auto。 其他常见触发情况： ...

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