• 测试
• 后端
• 云原生
• 容器编排
• 可观测性

本文基于 docker-selenium 仓库CHANGELOG/4.48.0/chrome_106.md这一版本变更记录，逐行拆解 Selenium Grid 4.48.0 时代下 Chrome 106 镜像的完整发布流程：从tag_and_push_browser_images.sh的参数语义、版本自动探测，到 12 个规范标签的命名规则与正确拉取姿势，帮助你读懂版本矩阵、按需固定浏览器版本并精准选取镜像标签。

一、版本矩阵：changelog 文件在整个仓库中的位置

docker-selenium 为每个 Grid 主版本维护一套「Selenium Grid × 浏览器版本矩阵」，总览入口是 CHANGELOG/README.md。矩阵中每一格是一个✓链接，指向对应 Grid 版本 + 浏览器版本的详细变更记录文件，例如本篇文章的主角 CHANGELOG/4.48.0/chrome_106.md 就对应「Grid 4.48.0 + Chrome 106」这一格。

该矩阵的设计动机，正如 CHANGELOG/README.md 开头所述：既要持续供应最新的 Selenium Grid 核心版本，又要让用户能固定（pin）某个浏览器版本用于跨浏览器测试，或规避特定浏览器版本上的兼容性问题。因此仓库会同时发布 Node 与 Standalone 两类镜像，并在其中打包「Grid 版本 + 浏览器版本 + 驱动版本」三元组，用户只需找到目标标签、拉取镜像即可开始测试。

需要特别说明的是：README 中明确提示，项目并未对「Grid × 浏览器」的每一种组合做全量回归测试，用户应根据自身测试需求评估选择；版本记录文件记录的是「该组合确实被打包并打上了标签」这一事实。

二、逐行解读：一次真实的 Chrome 106 标签发布会话

chrome_106.md全文是一段命令执行日志，完整记录了针对旧版浏览器 Chrome 106 执行镜像打标签脚本的过程。命令本身为：

./tag_and_push_browser_images.sh 4.48.0 20260909 selenium false chrome true

对应脚本 tag_and_push_browser_images.sh 的参数定义（见脚本 L3-L9），各位置参数含义如下：

日志的第 3 行Tagging images for browser chrome, version 4.48.0, build date 20260909, namespace selenium对应脚本 L59 的输出，随后脚本进入case "${BROWSER}"的chrome)分支（L61-L106）。

2.1 版本号的自动探测：docker run + awk

脚本并不会假设镜像内装了什么版本，而是直接运行刚构建好的 Node 镜像去探测（L65-L73）：

CHROME_VERSION=$(docker run --platform ${PLATFORM} --rm ${NAMESPACE}/node-chrome:${TAG_VERSION} google-chrome --version | awk '{print $3}') CHROMEDRIVER_VERSION=$(docker run --platform ${PLATFORM} --rm ${NAMESPACE}/node-chrome:${TAG_VERSION} chromedriver --version | awk '{print $2}')

• google-chrome --version的输出形如Google Chrome 106.0.5249.119，因此awk '{print $3}'取到106.0.5249.119；
• chromedriver --version的输出形如ChromeDriver 106.0.5249.61 (...), 因此awk '{print $2}'取到106.0.5249.61。

日志中Chrome version -> 106.0.5249.119与ChromeDriver version -> 106.0.5249.61正是这一探测结果。

随后short_version()函数（L53-L57）将完整版本号按.切分并只取前两段：106.0.5249.119→106.0，106.0.5249.61→106.0。这就是日志中Short Chrome version -> 106.0与Short ChromeDriver version -> 106.0的由来。短版本号的存在意义在于：它不会随补丁版本（patch）更新而失效，便于用户引用「某个大版本系列」的最新构建。

2.2 为什么 Chrome 106 走的是「legacy」驱动源

Chrome 106 是一个值得注意的版本分界：Chrome 115 之前的版本先于 Chrome for Testing（CfT）体系存在。在 NodeChrome/install-chromedriver.sh 中（L44-L47）可以看到明确的兼容分支：

if [ "${ARCH}" = "amd64" ] && [ -n "${CHROME_MAJOR_VERSION}" ] && [ "${CHROME_MAJOR_VERSION}" -lt 115 ]; then DRIVER_SOURCE="legacy" DRIVER_ARCH="linux64" ...

