Selenium 调试 Edge 自动化：驱动版本、等待与稳定性实战

1. 先把调试思路理顺：Edge 自动化的三层结构

凡是 Selenium 跑 Edge 卡住的人，十个里有八个不是脚本写错了，而是没搞清楚自己的代码到底在跟谁对话。我第一次在 Edge 上跑自动化脚本的时候，报错信息只有一句Unable to obtain browser driver，翻来覆去查了半天代码，最后发现问题出在驱动文件上。所以聊“Selenium 调试 Edge 浏览器的常见问题与解决方案”之前，我先把这条链路的层次摆清楚，后面所有的坑都能对号入座。

Selenium 驱动 Edge 的过程其实分三层：脚本层（你写的 Python/Java 代码，通过 WebDriver 协议发 HTTP 请求）、驱动层（msedgedriver这个可执行文件，接收协议指令并翻译成浏览器内部命令）、浏览器层（Edge 本体，执行真实操作）。三层之间是两个独立的握手：脚本连驱动，驱动连浏览器。任何一次握手失败，表现都是“脚本报错”，但病因可能完全在不同的层。这就是为什么很多人看着报错猜原因，越猜越偏。

1.1 三层结构决定了排查入口

把这三层想成寄快递会更容易理解。你的脚本是寄件人，msedgedriver是快递网点，Edge 浏览器是收件人。网点地址写错（驱动路径不对）、网点不认这个包裹（版本不匹配）、收件人不在家（浏览器启动参数把窗口干掉了），报错都会回到寄件人这里，但处理方式完全不同。所以我排查时习惯先问自己三个问题：驱动文件存不存在、驱动和浏览器版本对不对得上、浏览器进程有没有真的起来。

提示：遇到任何启动失败，先别改代码。先手动在命令行里执行一次驱动和浏览器，确认这两层是通的，再回到脚本。这一步能省掉大量无效试错。

1.2 Edge 的坑为什么比别的浏览器更集中

Chromium 内核的浏览器用 Selenium 驱动的原理基本一致，但 Edge 有几个很实际的特点会把问题放大。一是 Edge 与操作系统的绑定更紧，系统更新、浏览器的“自动更新”机制会在你不知道的时候把主版本号往前推一格，第二天脚本就挂了。二是msedgedriver的分发渠道和版本号命名习惯，让“我该下哪个版本”这个问题比想象中更容易出错。三是 Edge 默认开启的一些账户同步、侧边栏、首次运行引导，会在自动化启动时弹出各种打断流程的界面，无头模式下还可能直接卡在某个初始化弹窗上。

我在一个批量任务里吃过这个亏：本地跑得好好的脚本，换到另一台机器上，前五个用例全部超时。排查后发现那台机器的 Edge 是自动更新到新主版本的，而驱动还停在旧版本，驱动启动时尝试连接失败，脚本侧看到的只是“连接被拒绝”。这件事之后我养成了一个习惯，任何要长期跑的 Edge 自动化项目，第一件事就是把版本检测做成一个独立脚本，跑任务前先执行一遍。

1.3 起手式：一份对齐最小闭环的环境清单

动手之前，下面这几项确认完，后面 80% 的低级问题可以直接跳过。我把它做成了一个检查清单，每次搭新环境都照着过一遍。

最后一项特别容易被忽略。驱动是个可执行文件，某些终端防护策略会把它当成可疑程序拦下来，表现是“文件明明在，就是启动不了”，而且不报明确的权限错误。我遇到过一次，把驱动目录加到信任列表之后立刻恢复正常，前后折腾了四十分钟。所以把“能不能手动执行”作为一项硬指标，比任何日志分析都直接。

2. 驱动版本不匹配：最高频的失败点

如果说 Edge 自动化有一个“永恒主题”，那就是驱动版本。这个问题的麻烦之处在于，它不一定表现为清晰的版本报错，有时候表现为浏览器窗口一闪而过，有时候表现为会话建立后所有操作都超时，还有时候表现为随机崩溃。

2.1 版本号到底怎么对：分段对齐规则

先看清楚版本号的构成。Edge 的版本号是四段式，比如124.0.2478.80，四段分别是主版本、次版本、构建号、修订号。msedgedriver的版本号也是同样的格式。业界通行的兼容规则是：主版本号必须一致，其余段越接近越好。主版本一致意味着浏览器内部调试协议的核心接口没变，驱动能正常握手；次版本和构建号差异通常兼容，但如果用到某些较新的能力（比如特定的设备模拟、网络拦截），就可能踩到接口差异。

