所以这个错误很少真的是「太慢」。多半是某一步在等一件永远不会发生的事。按我排查的顺序，原因和对应的修法如下：

1. 定位器（locator）什么都没匹配到，于是 click() 或 fill() 一直等到测试时间用完。常见原因是测试 ID 改了、文字改了，或者有个对话框挡在前面。改定位器。
2. 页面跳转或 waitForURL() 在等一个永远不会出现的页面，因为重定向、登录页或首次启动页把应用带去了别处。改你等待的条件。
3. 准备工作确实慢：第一次请求才开始编译的开发服务器、从缩容到零状态被唤醒的后端、每个 beforeEach 里都走一遍 UI 登录。改环境，或者只准备一次。
4. 测试本来就长。这时，也只有这时，才用 test.slow() 或 test.setTimeout() 给这个测试加时间。

不管是哪种，第一件事都是找到时间用完那一刻还在执行的那一步。第二件事是设置 actionTimeout，让下一次失败直接告诉你是哪一步。

这 30 秒里都有什么

#

测试超时是一份时限，由 fixture 准备、beforeEach 钩子和测试函数共用。测试结束后，afterEach 钩子和 fixture 清理（teardown）另外再拿一份同样长的时限。beforeAll 和 afterAll 也拿同样的值，但不和任何测试共用，失败时也有自己的报错。

在这份时限里，只有断言有自己的计时。await expect(locator).toBeVisible() 默认 5 秒后放弃，并准确告诉你它在找什么。动作和页面跳转则不然：actionTimeout 和 navigationTimeout 默认不设上限。这个错误之所以这么含糊，原因全在这里。去点一个永远不会出现的元素，并不会失败，它只会老老实实地等，直到别的东西把测试结束掉。

下面是所有能让一次运行结束的超时，以及各自打印的内容。这些报错原文取自 Playwright 1.58 和 1.63，也就是我项目里最旧和最新的两个版本。

动作、页面跳转和整次运行这三行没有默认值可打印，所以里面的数字就是你自己设的值。

五个测试和一个改了名的测试 ID

#

今年 2 月，我做的估价应用的测试套件在一次运行里有五个测试失败，而且失败方式一模一样。这套测试用 Playwright 驱动应用的 Web 版（由开发服务器提供），只开一个 worker，连的是刚灌好种子数据的本地后端。下面是五个里的第一个，稍作删减：

  1) [default] › tests/templates.spec.ts:50:7 › Templates › should edit a template ───

    Test timeout of 30000ms exceeded.

    Error: locator.click: Target page, context or browser has been closed
    Call log:
      - waiting for locator('[data-testid="template-item"]').filter({ hasText: 'E2E Edit Template' }).locator('[data-testid="edit-template"]')


      57 |       .locator('[data-testid="template-item"]')
      58 |       .filter({ hasText: "E2E Edit Template" });
    > 59 |     await item.locator('[data-testid="edit-template"]').click();
         |                                                         ^
      60 |     await page.waitForTimeout(500);

单看 Target page, context or browser has been closed 这一行，像是浏览器崩了。其实不是。这是页面在脚下被关掉时，动作给出的报错：30 秒到了，Playwright 开始收拾这个测试，那个还在等待的点击就报告说它的页面没了。如果用的是内置的 page fixture，这一行会再说一遍超时，写成 Error: locator.click: Test timeout of 30000ms exceeded.。这些测试是在 beforeAll 里自己开的浏览器上下文，所以点击拿到的是通用版本的报错。

真正有用的是调用日志（call log）。点击在等 [data-testid="template-item"]。十个小时前，我把列表行组件的测试 ID 从 template-item 改成了 template-item-${name}，好让原生应用的端到端测试能按名字挑出某一行。用 = 的属性选择器要求整个值完全相等，于是 Web 测试要找的元素在页面上已经不存在了；又没有动作超时，这个点击注定要一直等到测试超时。五个失败各 30 秒，就是两分半钟，而整次运行一共才 3.8 分钟。

