Python+Selenium+Chrome两类启动错误互斥，如何优化运行稳定性？

问题本质 #

遇到的两类报错并不是解决方案互斥，而是之前的固定配置思路本身有缺陷：

• 手动写死--remote-debugging-port=9222的写法在生产环境很容易因为端口被占用、多实例并发抢端口，导致Chrome渲染进程无法被正常连接，触发unable to connect to renderer报错
• 不配置调试端口时，89这类早期版本的Chrome在无桌面的服务器环境下，不会自动生成驱动启动需要的DevToolsActivePort文件，触发文件不存在的报错
  两种报错的根源不是“要不要加调试端口参数”，而是配置方式没有适配服务器环境的特性。

可直接落地的配置调整 #

• 把写死的固定9222端口配置，替换为自动分配空闲端口的写法：用--remote-debugging-port=0替代原来的固定9222，这个参数会让Chrome自动选择系统当前未被占用的空闲调试端口，既可以正常触发DevToolsActivePort文件的生成，解决文件不存在的报错，又不会出现端口冲突导致的渲染进程连接失败。
• 补上服务器环境的必配参数，从底层减少进程崩溃概率：
  • 添加--disable-dev-shm-usage：解决Linux服务器上/dev/shm共享内存默认空间不足的问题，这个参数是89版本Chrome在生产环境出现渲染进程失联的最常见诱因
  • 把原来的裸headless参数替换为兼容89版本的--headless=chrome，避免旧版无头模式的进程管理bug
  • 添加--disable-gpu：无桌面服务器环境下关闭GPU模块，避免无意义的启动失败
  • 添加--disable-extensions、--disable-background-networking：减少Chrome启动时的额外资源占用和端口抢占
• 给每个启动的浏览器实例分配独立的临时用户数据目录，避免多实例并发时因为配置文件锁冲突导致的启动失败，不要用全局固定的用户数据目录路径。

修复后的可直接复用的代码 #

from selenium import webdriver
import chromedriver_binary
from selenium.webdriver.chrome.options import Options
import tempfile
import random

def launch_browser(headless=False):
    options = Options()
    # --no-sandbox 必须放在所有配置项最前面
    options.add_argument("--no-sandbox")
    # 解决共享内存不足导致的渲染进程崩溃
    options.add_argument("--disable-dev-shm-usage")
    # 无桌面环境关闭GPU模块
    options.add_argument("--disable-gpu")
    # 关闭易引发冲突的模块
    options.add_argument("--disable-extensions")
    options.add_argument("--disable-background-networking")
    # 兼容89版本Chrome的无头模式写法
    if headless:
        options.add_argument("--headless=chrome")
    # 自动分配空闲调试端口，替代固定9222的配置
    options.add_argument("--remote-debugging-port=0")
    # 为每个实例分配独立临时目录，避免锁冲突
    options.add_argument(f"--user-data-dir={tempfile.gettempdir()}/chrome_{random.randint(10000,99999)}")

    driver = webdriver.Chrome(options=options)
    return driver

额外的稳定性优化 #

• 不要长期停留在89版本的Chrome/Chromedriver，这个版本的无头模式本身存在较多进程管理的已知bug，后续升级到大版本匹配的稳定版Chrome，可以大幅减少这类偶发的会话失效问题，版本匹配只需要保证Chrome和Chromedriver的大版本号完全一致即可，不需要严格对齐到小版本。
• 可以给driver启动逻辑加简单的重试兜底：如果捕获到启动时的会话创建异常，间隔2秒后重新尝试1-2次，这类报错大多是临时的资源抢占导致的，简单重试就能覆盖大部分偶发场景。

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