Chrome启动失败根本原因在于容器环境缺失系统库（如libgbm1、libnss3）、无图形界面未配--headless=new、沙盒机制被禁用，而非代码或版本问题。
Chrome 启动失败，根本不是 Selenium 代码问题，而是容器里缺库、没显卡、沙盒被拦。
为什么 chrome-driver 连不上 chrome
常见现象是 WebDriverException: unknown error: Chrome failed to start 或直接卡在初始化阶段。这不是 chromedriver 版本不匹配（虽然也得对），而是底层 Chrome 根本没起来——google-chrome-stable 进程启动就退出，chromedriver 自然连不上。
根本原因有三个：
-
libgbm.so.1、libnss3、libxss1等系统库缺失，Chrome 直接报error while loading shared libraries - 无图形界面环境下，缺少
Xvfb或--headless=new配合不当，导致渲染初始化失败 - 容器默认禁用
user namespaces，Chrome 沙盒机制触发Failed to move to new namespace
Dockerfile 中必须装哪些依赖
Ubuntu/Debian 基础镜像下，光装 google-chrome-stable 不够，必须显式安装运行时依赖。以下命令缺一不可：
RUN apt-get update && \
apt-get install -y --no-install-recommends \
curl \
wget \
gnupg \
fonts-liberation \
libappindicator3-1 \
libasound2 \
libatk-bridge2.0-0 \
libatk1.0-0 \
libcups2 \
libx11-xcb1 \
libxcomposite1 \
libxdamage1 \
libxfixes3 \
libxrandr2 \
libxss1 \
libxtst6 \
lsb-release \
xdg-utils \
libgbm1 \
libnss3 \
libxshmfence1 \
libdrm2 && \
rm -rf /var/lib/apt/lists/*
特别注意：
-
libgbm1和libnss3是高频缺失项，不装必报错 -
--no-install-recommends能显著减小镜像体积，但会跳过部分非必需但 Chrome 实际用到的包（如libasound2），所以得手动补全 - CentOS/RHEL 系镜像请改用
yum install -y对应包名，例如libXScrnSaver替代libxss1
启动 Chrome 必须加的参数
即使依赖全了，不加关键启动参数，Chrome 在容器里照样起不来。最简可用组合是：
google-chrome \ --headless=new \ --no-sandbox \ --disable-gpu \ --disable-dev-shm-usage \ --remote-debugging-port=9222 \ --single-process \ --disable-extensions
逐个说明：
Python 3.14.3
微软官方的 Python 扩展，是 VS Code 安装量最高的扩展（209M+）。集成 IntelliSense（通过 Pylance）、调试（通过 Python Debugger）、代码检查、格式化、重构和单元测试等功能。支持 Jupyter Notebook、虚拟环境管理和多 Python 版本切换。
-
--headless=new：新 headless 模式（Chrome 112+），比旧版--headless --disable-gui更稳定 -
--no-sandbox：容器中无法启用 user namespace 沙盒，必须关掉，否则权限拒绝 -
--disable-dev-shm-usage：避免共享内存不足（Docker 默认 shm size 只 64MB） -
--single-process：减少多进程带来的容器兼容性问题，适合自动化场景
别信“只加 --no-sandbox 就够了”——在 CI 或低配容器里，--disable-dev-shm-usage 和 --single-process 经常是成败关键。
chromedriver 版本怎么和 chrome 对齐
不要硬编码版本号，用动态方式获取 Chrome 版本再拉对应 driver：
RUN CHROME_VERSION=$(google-chrome --version | grep -oE '[0-9]+\.[0-9]+\.[0-9]+') && \
wget -O /tmp/chromedriver.zip https://chromedriver.storage.googleapis.com/${CHROME_VERSION}/chromedriver_linux64.zip && \
unzip /tmp/chromedriver.zip -d /usr/local/bin/ && \
chmod +x /usr/local/bin/chromedriver && \
rm /tmp/chromedriver.zip
这个写法能规避两个坑：
- Chrome 自动升级后，旧版
chromedriver报session not created: This version of ChromeDriver only supports Chrome version X - 手动维护版本映射表容易漏，尤其 Chrome 大版本更新频繁（比如 124 → 125）
如果构建阶段 google-chrome --version 报错，说明前面依赖或安装步骤失败，得回头检查 libnss3 等是否真装上了。
真正麻烦的从来不是写几行 Dockerfile，而是在没图形、没权限、没共享内存的容器里，把一个桌面级浏览器“骗”得以为自己在正常运行。每少装一个 libxxx，每漏加一个 --xxx 参数，都可能让整个自动化链路静默失败——而且错误日志往往只显示“connection refused”，根本看不出是底层库缺失。