我第一时间加的是重试。不到半小时，配置里就多了 retries: process.env.CI ? 2 : 1，旁边的注释至今还写着 “for flaky browser crashes”，意思是用来应付偶发的浏览器崩溃。下一次运行，同样那五个里有四个连同重试一起又挂了，耗时从 3.8 分钟涨到 6.4 分钟。这几个 describe 块跑在串行（serial）模式下：一个失败，组里剩下的全部跳过；重试则从组里第一个测试重新开始。所以每个坏掉的点击都把 30 秒等了两遍。每次都以同样方式失败的测试，重试救不回来，只会让你付两遍代价。

修法是改成前缀匹配：

const item = page
  .locator('[data-testid^="template-item-"]')
  .filter({ hasText: "E2E Edit Template" });
await item.locator('[data-testid="edit-template"]').click();

往大里说，测试 ID 也是一种契约。我有两套测试都依赖这一个 ID，而彼此都不知道对方的存在。Playwright 的最佳实践指南建议优先用 getByRole() 这类基于用户可见属性的定位器，而不是我这种 CSS 选择器，为的就是让测试扛得住那些用户根本察觉不到的 DOM 改动。

找到卡住的那一步

#

先看调用日志。它属于时间用完时还在执行的那一步；如果 waiting for locator(...) 后面什么都没有，说明定位器从头到尾都没匹配上任何东西。

还不够的话，就打开 trace。我的两个应用测试套件，一个是估价应用的，一个是我做的一个集市兼社区应用的，用的都是 trace: "on-first-retry"。它只在第一次重试时录制，所以 retries 至少要设成 1。不开重试的话用 "retain-on-failure"；临时跑一次就加 --trace on。然后直接打开 trace，或者从 HTML 报告里打开：

npx playwright show-trace test-results/<test-folder>/trace.zip
npx playwright show-report

没执行完的那个动作，就是列表末尾附近带着报错的那一项。选中它看快照：那就是 Playwright 等待时页面的样子，你可以在里面找你期待的那个元素。换成我这个例子，那一行就好好地在那儿，只是带着一个测试没在找的 ID。

较新的版本还会在失败截图旁边写一个 error-context.md，里面是失败那一刻页面的文本快照。元素找不到的情况，往往光看它就够了。

有个坑：--debug 打开 Inspector 的同时，还会设置 --timeout=0，外加 --max-failures=1、--headed 和 --workers=1。在 --debug 下能通过的测试，对这 30 秒什么也说明不了。

给每个动作设个上限

#

我的配置文件里没有一个设了动作超时，所以一个找不到的元素才能五次各耗掉 30 秒。在 use 里加两行就能改过来：

import { defineConfig } from "@playwright/test";

export default defineConfig({
  timeout: 30_000,
  expect: { timeout: 5_000 },
  use: {
    actionTimeout: 10_000,
    navigationTimeout: 15_000,
    trace: "retain-on-failure",
  },
});

同样那个坏掉的定位器，就会在测试还剩时间的时候这样失败：

    TimeoutError: locator.click: Timeout 10000ms exceeded.
    Call log:
      - waiting for locator('[data-testid="template-item"]').filter({ hasText: 'E2E Edit Template' }).locator('[data-testid="edit-template"]')

哪一步、哪个动作、等了多久，全写在上面。我觉得这两个值都应该明显小于测试超时，这样某一步卡住时，不会把整份时限耗光，再躲到那条含糊的报错后面。2 月那次，问题从来不在 30 秒。那个点击身上只有这一个计时器，所以响的就是它。

只给长测试加时间，别给卡住的测试加

#

测试确实在做耗时的工作时，加超时是对的；某一步在等一件不会发生的事时，加超时就是错的，数字再大也只是让失败来得更晚。到底是哪种，通常看一眼 trace 就清楚了：动作一个接一个都完成了，只是数量多，那是长测试；有一个动作直到最后都停在 waiting for，那是卡住的测试。

对长测试，时间要加在真正长的地方，而不是整个套件。集市应用的套件里有一个冒烟测试，会一边截图一边把聊天界面走一遍，我给了它三分钟：

test("chat: open, send a message, go back", async ({ page }) => {
  test.setTimeout(180_000);
  // ...
});