实操上我建议直接取完整四段一致，别抱侥幸心理。原因很简单：主版本一致只是“能连上”，能不能稳定跑完整套用例是另一回事，而排查“连上了但偶尔失败”的成本远高于重新下一份驱动。

版本对齐有个容易搞错的地方：edge://version页面上显示了两行版本，一行是浏览器版本，一行是内核版本，两者通常相同但显示位置不同。别把另一款同内核浏览器的版本号抄过来，驱动认的是 Edge 自己的版本标识。我有一次顺手复制了旁边那行数字，结果下载的驱动死活连不上，查了半小时才发现抄错了行。

2.2 三种驱动管理方式的取舍

驱动从哪来、放在哪，有三种常见做法，各有适用场景。

第一种，手动下载固定路径。把msedgedriver.exe放到一个项目内的drivers目录，代码里用Service(executable_path=...)指定绝对路径。优点是可控、可离线、版本固定，适合公司内网或者 CI 环境无法访问外网的情况。缺点是每次 Edge 升级都要手动换文件，容易忘。

第二种，交给 Selenium 自带的驱动管理器。Selenium 4.6 之后内置了自动下载与缓存机制，只要不指定executable_path，它会在需要时自己判断版本并拉取驱动，缓存到用户目录下。优点是省心，适合个人开发和本地调试。缺点是有时判断滞后，或者缓存目录权限受限导致下载失败，而且它对网络有依赖。

第三种，自己写一段版本检测 + 下载逻辑。从浏览器安装目录拿到版本号，拼出驱动下载地址，下载后校验并缓存。灵活度最高，代价是要维护一段代码。团队里长期维护的项目我一般选这个方案，因为可以把“版本不对”这件事变成脚本内部的一个自动动作，而不是一个人肉运维环节。

注意：三种方式不要混用。一会儿让自动管理器接管，一会儿又在代码里写死executable_path，最容易出现“本地好好的，换台机器就不行”的诡异问题。一个项目只保留一条路径。

2.3 驱动放哪里，怎么被找到

如果选固定路径，路径本身有几个坑要躲。第一是空格和中文。放在C:\Program Files\或者带中文的目录下，某些调用方式会把路径截断，表现是“找不到文件”但文件明明在。我现在的习惯是驱动统一放在一个纯英文、无空格的短路径下，比如D:\auto\drivers\。

第二是PATH 环境变量。把驱动目录加进 PATH 之后，代码里就可以只写msedgedriver而不写全路径。这么做的好处是换机器时改一次 PATH 就行，坏处是容易出“到底用的哪个驱动”的困惑——系统里可能同时存在好几个版本，PATH 顺序决定了谁生效。

第三是权限。如果放在系统目录下，非管理员账户可能没有执行权限；如果放在用户目录下，又有可能被安全策略限制。折中方案是放在项目目录或者用户主目录下的一个专用文件夹，权限问题最少。

调试时可以加一行日志把实际使用的驱动路径打出来，这行日志救过我很多次：

from selenium import webdriver from selenium.webdriver.edge.service import Service service = Service(executable_path=r"D:\auto\drivers\msedgedriver.exe") print("driver path:", service.path)

如果这行打印出来的路径和你以为的不一样，说明有环境变量或配置在偷偷覆盖，先解决这个再谈其他。

2.4 一条命令验证驱动是否可用

驱动跑不起来的时候，最快的定位方式不是跑脚本，而是在命令行直接问驱动自己：

D:\auto\drivers\msedgedriver.exe --version

正常会输出类似Microsoft Edge WebDriver 124.0.2478.80的信息。如果这行报错，说明驱动文件本身有问题（下载不完整、被拦截、位数不匹配），跟 Selenium 和脚本一点关系都没有。这一步能非常干脆地把问题范围砍掉一半。

再进一步，可以手动让驱动去连一次浏览器：

D:\auto\drivers\msedgedriver.exe --port=9515

然后另开一个终端向http://127.0.0.1:9515/status发一次请求。返回结构里ready为真、带版本信息，说明驱动层是活的。这个做法在排查“脚本连不上驱动”时特别有用，因为它把脚本完全剥离了。

3. 启动参数与浏览器配置的实操细节

驱动版本对齐之后，第二大类问题就集中在启动配置上。Edge 的启动参数非常多，但真正需要天天用的就那么几组。这一节我把它们按用途拆开讲，每一条都说清楚为什么加。

