必须用EC.alert_is_present()显式等待原生弹窗，超时返回None需判空；fixture统一处理alert可避免UnexpectedAlertPresentException；DOM弹窗需用visibility条件定位并注意iframe上下文。
弹窗干扰必须在页面操作前主动拦截或兜底处理，不能靠“等它出现再 try”，否则测试会卡死或误判。
怎么用 WebDriverWait 等待并判断 alert 是否存在
直接调用 switch_to.alert 会抛 NoAlertPresentException，但显式等待能避免硬错。关键不是“等弹窗”，而是“等弹窗状态可判定”：
-
EC.alert_is_present()是唯一可靠的等待条件，它内部捕获异常并返回布尔值 - 超时后返回
None，需手动判空，不能直接链式调用.accept() - 注意：该条件只对 JavaScript 原生弹窗（
alert/confirm/prompt）有效，对 DOM 模态框无效
from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC <p>try: alert = WebDriverWait(driver, 2).until(EC.alert_is_present()) alert.accept() # 或 dismiss() / send_keys() except TimeoutException: pass # 没有弹窗，继续执行
pytest 中如何用 fixture 统一注入弹窗处理逻辑
把弹窗处理逻辑下沉到 fixture，比每个 test 函数里重复写 try/except 更可靠，也避免漏覆盖：
- 使用
autouse=True的 session 或 function 级 fixture，在每次页面跳转后自动检查 - 不能只依赖
driver.get()后的 hook，AJAX 触发的弹窗需要额外监听（如点击按钮后） - 推荐在 fixture 中封装一个
handle_alert_if_present()工具函数，供测试用例按需调用
@pytest.fixture(autouse=True)
def handle_alerts(driver):
yield
# 页面操作后统一检查一次
try:
alert = driver.switch_to.alert
alert.accept()
except NoAlertPresentException:
pass
为什么 switch_to.alert 在某些环境会报 UnexpectedAlertPresentException
这不是代码写错了，而是 Selenium 在执行其他操作（如 click()、find_element()）前，检测到已有未处理的 alert，直接中断流程并抛这个异常：
立即学习“Python免费学习笔记（深入）”；
- 它比
NoAlertPresentException更严重，表示“你漏处理了，现在连基本操作都做不了” - 常见于：上一步操作触发了 alert，但没处理，下一步又调用了
click() - 解决方式不是 catch 它，而是在所有可能触发 alert 的操作后，立即加兜底处理（比如封装成带 alert 清理的 click 方法）
def safe_click(element):
element.click()
try:
driver.switch_to.alert.accept()
except NoAlertPresentException:
pass
自定义 DOM 弹窗（非 alert）该怎么定位和关闭
这类弹窗本质是 HTML 元素，但常被遮罩层、动态 ID、iframe 隔离，导致常规查找失败：
- 优先用
visibility_of_element_located而非presence_of_element_located，避免查到不可见节点 - 如果弹窗在
iframe内，必须先switch_to.frame()，处理完再switch_to.default_content() - 关闭方式取决于实现：可能是
click()关闭按钮、execute_script()设置style.display="none"、或触发data-dismiss属性 - 别用
time.sleep()等弹窗出现——显式等待 + 最大重试 2 次更稳
wait = WebDriverWait(driver, 5) close_btn = wait.until(EC.element_to_be_clickable((By.CSS_SELECTOR, ".modal .close"))) close_btn.click()
真正难处理的不是 alert 本身，而是它出现的时机不可预测、且常伴随网络延迟或 JS 执行顺序问题；最稳妥的做法，是把弹窗响应逻辑绑定在用户动作之后（比如点完按钮立刻查 alert），而不是分散在各处靠运气 catch。
