chromium启动失败主因是缺运行时依赖库、沙箱限制或字体缺失；需在debian/ubuntu镜像中显式安装libnss3、libgbm1等全部依赖，并用--headless=new --no-sandbox --disable-gpu --dump-dom验证是否真能运行。
Chromium 启动失败，不是代码写错了，而是容器里根本没装对东西——缺库、没字体、沙盒被拦，三者占一个就起不来。
为什么 apt install chromium 还是报错「Chrome failed to start」
Debian/Ubuntu 基础镜像下，apt install chromium 只装了主程序，不自动拉运行时依赖。Chrome 一启动就卡在 error while loading shared libraries，典型缺失包括 libnss3、libgbm1、libxss1、libasound2 等。这些库在桌面系统里默认存在，但 slim 镜像里全得手动补。
- 必须显式安装全部运行依赖，不能只装
chromium或chromium-driver -
chromium-driver和chromium必须来自同一源（同仓库、同版本），否则WebDriverException: unknown error: Chrome failed to start会反复出现 - Alpine 镜像要换思路：
apk add chromium chromium-chromedriver更可靠，版本天然一致
如何验证 Chromium 是否真能跑起来
别信 which chromium 的输出，它只说明文件存在。真正要看的是进程能否初始化渲染上下文。最简检测方式是在容器里执行：
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
chromium --headless=new --no-sandbox --disable-gpu --dump-dom about:blank
如果返回 HTML 内容，说明基础环境 OK；如果卡住、报段错误或直接退出，就是缺库或参数不对。
- 必须加
--headless=new（旧版--headless在新版 Chromium 已弃用） -
--no-sandbox是容器里绕过 user namespace 限制的必要妥协，但得配合--disable-dev-shm-usage防止/dev/shm空间不足崩溃 - 中文网页截图乱码？补
fonts-liberation和ttf-wqy-zenhei，不是可选项
Dockerfile 中 Chromium 安装的两种安全路径
选错基础镜像或安装顺序，会导致构建成功但运行失败。关键不是“能不能装上”，而是“装完能不能用”。
- 推荐用
python:3.10-bookworm而非slim：bookworm 自带较新chromium包，依赖链更完整 - Debian 系统一气呵成安装（避免分多步导致缓存干扰）：
RUN apt-get update && \
apt-get install -y --no-install-recommends \
chromium \
chromium-driver \
fonts-liberation \
libnss3 \
libgbm1 \
libxss1 \
libasound2 \
libatk-bridge2.0-0 \
libx11-xcb1 && \
rm -rf /var/lib/apt/lists/*
- Alpine 用户直接走
apk（别混用pip install chromedriver-py）：
RUN apk add --no-cache \
chromium \
chromium-chromedriver \
ttf-dejavu \
ttf-droid \
nss
最容易被忽略的点：Selenium 初始化时必须显式传参，不能依赖默认行为。哪怕 Chromium 在 /usr/bin/chromium，也得写 executable_path="/usr/bin/chromium" + options.add_argument("--no-sandbox")，少一个参数，WebDriverException 就立刻回来。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