3.1 最该先加的几组参数

第一组，稳定性基础参数。自动化环境和人工点开浏览器是两种使用场景，很多为人工体验设计的特性在自动化里只会添乱。

from selenium.webdriver.edge.options import Options opts = Options() opts.add_argument("--disable-extensions") # 关扩展，避免插件弹窗干扰 opts.add_argument("--no-first-run") # 跳过首次运行引导 opts.add_argument("--no-default-browser-check") opts.add_argument("--disable-gpu") # 无头环境下避免渲染相关异常 opts.add_argument("--window-size=1440,900") # 明确窗口尺寸，避免元素不可见

--window-size这条我要单独说。默认窗口尺寸下，很多页面的元素会落在可视区外，Selenium 点击时报“元素不可交互”，但你去截图看，元素明明在那儿。原因是点击操作要求元素在视口内且未被遮挡，窗口太小时布局会变（响应式设计触发），元素位置和你的预期完全对不上。所以固定一个足够大的窗口尺寸，能消掉一大类“玄学点击失败”。

第二组，去掉自动化痕迹的参数。有些站点会检测自动化特征，检测到就弹验证或者直接返回简化页面。相关的两个常用写法是排除enable-automation开关和关闭自动化扩展。这两个属于“能做就做”的优化，不是必需，但做了能少掉一些莫名其妙的差异。

第三组，日志与调试参数。排查阶段非常值得打开驱动日志：

service = Service( executable_path=r"D:\auto\drivers\msedgedriver.exe", log_output=r"D:\auto\logs\driver.log", service_args=["--verbose"] )

驱动日志里会记录每一步协议交互和报错堆栈，比脚本抛出的那一行异常信息详细得多。很多“元素找不到”的问题，在驱动日志里能看到完整的页面加载时间线和查找过程，一眼就能看出是页面没加载完还是选择器写错了。

3.2 用户数据目录：登录态复用与文件占用

需要保持登录状态的任务，通常要指定用户数据目录：

opts.add_argument(r"--user-data-dir=D:\auto\profile")

加上之后，登录一次的 Cookie、本地存储、站点设置都会保留，下次启动直接是登录态，省掉每次跑脚本都要登录的麻烦。但这条参数有两个非常典型的坑。

坑一，目录被占用。同一个用户数据目录不能被两个浏览器实例同时使用。如果上一次脚本异常退出，Edge 进程还没完全退出，下一次启动就会报“用户数据目录已在被使用”或者干脆卡住不动。解决办法是启动前检测并清理残留进程，或者每次用不同的目录名（比如带上时间戳）。后者更干净，但登录态就不复用了，看你的需求取舍。

坑二，无头模式下的登录态。某些站点的登录校验会参考浏览器指纹，无头模式和带界面的模式指纹不同，可能出现“有头能登录，无头就是未登录”。遇到这种情况，先用带界面的模式登录一次把 profile 建好，再用无头模式加载同一个 profile，成功率会高很多。

注意：用户数据目录里存的是真实的账号凭据。不要把 profile 目录提交到代码仓库，也不要在共享机器上保留，做完任务及时清理。这一点在团队协作里特别重要，我见过直接把 profile 打包发同事的操作，风险很高。

3.3 无头模式的两种写法与踩坑

Edge 基于 Chromium，无头模式有新老两种写法：--headless和--headless=new。老写法是早期实现，页面渲染路径和真实浏览器差异较大，一些依赖真实布局的功能（比如截图尺寸、字体渲染、部分 JS 计算）结果会不一样。新写法复用完整的浏览器渲染栈，行为更接近有头模式，现在一般首选新写法。

无头模式最常见的三个坑，我按出现频率排一下。

第一，窗口尺寸必须显式指定。无头模式下默认视口尺寸很小，很多元素不满足可见性条件，点击直接失败。加上--window-size之后通常就好了。

第二，截图是空白或者尺寸不对。这个多半是页面还在动画或者懒加载阶段就截了。加一次显式等待，等目标元素出现或页面高度稳定之后再截。有时候还需要主动滚动触发懒加载，滚动完再等一小会儿。

第三，文件下载在无头模式下不生效。这个不是无头模式独有的问题，但在无头下更容易被忽略，因为你看不到下载栏。必须通过 prefs 指定下载目录并关掉下载确认框，细节放到下一节说。