在 describe 里调用 test.setTimeout()，会作用于组内所有测试，估价应用套件里的成本计算（job-cost）测试就是这样拿到一分钟的。test.slow() 会把当前的超时乘以三，不管它原来是多少，也可以带条件。在 beforeEach 里用 testInfo.setTimeout()，会延长所有经过这个钩子的测试：

test("slow in WebKit", async ({ page, browserName }) => {
  test.slow(browserName === "webkit", "This page is slow in WebKit");
  // ...
});

test.beforeEach(async ({ page }, testInfo) => {
  testInfo.setTimeout(testInfo.timeout + 30_000);
});

还有一样东西每次都在悄悄吃掉时限：固定等待。估价应用的套件里，几乎每个 spec 文件都用到了 page.waitForTimeout()，加起来一百多处。上面那个编辑测试在走到点击之前先睡了 3 秒，可睡多久都救不了它。Playwright 的 API 文档在这一点上说得很直白：“Never wait for timeout in production. Tests that wait for time are inherently flaky.” 也就是说，正式环境里永远不要按时间等待，靠时间等待的测试天生就不稳定。Web 优先断言（web-first assertion）本来就会等到需要的时候为止，一点不多等：

// before
await page.locator('[data-testid="save-template"]').click();
await page.waitForTimeout(1500);
await expect(page.getByText("E2E Edited Template")).toBeVisible();

// after
await page.locator('[data-testid="save-template"]').click();
await expect(page.getByText("E2E Edited Template")).toBeVisible();

断言超时也要同样小心。两个应用套件都把 expect.timeout 调到了 15 秒，而且都是对着应用的开发服务器跑，而不是生产构建。这样是多了余量，但连着两个慢断言就可能把 30 秒用光，于是测试超时先触发，你又回到了那条含糊的报错。

当计时的不是测试本身

#

如果报错里出现 config.webServer，说明还一个测试都没跑。Playwright 会先启动你的 webServer 命令，等它的 url 有响应了才开始跑测试。这段等待有单独的超时，默认 60 秒。两个应用套件都给开发服务器留了两分钟：

webServer: {
  command: "npm run web -- --port 8081",
  url: "http://localhost:8081",
  reuseExistingServer: false,
  timeout: 120_000,
},

如果测试对着的是部署好的环境而不是本地服务器，先搞清楚它的第一个请求要多久。我终于在自己用的托管平台上量了一次，一台从缩容到零状态启动的机器，要 25 到 33 秒才能响应任何请求，还没点第一下，测试的时限就用掉了大半甚至全部。那段经历写在缩容到零，于是每次重启都是一次 30 秒的故障里。

如果报的是「No tests found」

#