即 Chrome 主版本号小于 115 时，ChromeDriver 不会走 CfT 下载路径，而是使用已冻结的chromedriver.storage.googleapis.com旧版 API（脚本 L62-L66），通过LATEST_RELEASE_106这类端点解析对应主版本的驱动并下载chromedriver_linux64.zip。这正是 Chrome 106 这类「老版本浏览器」仍能在 4.48.0 新 Grid 中正常工作的底层保证之一；同时说明该路径仅有 linux64 架构产物，属脚本注释中明确指出的历史遗留事实。

三、12 个标签的语义：命名规范全解析

脚本在chrome)分支中构建CHROME_TAGS数组（L75-L99），随后对node-chrome与standalone-chrome两种镜像各打一遍标签（L101-L104）。日志中的 12 行Tagged ...因此拆分为两个 6 元组。

以node-chrome为例，完整标签如下（standalone-chrome同理）：

这套标签体系与 docs/docker-hub/node-chrome.md 中记载的 Tagging Convention 完全一致——该文档给出了通用形式：

selenium/node-chrome-<Major>.<Minor>.<Patch>-<YYYYMMDD> selenium/node-chrome-<browserVersion>-<browserDriver>-<browserDriverVersion>-<Major>.<Minor>.<Patch>-<YYYYMMDD>

并注明「plus all the permutations from the above one」，即上述所有组合的排列变体。也就是说，标签从「最精确（钉死一切版本）」到「最宽松（仅钉浏览器大版本 + 构建日期）」都有覆盖，用户可以按自己的可重复性需求挑选。

3.1 关键细节：为什么这里没有「浮动标签」

细心的读者会发现：日志中并没有出现selenium/node-chrome:106.0这类不带构建日期的短标签。原因在于脚本第 6 个参数RELEASE_OLD_VERSION=true。

对照 tag_and_push_browser_images.sh 的 L88-L99：

if [ "${RELEASE_OLD_VERSION}" = "false" ]; then CHROME_TAGS+=( ${CHROME_VERSION}-chromedriver-${CHROMEDRIVER_VERSION} ${CHROME_VERSION} ${CHROME_SHORT_VERSION}-chromedriver-${CHROMEDRIVER_SHORT_VERSION} ${CHROME_SHORT_VERSION} ) fi

只有当RELEASE_OLD_VERSION=false（即发布的是当前最新浏览器版本）时，才会额外追加106.0、106.0.5249.119等「浮动标签」——这类标签不带构建日期，会随同系列后续构建被不断覆写，语义上指向该系列的最新构建。而本次记录的对象是 4.48.0 时代已经「过时」的 Chrome 106，因此脚本以RELEASE_OLD_VERSION=true运行，只为旧版本生成带构建日期的不可变标签，避免无意中把「最新 106」的浮动指针移动到旧构建上。这正是本次输出恰好 12 个标签（而非 20 个）的原因。

3.2 打标签但不推送：PUSH_IMAGE=false 的行为

日志中每条都是Tagged ...，没有任何docker push输出。对照retag()函数（L31-L51）：当PUSH_IMAGE=true时，每个docker tag之后会跟随docker push；而false时只执行本地docker tag。同时注释（L18-L30）还说明了另一种发布模式：当PROMOTE_TAGS=true（由 deploy.yml 在发布时设置），脚本改用docker buildx imagetools create在 registry 之间直接创建多架构 manifest 别名，而不是重新构建——这是 CI 发布链路的优化路径，日常在本地复现标签流程时并不涉及。

四、实战：拉取并运行 Chrome 106 镜像

4.1 直接拉取固定版本

# 信息最全的标签（推荐用于可复现测试） docker pull selenium/node-chrome:106.0.5249.119-chromedriver-106.0.5249.61-grid-4.48.0-20260909 # 或更简短：短版 Chrome + 构建日期 docker pull selenium/node-chrome:106.0-20260909

注意：若使用不带grid-段落的标签（如106.0-20260909），镜像内实际打包的 Grid 版本需结合 generate_release_notes.sh 生成的版本矩阵（见 CHANGELOG/README.md）交叉确认；要绝对钉死「Grid 4.48.0 + Chrome 106」，首选包含grid-4.48.0-20260909的完整标签。