3.4 下载目录与自动下载策略

自动化里做文件下载，核心是让浏览器“不问、不弹、直接存到指定位置”。这靠的是 prefs 配置：

prefs = { "download.default_directory": r"D:\auto\downloads", "download.prompt_for_download": False, "download.directory_upgrade": True, "safebrowsing.enabled": True, "profile.default_content_setting_values.automatic_downloads": 1, } opts.add_experimental_option("prefs", prefs)

最后一项是允许多文件自动下载，不加的话，页面连续触发两次下载会被拦第二次。

配置完之后还有一个隐性坑：下载是异步的。点击下载按钮之后脚本立刻去检查文件，文件往往还没落地，尤其在下载大文件或者经过服务端生成的情况下。正确做法是轮询检查目录，直到出现目标文件且不再有临时文件后缀。我一般写成“目录里文件数量变化 + 目标文件大小连续两次检查不变”，两个条件同时满足才认为下载完成，比单纯等固定秒数可靠得多。

另外，下载目录必须提前创建好。目录不存在时，不同版本的浏览器行为不一致，有的自动创建，有的直接静默失败，脚本这边完全不报错，只在后面找不到文件时才暴露，非常难查。

4. 定位、等待与页面结构问题

驱动和启动都通了之后，脚本就开始跑业务了，这时候问题会从“启动不了”变成“跑不稳”。跑不稳的原因九成集中在等待策略和页面结构上。

4.1 显式等待与隐式等待的混用陷阱

这个是 Selenium 新手最容易掉进去的坑，而且掉进去之后很难自己爬出来。隐式等待是全局的，设一次对所有元素查找生效；显式等待是针对某个条件的轮询。两者同时开启时会叠加，不是取最大值。

算一笔账。假设隐式等待设 10 秒，显式等待设 15 秒、轮询间隔 0.5 秒：

• 显式等待每次轮询会执行一次元素查找
• 每次查找如果没找到，隐式等待会先等 10 秒才返回“找不到”
• 显式等待最多轮询 15 / 0.5 = 30 次
• 最坏情况下单次等待耗时：30 × 10 = 300 秒

也就是说你以为设了 15 秒超时，实际上可能挂 5 分钟。这就是为什么很多人觉得“脚本卡死了但没报错”，其实它在老老实实等你设的那个组合超时。

我的做法很明确：只用显式等待，隐式等待设 0。所有等待逻辑集中在一个封装好的等待工具里，超时时间统一从配置读取。这样每一处等待都是可预期的，出问题也好定位。

from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.common.by import By driver.implicitly_wait(0) # 显式关掉 def wait_clickable(driver, locator, timeout=15): return WebDriverWait(driver, timeout, poll_frequency=0.5).until( EC.element_to_be_clickable(locator) ) btn = wait_clickable(driver, (By.CSS_SELECTOR, "#submit")) btn.click()

超时时间怎么定？别拍脑袋。我的经验值是按页面实际情况分档：本地静态页面 5 秒足够，普通业务页面 10 到 15 秒，涉及第三方接口或者报表生成的页面 30 秒起步。定完之后跑一批真实用例，统计一下每次等待实际耗时，把超时设成实际最大耗时的 2 倍左右比较合适，既能容忍抖动，又不会在真失败时干等太久。

4.2 iframe 与多窗口切换

元素明明在页面上，选择器也没写错，就是找不到——十有八九在 iframe 里。Selenium 只能操作当前文档上下文里的元素，进了 iframe 就是一个独立文档。处理方式：

from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC WebDriverWait(driver, 15).until( EC.frame_to_be_available_and_switch_to_it((By.ID, "pay-frame")) ) # 操作完记得切回来 driver.switch_to.default_content()

frame_to_be_available_and_switch_to_it这个条件比先等待再切换更稳，因为它把“等 iframe 出现”和“切入”合成一步，避免了两步之间的时间差。切回去这一步千万别忘，否则后续所有查找都在 iframe 里进行，全报找不到。

多窗口的坑在“新窗口还没打开就切换”。点击一个会打开新标签的链接后立刻执行driver.window_handles，可能还是只有原来那一个。正确做法是等待窗口数量变化：

orig = driver.current_window_handle WebDriverWait(driver, 10).until(lambda d: len(d.window_handles) > 1) new = [h for h in driver.window_handles if h != orig][0] driver.switch_to.window(new)

