本文讲解Appium中获取WebView上下文时因误打印集合对象导致重复显示[NATIVE_APP, WEBVIEW_chrome]的问题，指出关键错误在于循环内打印了整个Set而非单个context，并提供修正代码与调试建议。
本文讲解appium中获取webview上下文时因误打印集合对象导致重复显示[native_app, webview_chrome]的问题，指出关键错误在于循环内打印了整个set而非单个context，并提供修正代码与调试建议。
在使用Appium进行混合应用（Hybrid App）自动化测试时，常需在NATIVE_APP和WEBVIEW上下文之间切换，以便操作原生控件或Web元素。一个典型场景是：点击登录按钮后，页面跳转至内嵌Chrome WebView，此时需通过driver.getContextHandles()获取可用上下文列表，并切换至WEBVIEW_chrome执行后续操作。
但开发者常遇到如下异常输出：
[NATIVE_APP, WEBVIEW_chrome] [NATIVE_APP, WEBVIEW_chrome]
这并非上下文真实重复，而是日志逻辑错误所致——问题代码中在for循环内打印的是整个contextNames集合（即System.out.println(contextNames)），而非当前迭代的单个上下文字符串context。由于contextNames是一个Set<string></string>，其toString()方法默认返回类似[NATIVE_APP, WEBVIEW_chrome]的格式化字符串；而循环执行两次（因为集合含两个元素），每次均输出完整集合，从而造成“重复两行相同内容”的假象。
✅ 正确做法是打印每个独立的上下文名称：
Set<string> contextNames = driver.getContextHandles();
System.out.println("Available contexts: " + contextNames); // 仅一次，查看全量
for (String context : contextNames) {
System.out.println("Context: " + context); // ✅ 正确：逐个输出
}</string>
运行后将得到清晰、无冗余的日志：
Available contexts: [NATIVE_APP, WEBVIEW_chrome] Context: NATIVE_APP Context: WEBVIEW_chrome
⚠️ 注意事项：
-
getContextHandles()返回的是不可变快照，不随页面动态变化实时更新，如需捕获新出现的WebView（例如H5页加载后才注入），应在触发跳转后显式等待并重新调用该方法； - 切换上下文前务必确认目标上下文存在，推荐使用
contextNames.contains("WEBVIEW_chrome")校验； - 部分Android设备可能显示为
WEBVIEW_com.xxx.app而非固定WEBVIEW_chrome，建议用context.startsWith("WEBVIEW_")做兼容性判断； - 切换上下文后，需重新定位Web元素（原
WebElement实例在上下文变更后失效）。
掌握上下文句柄的正确遍历方式，是稳定操作Hybrid App中WebView内容的基础。避免低级打印失误，能显著提升调试效率与脚本健壮性。
