背景
我一直使用 Android 系统的手机，前段时间用 iPhone 才发现我的博客在 Safari 上样式混乱，这个问题在 Windows 和 Android 的浏览器上都无法复现。为了弄清楚到底是出了什么问题，自然需要使用开发者工具调试网页。如果是 Android Chrome 那很简单，通过 adb 连接到手机，然后进入 chrome://inspect 调试即可。iOS Safari 也提供了这样的远程调试功能，但是需要使用 macOS 上的 Safari。没有 Mac 怎么办呢？在国内，考虑到 iOS 与 macOS 的市占率之间的显著差异，我有理由相信这是一个普遍问题。弄来一台物理机或者装黑苹果什么的有点麻烦，不过好在还是有办法的。
以下的推荐方案是我测试之后最为简单易行的方法，尽量详细，如果你只是想快速解决问题，看这一部分就够了；想了解更详细的问题探索过程，可以阅读后续部分。说明一下我使用的软件版本，电脑端为 Windows 11、Chrome 137，手机端为 iOS 16。这个方法应当是各版本通用的，尤其要强调的是这是兼容高版本 Chrome 的。
推荐方案：ios-safari-remote-debug-kit
安装与初始化
有一个开源工具包 ios-safari-remote-debug-kit（下文简称 debug kit），自带一套开发者工具而不依赖浏览器的任何独有特性，可以在 Windows 或 Linux 上方便地调试 Safari。
电脑上必须安装 git 和 Node.js 环境才能运行该工具包，环境的安装过程本文不作说明。首先将 debug kit 的仓库克隆到本地，当然了你也可以用 GitHub 网页上的“Download ZIP”并解压，后者下载的体积较小。
在 PowerShell 中进入到 debug kit 项目的 src 目录，内有一键式的安装与启动脚本。运行 generate.ps1，下载依赖并初始化。这个过程会通过 HTTPS 克隆外部的 git 仓库，国内网络环境下会比较慢。如果有代理的话，可以执行 $env:https_proxy="..."，通过环境变量指定通过代理连接。此外，可能会遇到 PowerShell 的报错，提示脚本没有数字签名不能运行。在具有管理员权限的 PowerShell 终端中运行 Set-ExecutionPolicy Bypass -Scope CurrentUser 关闭该检查。不过出于安全考虑，建议在运行完之后调回原来的设置。
初始化过程的末尾，会提示选择设备的 iOS 版本，我这里选择了大于等于当前设备版本的最低版本。
连接到 iPhone
调试功能是默认关闭的，需要手动开启。在 iPhone 的“设置 > Safari 浏览器 > 高级”中，打开“网页调试器”功能。
在电脑上安装 iTunes，这是连接到 iPhone 的必要步骤。Apple 官网上提供了在 Microsoft Store 中安装的链接。不过，如果你和我一样不想在电脑上登录微软账号，可能会遇到麻烦——微软商店中的大部分应用，包括 iTunes 在内，必须登录微软账号才能安装。Apple 官网上如今不提供 iTunes 的安装包，于是我找到了 Uptodown 上 iTunes 的 exe 安装包，带有 Apple 的数字签名，可以放心安装。
运行 iTunes，将 iPhone 通过 USB 连接到电脑，并按照 iTunes 的指示在 iPhone 上信任该设备，在 iTunes 中能看到自己的设备即可。
启动调试
在 PowerShell 中进入 debug kit 的 src 目录，运行 start.ps1，首次运行还会通过 HTTPS 拉取 GitHub 上的 ios_webkit_debug_proxy（下文简称 iwdp），如果拉取速度慢解决方法同上。开始运行后，会弹出 iwdp 的运行窗口，显示其正在监听 9221 端口；如果连接一切正常，能看到日志中显示已经连接到你的设备。最小化即可，不要关闭该窗口。让我们回到 debug kit 的终端，可以看到开发者工具的链接，形如 http://localhost:8888/Main.html?ws=localhost:9222/devtools/page/1。
我们终于可以开始调试了。在 Safari 中打开待调试的标签页并保持在前台，如果有需要可以调整一下 iPhone 的屏幕自动锁定时间。在桌面端浏览器中打开 http://localhost:9221/，这是 iwdp 的设备列表。点击当前设备，可以看到当前打开的标签页（如果看不到待调试的标签页，不妨刷新一下，或者关闭 Safari 中多余的标签页），每个标签页的链接是打开 iwdp 自带的调试功能，这里我们不会用到。我们只需要用这个标签页前面的序号，替换 debug kit 给出的链接中 /page/ 后面的末尾的数字即可。
在浏览器中打开这个链接，稍等片刻就能看到开发者工具了。这是 debug kit 自带的 Web 应用，只依赖项目的本地资源运行，不需要科学的上网环境。虽然界面和 Chromium 的 DevTools 有出入，但是功能一点也不少，至少常用的功能如此，包括控制台、网络、DOM 元素等模块。有一个不足是，无法在桌面端预览网页，而只是在手机上显示（至少我没找到这个功能）；相比之下，在 Chrome 上调试 Android 的网页是能在桌面端实时预览并交互的。左上角的选择元素功能，点击之后在手机上点击相应元素，即可在 DOM 视图中高亮该元素。调试简单的网页，完全足够了，通过这个方法我终于找到了博客上的 bug 并修复。
关于 ios_webkit_debug_proxy
在网上搜索相关问题时，会看到 ios_webkit_debug_proxy 这个项目，上文 debug kit 也依赖它。这个项目是谷歌维护的，可以将 Safari 的调试协议转换成 Chrome 可以解析的调试协议。通过 Scoop 安装也很简单，Scoop 是 Windows 上的一个流行的非官方的软件包管理器，相当于 Homebrew 之于 macOS。
然后直接在终端中启动 iwdp 即可。问题是按照步骤打开之后，是无法调试的。在 chrome://inspect 中试图调试对应标签页，页面是空白的，即使我正确配置了网络代理也如此。经查，是因为新版本的 Chrome 的调试协议变化较大，无法兼容。