关闭新窗口后也要显式切回原窗口，别依赖自动跳转。顺手清理一下window_handles里残留的已关闭句柄，能让后续调试清晰很多。

4.3 Shadow DOM 里的元素怎么找

现在不少前端组件用了 Shadow DOM 封装，页面源码里能看到标签，但普通 CSS 选择器穿透不进去，表现就是“元素存在但找不到”。这种情况常规的选择器写法全部失效。

处理方式有两条路。一条是用 JS 直接穿透查询，把结果返回给脚本；另一条是在脚本里逐层进入 shadow root。前者的写法大概是这样：

script = """ const host = document.querySelector('my-widget'); const root = host.shadowRoot; const el = root.querySelector('.inner-btn'); return el; """ el = driver.execute_script(script) el.click()

这条路的优点是简单直接，缺点是绕过了 Selenium 的等待机制，需要自己处理元素是否就绪。我的习惯是先等待宿主元素出现，再用 JS 取内部元素，然后加一个“元素可点击”的显式判断，比一次性 JS 搞定更稳。

提示：判断元素是否在 Shadow DOM 里有个土办法。在浏览器开发者工具里用普通选择器搜，搜得到；用document.querySelector在控制台里搜不到，那基本就是被 shadow 包住了。

4.4 元素可见但点不动：遮挡与滚动

ElementClickInterceptedException这个异常我见得最多，字面意思是点击被拦截，实际原因通常是三种：有浮层挡住（弹窗、引导蒙层、固定在顶部的导航条）、元素在视口外、元素动画还没结束。

处理顺序我固定成三步。先等浮层消失（很多弹窗有固定的存活时间，等一两秒就自己没了）；再滚动到元素位置：

driver.execute_script( "arguments[0].scrollIntoView({block: 'center'})", el )

用block: 'center'而不是默认的start，是因为固定导航条常常遮住页面顶部，滚到顶部反而被挡得更死。滚到中间之后，绝大部分遮挡问题就解决了。最后如果还是点不动，退一步用 JS 直接触发点击：

driver.execute_script("arguments[0].click()", el)

这条是保底手段，慎用。因为它绕过了真实用户的交互路径，某些依赖真实鼠标事件的前端逻辑不会被触发（比如某些下拉框、拖拽组件），用了之后可能点击“成功”但页面毫无反应，白白浪费排查时间。我的原则是：先解决遮挡，实在解决不了才用 JS 点击，并且在代码里留注释说明原因。

5. 典型报错速查表与排查路径

调试经验里最值钱的不是“我知道怎么修”，而是“我知道先看哪里”。这一节把高频报错整理成速查表，再讲一套固定的排查顺序。

5.1 报错与病因对照

stale element reference这个我想多说两句。它的本质是“你手里的元素引用已经过期”，页面结构变了，旧的引用指向的节点被销毁了。新手常犯的错是把找到的元素存成全局变量反复用，页面一刷新就全废。正确做法是每次操作前重新查，或者封装成“查找 + 操作”的一体化函数，让元素的生命周期尽可能短。

5.2 固定排查顺序：从底层往上

我给自己定了一套不变的顺序，避免每次瞎猜。

第一步，验证驱动。命令行执行驱动--version，能输出就说明文件层面没问题。

第二步，验证驱动能拉起浏览器。启动驱动监听端口，然后发一次会话创建请求。这一步能区分“驱动问题”和“浏览器问题”。

第三步，跑最小脚本。只做三件事：启动浏览器、打开一个空白页、打印标题、退出。这三步都过了，说明环境完全正常，问题在你的业务代码里。

第四步，打开驱动日志和截图。业务代码出问题时，日志和截图是唯一的现场证据。

这套顺序的价值在于它每一步都在缩小范围，绝不会出现“查了两小时发现方向从一开始就错了”的情况。我早期调试时最大的浪费就是跳过前两步直接改代码，最后发现是驱动文件根本没下全。

5.3 失败现场要留哪些证据

自动化脚本失败时的信息量取决于你留了多少。我的标准配置是三样：当前页面截图、页面源码、驱动日志。截图看视觉状态，源码看 DOM 结构，日志看交互时序，三样凑齐基本能还原失败瞬间。

import datetime, pathlib def dump_evidence(driver, tag="fail"): ts = datetime.datetime.now().strftime("%Y%m%d_%H%M%S") base = pathlib.Path(r"D:\auto\evidence") base.mkdir(parents=True, exist_ok=True) driver.save_screenshot(str(base / f"{tag}_{ts}.png")) (base / f"{tag}_{ts}.html").write_text(driver.page_source, encoding="utf-8") print("current url:", driver.current_url) print("window size:", driver.get_window_size())

