Selenium+Python脚本在Chrome 103版本运行崩溃如何解决

已知前置特征：脚本在Chrome 102版本运行完全正常，排除核心业务逻辑错误，偶现启动成功但循环执行到第5次左右崩溃，问题仅在Chrome 103版本复现。 #

一、优先排查版本兼容硬问题 #

• 核对ChromeDriver与Chrome的精确版本匹配：Chrome 103存在多个小版本迭代（包括103.0.5060.24、103.0.5060.66、103.0.5060.134等），不能只匹配103大版本号，必须使用和本地Chrome安装包小版本号差不超过1的对应ChromeDriver，版本不匹配时会出现内存寻址偏移问题，循环执行时累积触发崩溃。
• 核对Selenium版本适配性：Chrome 103对CDP（Chrome DevTools Protocol）接口做了3处非向下兼容调整，Selenium版本低于4.2.0时，底层调用CDP实现隐式等待、元素定位、页面加载状态监听的逻辑会存在内存泄漏，内存占用随循环次数累积到阈值就会触发Chrome进程崩溃。如果当前使用Selenium 3.x版本，要么升级到4.2.0及以上的Selenium 4版本，要么手动给Selenium 3.x打Chrome 103对应的CDP接口适配补丁。

二、抓取崩溃日志定位具体触发原因 #

启动Chrome时追加启动参数--enable-logging --v=1，崩溃后到Chrome用户数据目录读取chrome_debug.log，根据日志特征对应修复：

• 日志出现GPU process exited with code 5：这是Chrome 103独有的已知bug，默认开启的GPU硬件加速和Selenium的沙箱/无头模式存在冲突，启动Chrome时追加参数--disable-gpu --disable-software-rasterizer即可解决，该问题在Chrome 102版本不存在。
• 日志出现Renderer process OOM：Chrome 103默认开启的BackForwardCache功能会驻留所有打开过的页面资源不释放，循环执行时内存占用逐轮上涨，通常到第4-6轮就会占满内存触发渲染进程崩溃，启动参数追加--disable-features=BackForwardCache,TranslateUI关闭该特性即可。
• 日志出现Shared memory region creation failed：Linux环境下/dev/shm默认空间较小，Chrome 103的共享内存占用比102版本高30%左右，循环执行时很容易因为共享内存不足崩溃，启动参数追加--disable-dev-shm-usage --no-sandbox即可。

三、适配Chrome 103的逻辑变更 #

即使业务逻辑没有问题，Chrome 103对部分接口的执行逻辑做了调整，旧的写法会触发隐性资源泄漏：

• 旧版无头模式参数--headless在Chrome 103中被标记为废弃，存在随机崩溃问题，替换为新无头模式参数--headless=new。
• Chrome 103调整了driver.close()、driver.quit()的句柄回收逻辑，102版本下即使不主动清理多余标签页、缓存也不会出现泄漏，103版本下每轮循环结束必须手动清理残留资源，可在每轮循环收尾加如下固定回收逻辑：

# 每轮循环执行完业务操作后运行
# 关闭所有多余标签页
while len(driver.window_handles) > 1:
    driver.switch_to.window(driver.window_handles[-1])
    driver.close()
# 切回主标签页，清理缓存，强制触发内存回收
driver.switch_to.window(driver.window_handles[0])
driver.delete_all_cookies()
driver.execute_cdp_cmd("Memory.forcedGarbageCollection", {})

四、最终验证方案 #

先把上述提到的适配启动参数全部加上，连续跑10次以上循环，如果不再崩溃，再逐个移除参数定位具体触发项；如果仍然崩溃，直接替换Chrome 103分支的最终稳定版103.0.5060.134，该版本修复了103早期版本所有和自动化框架相关的已知崩溃问题，不要使用103分支的早期测试版。 #

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