iOS 27 上线后，369 条真实搜索都在问什么

2026 年 9 月 20 日到 10 月 6 日，也就是 iOS 27 上线后的头三周，本站的 Google Search Console 记录下 1,630 条查询记录，覆盖 369 个不同的搜索词。我们把每一条按它描述的「症状」归类、数出结果，并把生成下面每一个数字的 SQL 一起公开。这一页就是结果，包括我们解释不了的那部分。

一句话结论：真正找上我们的搜索，按体量排序是发热、存储账目、无线连接。而大家通常以为会主导一次糟糕更新的两类问题——应用闪退和通知丢失——加起来是个零头。

这份数据是什么，不是什么

数据源是本站自己的 Search Console 导出，存在本项目数据库里，可以按随项目发布的 docs/growth/data/query-mix-study/ 文件原样重跑。它是真实搜索的真实测量，但有六条硬限制，引用本页任何数字之前请先读：

1. 它只是一个站。 WhyMyPhone 是 2026 年 9 月上线的小型故障排查站，它的搜索可见度是一个市场的一个切面，不是 iPhone 用户的样本。
2. 它只有分布的头部。 这份导出每天只返回大约前 200 条查询，长尾整体缺失。本页描述的是最大的那些查询，不是全部查询。
3. 它是 10 天，不是 17 天。 9 月 20 日到 10 月 6 日之间我们抓到了 12 天，其中 9 月 25 日与 10 月 2 日的结果与前一天逐字节相同，我们判断为抓取失败后把上一次结果又写了一遍，因此剔除了重复的这两天。另外还有 5 个自然日完全没有查询维度的数据。分析窗口冻结在 10 月 6 日。 Search Console 一直在陆续送达新的日期——这一页还在写的时候又落进来一天——所以分析固定了结束日期，而不是报告「最新的可用数据」。不固定的话，同一套查询每周都会返回不同的总数，本文也就无从核对。因此被排除的日期列在 report-14 里。
4. 查询行与日汇总对不上。 逐天看，查询维度的曝光最低不到当日汇总的 3%（第一天只抓到 6 行），最高到 164.5%。我们没有找到干净的解释，所以本文只报告查询集合内部的相对分布，绝不把它换算成全站曝光占比。
5. 我们自己的内容库决定了我们能出现在哪些查询里。 我们只对写过的题目有排名。一个我们从没覆盖过的问题，无论多常见都不可能出现在这份数据里。
6. 分类是我们做的。 每个搜索词由一条写明的正则规则归入某个症状类别，不是逐条人工判读。规则就在公开的 SQL 里，你完全可以不同意它并重跑。

构成：发热、系统数据与蓝牙吃掉六成以上

每个搜索词只归入一个类别。曝光指我们的页面在该词的结果里出现多少次，排名指它出现在第几位，点击率指这些出现里被点掉的比例。

其中发热、存储、卡顿、电池四类，在我们的内容里都被归到同一个过程：iPhone 安装完更新之后仍在后台跑的那批活（重建索引、重建缓存、迁移数据），Apple 的文档把它描述为「数小时甚至数天」，取决于数据量。这四类合计 67.2% 的曝光。这个归并是我们对机制的编辑判断，不是搜索数据本身证明的结论；机制本身写在《iOS 索引用多久才会结束》里。

还有一点从表里不容易一眼看出来：我们排名最好的类别，并不是需求最大的类别。 通知、应用闪退、连接类我们稳定在 7.0～8.0 名，而卡顿和发热在 10.5～12.5 名——可发热带来的曝光是闪退的九倍（1,779 对 195）。在一个问的人本来就少的题目上排得很好，并不会带来流量。

闪退只占 2.5%，而且这不是「我们没写」造成的

对「闪退只有 2.5%」最直接的反驳是：是不是我们压根没写闪退？我们写了——iOS 27 应用闪退两篇、通知延迟或收不到两篇，而且这两类的排名比发热更好：平均 7.5 名和 7.0 名，发热是 12.5 名。它们在排名不差的情况下，拿到的曝光很少。

这恰恰是有用的信号。在一个稳定但不靠前的位置上，曝光量粗略反映了「到底有多少人在搜这个词」：我们出现了，但几乎没人点，因为这个问题本来就冷门。按这个读法，从搜索这一侧看到的 iOS 27 问题潮，是一场发热与存储账目的浪潮，不是稳定性浪潮。这两类到底在讲什么，见《iOS 27 系统数据》与 iOS 27 应用闪退。

两套机制，顶着同一个「更新之后」的标签

