WkWebView复制文本触发APP冻结，如何排查调试？

首先，那条日志Returning local object of class NSString PBItemCollectionServicer connection disconnected其实指向了系统粘贴板服务（和UIPasteboard关联的PBItemCollectionServicer）的异常断开，这说明冻结大概率和复制触发的粘贴板交互有关——哪怕你没写自定义复制代码，也可能是隐性冲突或系统层面的问题。下面是具体的排查步骤：

• 先做环境隔离测试
  新建一个极简Demo，只初始化一个WKWebView加载你出问题的网页，测试复制操作是否会冻结。如果Demo里没问题，那肯定是主APP里的其他代码和WKWebView冲突了——比如全局的粘贴板监听、第三方SDK的钩子，或者AppDelegate里的某些全局逻辑。

• 检查粘贴板相关的隐性代码
  虽然你说没自定义复制逻辑，但要排查：

  • 有没有注册UIPasteboardChangedNotification或UIPasteboardRemovedNotification这类通知？如果通知回调里在主线程做了耗时操作（比如解析大文本、频繁操作UI），很容易卡死。
  • 有没有第三方SDK用到了粘贴板？比如某些统计、分享SDK可能会偷偷监听粘贴板，处理不当就会引发问题。
  • 有没有自定义UIPasteboard的分类或者扩展？这类代码可能干扰系统的粘贴板服务流程。

• 用Instruments抓主线程阻塞点
  暂停调试器没有效信息的话，Time Profiler工具是关键：

  1. 打开Xcode，选择Product > Profile，启动Instruments后选中Time Profiler。
  2. 操作APP触发复制冻结，等几秒后停止录制。
  3. 在左侧选中主线程，查看调用栈里的耗时方法——大概率能找到卡住的根源，比如某个锁等待、耗时的字符串处理，或者第三方库的阻塞方法。

• 排查WKWebView的配置和注入脚本
  检查你的WKWebViewConfiguration细节：

  • 有没有通过userContentController注入过JS脚本？有些脚本可能全局监听了copy事件，哪怕你没刻意处理，也可能和系统复制流程冲突。
  • 有没有开启allowsLinkPreview、mediaTypesRequiringUserActionForPlayback这类属性？某些属性在特定iOS版本下可能和复制操作存在兼容性问题。
  • 有没有设置自定义的WKUIDelegate或WKNavigationDelegate？这些代理方法里的逻辑会不会在复制时被意外触发，导致主线程阻塞？

• 验证系统版本和设备兼容性
  换不同iOS版本的设备测试（比如iOS 15、16、17），看是不是特定版本的系统bug。比如部分iOS版本里WKWebView的复制操作和粘贴板服务存在进程通信的bug，这种情况可以尝试绕过：拦截网页的copy事件，用JS获取选中文本，自己调用UIPasteboard.general.string设置内容，跳过系统默认的复制流程。

• 查看完整系统日志
  打开Mac上的Console.app，过滤你的APP名称，查看冻结前后的所有日志——除了那条PBItemCollectionServicer的日志，有没有WebContent进程崩溃、粘贴板服务超时这类相关报错？这些细节能帮你更快定位问题根源。

内容的提问来源于stack exchange，提问作者andromedainiative