4.2 以 Node 模式接入 Selenium Grid

参考 docs/docker-hub/node-chrome.md 的标准接入流程：先建网络、再起 Hub、最后起 Node。将文档中的latest替换为本次的固定标签：

# 1. 创建网络 docker network create grid # 2. 启动 Hub docker run -d -p 4442-4444:4442-4444 --net grid --name selenium-hub selenium/hub:latest # 3. 启动固定版本的 Chrome Node docker run -d --net grid \ -e SE_EVENT_BUS_HOST=selenium-hub \ --shm-size="2g" \ selenium/node-chrome:106.0-chromedriver-106.0-grid-4.48.0-20260909

随后将 WebDriver 测试指向http://localhost:4444即可；如需观察容器内浏览器运行情况，可访问http://localhost:7900/?autoconnect=1&resize=scale&password=secret。

务必注意：对含浏览器的镜像运行docker run时，官方建议使用--shm-size=2g以使用宿主机共享内存，避免 Chrome 因/dev/shm过小崩溃。测试完毕后可执行docker network rm grid清理。

4.3 以 Standalone 模式单机运行

若不需要 Hub-Node 架构，可直接使用standalone-chrome镜像，一个容器内同时包含 Grid 服务器与 Chrome 浏览器：

docker run -d -p 4444:4444 --shm-size="2g" \ selenium/standalone-chrome:106.0-chromedriver-106.0-grid-4.48.0-20260909

Standalone 与 Node 的区别在于：Node 需要自行注册到 Hub/EventBus，而 Standalone 自带完整的 Grid 组件，开箱即用。

五、如何自助验证与复现

• 核对版本号：仓库提供了 generate_release_notes.sh，发布时同样通过docker run探测各镜像中的 Chrome、ChromeDriver、Grid 版本并生成「Released versions」表格——它与 CHANGELOG/README.md 的矩阵相互印证，可用来核对本文记录中的版本三元组。
• 复现打标签流程：若本地已有selenium/node-chrome:4.48.0-20260909镜像，可直接执行本文开头那条命令（把selenium替换为你的命名空间），观察与日志逐行一致的输出。
• 驱动解析逻辑的单测：tests/node_chrome/test_resolve_chromedriver_source.py对 ChromeDriver 来源解析（legacy/CfT/Chromium 包三路）有自动化断言，是理解「Chrome 106 走 legacy 路径」行为的最佳测试佐证。
• 自定义构建版本：如需构建含特定 Chrome 版本的镜像，可参考 NodeChrome/Dockerfile 中的CHROME_VERSION（默认google-chrome-stable，可传google-chrome-beta/unstable或google-chrome-stable=106.0.5249.119-1这类 apt 精确版本）与CHROME_DRIVER_VERSION参数，构建逻辑分别由 NodeChrome/install-chrome.sh 与 NodeChrome/install-chromedriver.sh 实现。

六、标签选择建议

结合 docs/docker-hub/node-chrome.md 的 Tagging Convention 与本次 Chrome 106 记录，给出选择策略：

1. 追求最强可复现性（CI 流水线、回归基线）：使用完整五段标签，如106.0.5249.119-chromedriver-106.0.5249.61-grid-4.48.0-20260909，浏览器、驱动、Grid、构建日期全部钉死。
2. 需要「某大版本系列最新」：对旧版浏览器使用106.0-20260909（带构建日期）最稳妥；对当前最新浏览器，106.0浮动标签会指向同系列最新构建，但注意它会被后续构建覆写。
3. 只想固定浏览器、跟随 Grid 更新：优先选node-chrome:106.0-chromedriver-106.0-grid-<新版本>-<新日期>形式的标签，前提是该组合存在于对应 Grid 版本的矩阵中（在 CHANGELOG/README.md 中可查）。

从源码结构看，这套「完整版 + 短版 × 是否含 Grid 版本 × 是否含构建日期」的标签生成逻辑在chrome / chromium / edge / firefox / chrome-for-testing五个分支中完全对称（见 tag_and_push_browser_images.sh 的 L61-L281），因此本文对 Chrome 106 的解读方式可直接迁移到矩阵中的任何浏览器与版本组合。

• 测试
• 后端
• 云原生
• 容器编排
• 可观测性