曝光第三大的类别（与第二名只差一个零头），恰好是不符合「更新后后台还在忙」这套解释的那一个。蓝牙掉线、AirPods 断连、CarPlay 异常、SIM 不识别，合计 20.4% 的曝光，而且整个集合里最大的那一条查询就在这里：

我们内容里给出的机制不是后台索引，而是连接状态：旧系统版本下写入的过期配对记录、配件固件按自己的节奏更新、以及你身边 2.4GHz 干扰格局的变化。这写在《iOS 27 蓝牙问题》里。把它们一锅端成「更新把手机弄坏了」是错的，而搜索数据正好让这个区分变得可见：两个毫不相干的成因，人们打出的是同样三个词。

没有一个人在搜新功能

369 个查询词里，没有任何一个命中功能类措辞——没有新界面名称，没有助手名称，没有「评测」，也没有「怎么用」。每一个词说的都是「哪里不对」或者「这个开关是干嘛的」。

这句话要读得小心，因为它有一个明显的替代解释：我们没写过任何功能页，所以就算有人搜，我们也不可能出现。这是上面第 5 条限制最清楚的例子。这个「零」真正能支撑的结论要窄得多，但依然有用——在我们有资格出现的查询里，没有人在找这次更新加了什么。

版本无关的那一层：13% 的需求，我们排名最差的地方

369 个查询词里有 155 个既没点名操作系统，也没点名机型。与带版本号的查询相比，这一层的行为完全不同：

平均排名 34 意味着第四页：我们实际上是不可见的，1.8% 的点击率是结果，不是页面本身的毛病。常青问题就住在这里，其中好几条有真实且稳定的量：

这些就是「这个开关到底做什么」类的问题——下一个大版本落地时它们也不会过期。回答它们的页面其实已经写好了（《背景 App 重新整理是什么》、《各机型电池健康》）；这份数据记录下来的问题是排名，不是内容。

需求从哪些语言来

本站默认语言是英文，但 58.5% 的曝光和 67.7% 的点击来自非拉丁文字的查询；日文查询用 38.3% 的曝光换来了 45.7% 的点击。

在被引用之前，先记住一条限制：查询语言与页面语言是纠缠在一起的。 日文查询打到我们的日文页，英文查询打到英文页，而两个版本在篇幅、结构、内链上并不相同。这里没有任何东西能支撑「日语用户遇到的 iPhone 问题更多」。能说出口的是「可触达市场」的分布，不是「人」的分布。

一个我们解释不了的数字

系统数据这一族最能说明「点击率要小心读」。五种看起来是同一个意图的措辞，排名都落在 5.9～7.8 名之间，结果是这样：

我们看得到这个形态，但归因不了。摘要片段的匹配、意图的具体程度、这条查询的曝光是分摊在哪几天拿到的——在一个 10 天窗口和这个样本量下，没有一项能被干净地拆开。我们把它原样放出来而不是抹平，因为一份藏起自己噪声的研究，对引用它的人比对一份标出噪声在哪的研究更没用。

怎么复现每一个数字

完整分析在本项目仓库的 docs/growth/data/query-mix-study/ 目录：

• base.cte.sql —— 去重、冻结分析窗口与分类规则，含全部正则
• report-00 到 report-14 —— 本页每一张表对应一个文件
• run.sh —— 一次跑完并写出 OUTPUT.txt
• coverage-map.csv —— 每个类别我们各自有多少篇文章
• OUTPUT.txt —— 保存下来的输出，方便与重跑结果对照

```bash

export DB9_API_KEY=<key>

bash docs/growth/data/query-mix-study/run.sh

```

里面内置了两项稳健性检查。用一套故意更粗的分类规则（每类只认少数关键词）重跑，任何一个被命名的类别移动都不超过 1.9 个百分点，前三名（发热、系统数据、连接）顺序不变；但「其他」这个兜底桶会从 3.5% 涨到 16.2%，因为更粗的规则认不出那些词了——所以请把兜底桶当作分类器的产物，不要当成发现。另外按类别清点我们自己的文章数——发热 11 篇、连接 7 篇、存储 6 篇、电池 5 篇、卡顿 2 篇、闪退 2 篇——会发现曝光构成与覆盖构成大体同步，这正是上面第 5 条限制比其余各条都重要的原因。76.3% 的曝光来自在 10 次导出里至少出现 7 天的查询，所以这是一波持续的需求，不是某一天的新闻尖峰。

Related

• iOS 索引要多久才结束？
• iOS 27 系统数据：多少算正常
• iOS 27 蓝牙问题
• iOS 27 卡顿与掉帧
• 背景 App 重新整理是什么？