No tests found 听起来相关，但它不是超时：Playwright 找了一圈，没有可跑的东西。默认情况下，它会在 testDir 下收集匹配 **/*.@(spec|test).?(c|m)[jt]s?(x) 的文件，而 testDir 默认就是配置文件所在的目录。我的配置都指向配置文件旁边的 testDir: "./tests"，所以放在别处的 spec 根本看不见。命令行参数是拿来匹配文件路径的正则表达式，所以报错里才会附上一句 “Make sure that arguments are regular expressions matching test files."。想在不运行任何东西的情况下，看看 Playwright 收集到了什么：

npx playwright test --list

如果你的 spec 不在这个列表里，它压根就没机会超时。另外，如果你是第一次搭 Playwright，我在小团队更该做视觉测试里讲过为什么建议从截图对比开始。

我花在调试上的时间实在太多了。谁不是呢。最近大部分时间都在 Xcode 和模拟器里追自己应用的 bug，越用越有一个感受：Xcode 自带的调试工具其实很强，只是大多数人几乎不碰。这篇就把我多年下来沉淀的调试流程写出来，都是真正省时间的部分。

断点比你想的更强大

#

大多数人点一下行号边栏，设个断点就完事了。其实右键点开，里面有一堆能改变调试方式的选项。

条件断点

#

假设有个循环要处理 1000 个项目，只有第 347 个出问题。总不能先命中 346 次断点吧。

for i in 0..<users.count {
    processUser(users[i])  // 在这设断点，条件: i == 347
}

右键断点，加上条件 i == 347，Xcode 只在条件为真时停下。userId == "abc123"、error != nil 这类条件同样好使。

符号断点

#

不知道方法在哪被调用时，就靠它。打开断点导航器（Cmd+8），点 + 按钮，选“Symbolic Breakpoint”。

想看每个视图控制器什么时候加载？把符号设成 viewDidLoad，Xcode 会在每一处暂停。太吵就缩小范围：MyViewController.viewDidLoad。

我常年留着这三个：

• UIViewAlertForUnsatisfiableConstraints：当场抓住 Auto Layout 冲突
• objc_exception_throw：在崩溃之前就停在 Objective-C 异常上
• malloc_error_break：发现内存分配问题

异常断点

#

这大概是新项目里第一件该做的事。加一个异常断点（断点导航器里点 + → Exception Breakpoint），Xcode 会在抛异常的那一刻暂停，而不是等应用死透了才反应。

多少 nil 解包的问题都是靠它抓住的，不然只会在控制台里留下一条莫名其妙的崩溃。

断点动作

#

断点其实不必停止执行。编辑断点，点“Add Action”，可以：

• 不暂停地输出变量："User count: @(users.count)@"
• 自动执行 LLDB 命令
• 执行 shell 脚本
• 播放声音（我用它来确认罕见代码路径有没有被走到）

勾上“Automatically continue after evaluating actions”，断点就成了一个不打断流程的日志器。

LLDB：你真正会用到的控制台命令

#

在断点停下时，底下那个控制台不只是看崩溃日志的地方。那是 LLDB，非常好用。

基础

#

(lldb) po user
▿ User
  - id: "123"
  - name: "John Doe"
  - email: "john@example.com"

po 用可读的格式打印对象。我 90% 的 LLDB 操作就是它。

想要更多细节，换 p：

(lldb) p user.name
(String) $R0 = "John Doe"

一次看完所有局部变量：

(lldb) frame variable

运行时改值

#

LLDB 真正值钱的地方在这：不用重新编译就能改变量。

(lldb) expr user.name = "Jane Doe"
(lldb) expr index = 0

发现 bug，想不重新构建就试一下修复？改掉变量继续跑就行。缩小边界情况范围的时候，我一直这么换值测试。

方法也能调：

(lldb) po self.refreshUI()
(lldb) expr navigationController?.popViewController(animated: true)

导航

#

(lldb) bt              # 显示调用栈
(lldb) frame select 3  # 跳到不同的栈帧
(lldb) continue        # 继续运行（或者直接 'c'）
(lldb) n               # 单步跳过（下一行）
(lldb) s               # 单步进入函数

监视点

#

想知道变量什么时候被改了？设个监视点：

(lldb) watchpoint set variable user.isLoggedIn

之后不管代码哪里改了这个值，执行都会立刻暂停。追踪莫名其妙的状态变化，没有比这更好用的了。

Console.app：被埋没的调试工具

#

多数时候 Xcode 的控制台够用，但要把系统日志、崩溃报告全都看一遍时，就该打开 Console.app 了。

如果你在用 OSLog（应该用），Console.app 能让这些日志随便搜、随便过滤：

import os.log

let logger = Logger(subsystem: "com.example.app", category: "networking")

logger.info("Starting API request")
logger.debug("Request URL: \(url.absoluteString)")
logger.error("Failed to decode: \(error.localizedDescription)")

Console.app 那边的步骤：

1. 选中你的模拟器或已连接的设备
2. 按子系统过滤：subsystem:com.example.app
3. 按级别过滤：subsystem:com.example.app AND level:error

常用的过滤谓词可以存起来。我存了三个：看网络请求的、看数据库操作的、只显示错误和警告的。

为什么用 OSLog 而不是 print()

#

OSLog 比到处撒 print() 强太多。它是结构化的，能按级别和分类过滤；日志本身经过优化，不会拖慢应用；生产环境里还会自动遮蔽敏感数据，而且应用崩了日志也还在。

临时看一眼，用 print() 没问题。以后可能要翻的东西，交给 OSLog。

Console.app 过滤进阶

#

Console.app 支持相当强的谓词查询。我常用的几条：

# 应用里所有的错误和故障
subsystem:com.example.app AND (level:error OR level:fault)

# 失败的网络请求
subsystem:com.example.app AND category:networking AND eventMessage CONTAINS "failed"

# 过去 5 分钟的所有内容
subsystem:com.example.app AND timestamp >= now(-5m)

日志还能导出来附在 bug 报告里，比从 Xcode 控制台复制粘贴省事多了。

视图调试

#

UI 坏了又看不出为什么，最快的路是视图调试器。

运行应用，走到出问题的页面，点 Xcode 调试栏里的“Debug View Hierarchy”按钮（或按 Cmd+Shift+D），整个视图层级就以 3D 分解图摊在你面前。

转一转，问题自己会冒出来：

• 藏在其他视图后面照常渲染的视图
• 跑到屏幕外老远的视图
• 大小为零的视图
• 选中视图的完整约束链

我用它找到过吞掉点击事件的隐形按钮、以 0x0 渲染的标签，还有一张不知怎么变成 10,000 像素宽的图片。

Auto Layout 调试

#

视图层级里的紫色警告图标就是约束冲突。点开，Xcode 会告诉你到底哪些约束在打架。

给约束加上标识符：

heightConstraint.identifier = "ProfileImageHeight"

约束出问题时，错误里显示的就是 "ProfileImageHeight" 而不是一串内存地址，日志一下就能读了。

在 LLDB 里也能打印约束树：

(lldb) po view.hasAmbiguousLayout
(lldb) po view._autolayoutTrace()

省时间的模拟器功能

#

慢速动画

#

Debug → Slow Animations，一切放慢到 1/10 速度。想看清转场里到底发生了什么、动画为什么看着别扭，用它正好。

模拟内存警告

#

Debug → Simulate Memory Warning，测试应用在低内存下的表现。我靠它发现过不少图片缓存 bug：内存警告触发之前一切正常，一触发所有图片全没了。

Network Link Conditioner

#

Xcode → Open Developer Tools → Network Link Conditioner

可以模拟 3G、LTE、高丢包率或者完全离线。如果你遇到过 API 请求在 WiFi 上好好的、一到蜂窝网络就超时，用它就能复现。

我常备一个“Bad Network”配置：500ms 延迟加 10% 丢包。那些在办公室高速 WiFi 上永远看不到的超时 bug 和加载状态问题，全在这现形。

状态栏覆盖

#

在模拟器里右键状态栏，可以改时间、电量、信号强度和运营商。想统一截图，或者想看不同电量下 UI 的样子，都用得上。

位置模拟

#

Debug → Location，人不离开桌子就能模拟各种位置：自定义坐标、城市步行、高速公路驾驶，全都有。测位置相关功能，或者查只在某些地区出现的问题，特别方便。

内存调试

#

Debug Memory Graph

#

点 Debug Memory Graph 按钮（Cmd+Shift+M），Xcode 会展示内存里的每个对象、它们之间的引用关系，以及你真正关心的：哪些在泄漏。

紫色感叹号就是泄漏。点开就能看到循环引用。

我见得最多的泄漏长这样：

class ViewController: UIViewController {
    var onComplete: (() -> Void)?

    func setupHandler() {
        onComplete = {
            self.dismiss(animated: true)  // ❌ 强引用了 self
        }
    }
}

用 weak self 修：

onComplete = { [weak self] in
    self?.dismiss(animated: true)  // ✓ 没有循环引用
}

delegate 也得是 weak：

weak var delegate: ManagerDelegate?  // 不只是 'var'

Instruments

#

要认真查内存，就上 Instruments（Product → Profile，或 Cmd+I）。

Allocations 能看到每一次对象分配、内存随时间的增长、哪些类最占内存，以及每次分配发生在哪的堆栈跟踪。

我通常找三样东西：随时间线性增长的内存（八成是泄漏）、意料之外的大块分配（是不是把 1000 张图一次全加载了？）、该释放却还活着的对象。

在操作前后标记代（那个小旗子按钮），就能看出什么东西不该留却留下了。

性能分析

#

Time Profiler

#

Product → Profile → Time Profiler。一边在应用里做那个慢操作一边录制，然后读调用树。

按“Self Weight”排序找瓶颈。哪个函数占了 40% 的 self weight，时间就是耗在那了。

我有次发现一个 JSON 解析函数每秒被调用 1000 次。挪到后台队列，UI 立刻不卡了。

Main Thread Checker

#

后台线程上的 UI 更新，Xcode 会自动抓。看到这条：

Main Thread Checker: UI API called on a background thread: -[UILabel setText:]

说明你干了这种事：

URLSession.shared.dataTask(with: url) { data, response, error in
    self.label.text = "Loaded"  // ❌ 崩溃！
}

改成这样：

URLSession.shared.dataTask(with: url) { data, response, error in
    DispatchQueue.main.async {
        self.label.text = "Loaded"  // ✓
    }
}

运行时诊断

#

Edit Scheme → Run → Diagnostics。这里一排复选框，专抓那些靠手动永远找不到的 bug。

Address Sanitizer

#

查内存损坏：use-after-free、缓冲区溢出、内存泄漏。应用会慢 2-3 倍，但它抓的 bug 换别的办法几乎无从下手。追那种偶尔才出现的崩溃时，我会把它打开。

Thread Sanitizer

#

抓数据竞争和线程问题。开着它跑应用，正常用就行，只要有竞态条件，它自然会找出来。

Address Sanitizer 和 Thread Sanitizer 不能同时开，所以碰到诡异崩溃我就在两者之间轮换。

Zombie Objects

#

抓发给已释放对象的消息。开着它，你一碰已释放的内存，Xcode 立刻告诉你：

*** -[MyViewController viewDidLoad]: message sent to deallocated instance 0x600001234000

别一直开着。它会阻止对象释放，内存只涨不降。但要钉死某个 use-after-free bug，它是最好的。

常见调试场景

#

一启动就崩溃

#

先加异常断点，通常就能抓到。

抓不到就查这几处：Info.plist 缺键、初始化代码里的强制解包、依赖注入失败。

UI 不更新

#

每次。每一次，都是其中之一：

1. 更新不在主线程上
2. outlet 没连上
3. 视图根本不在屏幕上（LLDB 里 po view.window 查一下，返回 nil 就说明不在层级里）

表格或集合视图的话，是你忘了调 reloadData()。

内存警告导致崩溃

#

用 Instruments Allocations 看什么在占内存。通常不外乎：图片没从缓存里放掉、视图控制器释放不了（循环引用）、某个数组或字典一直在涨。

在模拟器里模拟内存警告，把清理代码测一遍。

神秘崩溃

#

sanitizer 全开。间歇性的多半是线程问题，用 Thread Sanitizer 跑；崩在系统框架里的多半是内存损坏，用 Address Sanitizer 跑。

复现不了的崩溃

#

崩溃要是发生在别人的手机上，崩溃报告一般还找得到。TestFlight 和 App Store 的构建，Xcode 的 Organizer（Window → Organizer → Crashes）会收集那些同意共享分析数据的用户的崩溃报告，只要 dSYM 跟着构建一起上传了，报告就已经符号化好了。测试人员的手机上，报告就存在设备本地：设置 → 隐私与安全性 → 分析与改进 → 分析数据，里面以应用名开头的 .ips 文件就是，让对方用隔空投送（AirDrop）传过来就行。先看崩溃线程的调用栈，再按上面几种场景逐个排查。

在模拟器里调试 OTA 更新

#

我的应用会推送 OTA（空中下载）更新，而调试这整条流程，模拟器是最省事的地方。

我先盯网络流量。把 Console.app 过滤到应用的子系统，清单请求和响应就实时滚出来，发了什么头部、服务器回了什么，一清二楚。

然后故意把网络弄坏。用 Network Link Conditioner 看看更新流程在慢连接、丢包下什么表现。应用挂住了吗？加载指示器出来了吗？有没有体面地降级？

更新检查逻辑周围都埋上日志：开始检查时、发现可用更新时、开始下载时、加载新 bundle 时，每个节点都记。

import os.log

let logger = Logger(subsystem: "com.example.app", category: "updates")

logger.info("Checking for updates...")
let update = try await Updates.checkForUpdateAsync()
logger.info("Update available: \(update.isAvailable)")

最后，清单端点本身也值得单独测一遍。用应用发的同样头部直接 curl：

curl -H "expo-protocol-version: 1" \
     -H "expo-platform: ios" \
     -H "expo-runtime-version: 1.0.0" \
     https://updates.example.com/manifest

先确认服务器返回的数据没问题，再去挖客户端。

第三方工具

#

Charles Proxy / Proxyman

#

看全部网络流量、改请求和响应、测试错误条件。API 调试离不开。

Proxyman 的 UI 比 Charles 好，在 macOS 上也更像原生应用。我去年换过去之后就没回头。

Reveal

#

类似 Xcode 的视图调试器，但更强。不连 Xcode 也能在真机上用，查测试人员设备上的布局问题很合适。

模拟器和真机的区别

#

我大部分调试都在模拟器里做，因为快：不用插线，不用签名，也不用等安装。但模拟器说到底是一个跑在 Mac 处理器上的 iOS 构建，用的是 Mac 的内存、Mac 的网络，有些 bug 只有在手机上才会出现。

所以我在模拟器里写逻辑、调逻辑，发版前再拿还在支持的最老的那台 iPhone 跑一遍。性能、内存压力，还有一切跟硬件打交道的东西，没在真机上跑过，就不算真正测过。

在真机上运行

#

把 iPhone 插上，在运行目标里选中它，再到 Signing & Capabilities 里设好 Team（只装到自己的手机上，免费的 Apple ID 就够了）。从 iOS 16 开始，手机还得在 设置 → 隐私与安全性 里打开开发者模式，第一次打开会重启。打开之后，手机自己的 设置 → 开发者 菜单里也有 Network Link Conditioner，弱网配置和 Mac 上的一样。

无线调试

#

用 USB 连一次设备，到 Window → Devices and Simulators 勾上“Connect via network”，然后拔线。只要在同一个 WiFi 下，设备就一直挂在 Xcode 里。

Device Console

#

Window → Devices and Simulators → Open Console。系统日志、应用日志、崩溃报告，全都在，比 Xcode 自己的控制台详细得多。

测试人员说“应用崩了”，我一定让他们把设备插上来抓控制台日志。往往里面就躺着一条系统级错误，把一切都解释清楚了。

我调试时的实际顺序

#

1. 没有异常断点就先加一个
2. 重现 bug
3. 在怀疑出问题的地方附近设断点
4. 在 LLDB 里用 po 查值
5. 改变量，不重编译就验证修复
6. UI 相关就查视图层级
7. 性能相关就用 Instruments 分析
8. 内存或线程相关就开 sanitizer

诀窍是从症状往回推。崩溃？异常断点。慢？Time Profiler。内存？Instruments。UI 诡异？视图调试器。

希望早点知道的事

#

用断言。逻辑错误还没变成 bug 就能被拦下：

assert(users.count > 0, "Users array should never be empty here")

调试前先提交。一旦开始改东西验证猜想，你迟早会想回退。

调完把 print 删掉，至少也用 #if DEBUG 包起来。旧的调试日志会挡住下一个 bug。

把 LLDB 学明白，比把应用重新构建二十遍快。

还有，模拟器不是真手机。只在真机上出现的 bug，几乎全是线程或内存问题。再不然就是性能问题，毕竟模拟器跑的是 Mac 的 CPU，不是真正的 iPhone 芯片。

我一直开着的工具

#

• Xcode（这不用说）
• 过滤到应用子系统的 Console.app
• 网络调试用 Proxyman
• 事态严重时上 Instruments

没有哪个工具包打天下。视图调试器找不出内存泄漏，Instruments 也解不开 Auto Layout 冲突，功夫全在把工具对上症状。这事只能靠次数堆：循环引用踩得多了，看一眼堆栈跟踪就能闻出味来。调试大概永远谈不上有趣，但至少不再是受罪。