这里有个小细节值得说：截图之前先driver.get_window_size()打一下尺寸。我遇到过一次“截图里页面布局全乱”的问题，查了半天以为是前端问题，最后发现是无头模式下窗口尺寸被设成了很小的值，页面进了移动端布局，元素自然全对不上。这个信息如果不打印，光看截图会完全误判。

6. 稳定性与批量运行

单次跑通只是开始，真正折磨人的是把脚本稳定跑上几百次。

6.1 会话复用与残留进程清理

每次任务都新建会话是最稳的做法，但开销大。想复用会话的话，要注意会话状态会累积：Cookie、localStorage、打开的标签页、浏览器缓存都会保留，可能影响后续用例。我的折中方案是同一批用例复用一个会话，批与批之间重建，并且每批开始前显式清理存储：

driver.delete_all_cookies() driver.execute_script("window.localStorage.clear(); window.sessionStorage.clear();")

残留进程是批量运行的头号杀手。脚本异常退出时，msedgedriver和浏览器进程可能还挂在后台，占着端口和用户数据目录，下一次启动直接失败。清理方式：

taskkill /F /IM msedgedriver.exe /IM msedge.exe

注意：这条命令会杀掉机器上所有相关进程，包括你自己手动打开的浏览器窗口。在开发机上用之前想清楚，别把自己正在查资料的窗口一起关了。CI 或者专用执行机上就没这个顾虑。

更好的做法是在代码里用try/finally保证退出：

driver = None try: driver = webdriver.Edge(service=service, options=opts) # 业务逻辑 finally: if driver: try: driver.quit() except Exception: pass

quit()和close()的区别要记牢：close()只关当前窗口，quit()关整个会话并结束驱动进程。批量任务里一律用quit()，不然驱动进程会一个个堆起来。

6.2 并发运行的资源账

想靠多线程提速的话，先算一下资源账。每个浏览器实例的常驻内存按 300 到 500 MB 估（复杂页面会更高），加上驱动进程和页面本身的内存占用。一台 8 GB 的机器，理论上能跑 8 到 10 个实例，但实际建议控制在 4 到 6 个，留出余量，否则会频繁触发内存回收，整体反而变慢。

我实测过一个任务，单实例跑 200 个页面耗时约 18 分钟。改成 4 并发之后耗时降到 6 分钟左右，但再往上加到 8 并发，耗时只降到 5 分钟出头，而且开始出现零星超时失败。这就是典型的边际收益递减加稳定性下降。并发的甜点位置一般出现在“机器核数的一半”附近，超过就得上多机分摊。

并发还有一个隐藏问题：用户数据目录冲突。每个实例必须用独立目录，包括独立下载目录。同一目录被两个实例写，轻则文件覆盖，重则浏览器启动失败。我一般用实例序号拼目录名，简单有效。

6.3 无人值守环境下的额外注意点

在没有图形界面的执行环境里跑 Edge，有几件事和本地开发机不一样。

一是必须开无头模式，且建议用新写法。老写法在某些页面上的渲染结果差异很大，截图对比会明显不同。

二是字体和编码。精简过的环境里可能缺少中文字体，页面渲染出来的中文变成方块，截图没法看，某些依赖文字宽度的布局也会偏。如果业务涉及截图比对或者文字定位，提前装好字体。

三是时区和语言。容器默认通常是 UTC 和英文环境，页面上的时间显示、日期格式会和你本地不一样。涉及日期选择器的用例特别容易在这里翻车，明明本地能选中的日期，在容器里因为格式不同就找不到了。

四是超时时间要放宽。共享资源的执行环境比本地慢，原来 15 秒的等待可能不够。我的做法是通过环境变量注入超时倍数，本地是 1，执行环境是 1.5 到 2，不用改代码就能适配。

最后分享一个我一直在用的小技巧：给每个用例的日志加上会话标识和开始时间。批量跑的时候，几百条日志混在一起，没有标识根本对不上号。加上之后，出问题直接按标识过滤，几秒钟就能定位到那一次完整的过程。这个习惯看起来不起眼，但它把“翻日志找线索”从十几分钟压缩到了几十秒，是我在长期维护 Edge 自动化脚本过程中最实用的一条经验。