企业官网建设流程全解析

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

本指南以仓库 CHANGELOG/4.48.0/chrome_110.md 为骨架，完整解读这份 changelog 背后的一整套浏览器镜像标签生成机制。你将掌握 docker-selenium 镜像标签的命名规范与含义、Chrome 110 / ChromeDriver 110 与 Grid 4.48.0 的配套关系，以及如何拉取、运行和编排这些固定版本镜像，用于跨浏览器测试或版本锁定场景。

这份 changelog 记录了什么

CHANGELOG/4.48.0/chrome_110.md是 docker-selenium 发布流程中由 tag_and_push_browser_images.sh 自动生成的输出日志，完整记录了一次针对 Chrome 110 的镜像打标签操作。原始内容如下：

./tag_and_push_browser_images.sh 4.48.0 20260909 selenium false chrome true Tagging images for browser chrome, version 4.48.0, build date 20260909, namespace selenium Selenium Grid version -> 4.48.0-20260909 Chrome version -> 110.0.5481.177 Short Chrome version -> 110.0 ChromeDriver version -> 110.0.5481.77 Short ChromeDriver version -> 110.0

从这段输出可以提取出本次发布的核心版本事实：

随后脚本为node-chrome与standalone-chrome两组镜像各生成了 10 个标签，合计 20 个镜像标签，全部面向selenium命名空间（Docker Hub 的selenium/node-chrome、selenium/standalone-chrome系列）。这些标签正是本次 changelog 的"正文"，将在下一节逐一解析。

标签命名规范深度解析

对照 tag_and_push_browser_images.sh 的源码，可以精确还原每个标签的构造逻辑。脚本以VERSION、BUILD_DATE、NAMESPACE、PUSH_IMAGE、BROWSER、RELEASE_OLD_VERSION为参数，本次调用的完整语义为：

./tag_and_push_browser_images.sh 4.48.0 20260909 selenium false chrome true # 参数1 VERSION = 4.48.0 Selenium Grid 版本 # 参数2 BUILD_DATE = 20260909 构建日期 # 参数3 NAMESPACE = selenium 镜像命名空间 # 参数4 PUSH_IMAGE = false 只打标签，不推送（false） # 参数5 BROWSER = chrome 浏览器类型 # 参数6 RELEASE_OLD_VERSION = true 保留旧版本发布时间线标签

脚本首先通过docker run进入已构建的selenium/node-chrome:4.48.0-20260909镜像，分别执行google-chrome --version与chromedriver --version，再用short_version()函数（按.分割取前两段）得到短版本号。随后按CHROME_TAGS数组顺序生成三组不同粒度的标签：

第一组：完整版本号 + 构建日期（6 个）

110.0.5481.177-chromedriver-110.0.5481.77-grid-4.48.0-20260909 110.0.5481.177-chromedriver-110.0.5481.77-20260909 110.0.5481.177-20260909 110.0-chromedriver-110.0-grid-4.48.0-20260909 110.0-chromedriver-110.0-20260909 110.0-20260909

第二组：纯版本号（4 个，仅在 RELEASE_OLD_VERSION=false 时追加）

110.0.5481.177-chromedriver-110.0.5481.77 110.0.5481.177 110.0-chromedriver-110.0 110.0

从源码可以看出几个关键点：

• 标签信息递进：同一镜像被赋予从"浏览器+驱动+Grid+日期"到仅"浏览器短版本号"的多重标签，精度逐级降低，用户可按需选择锁定粒度。
• RELEASE_OLD_VERSION的作用：为true时只保留带构建日期的标签，避免覆盖历史版本时间线上的标签（Makefile 中对应RELEASE_OLD_VERSION变量，用于旧版本发布，防止破坏已存在的时间点标签）；为false时追加不带日期的纯版本标签，供常规使用。
• retag()的两种路径：常规路径执行docker tag+ 可选docker push（本 changelog 中PUSH_IMAGE=false，因此只打标签不推送）；当PROMOTE_TAGS=true时改用docker buildx imagetools create在 registry 之间直接创建 manifest 索引标签，以保留多架构镜像（详见 tag_and_push_browser_images.sh 头部注释）。
• 镜像名与浏览器参数的对应：chrome分支固定对node-chrome与standalone-chrome两个镜像名循环打标签（tag_and_push_browser_images.sh）；同理，chromium、edge、firefox、chrome-for-testing分支分别对应各自的 node/standalone 镜像。

最终，selenium/node-chrome与selenium/standalone-chrome各获得 10 个标签，其中带grid-4.48.0-20260909的标签明确表达了"浏览器 110 配套 Grid 4.48.0"的完整组合信息。

为什么需要固定浏览器版本

CHANGELOG/README.md 开篇解释了这套矩阵与标签体系的动机：项目希望持续供应最新的 Selenium Grid 核心版本及其新功能，同时让用户仍能用于跨浏览器测试，或因为特定浏览器版本存在兼容性问题、支持范围限制而固定（pin）某个浏览器版本。因此仓库同时交付 Node 与 Standalone 两种镜像形态，并各自打包特定 Grid 与驱动/浏览器版本组合——用户只需在矩阵中找到镜像标签、拉取所需镜像即可开始测试。

对于 Chrome 110 这类较老版本而言，其价值正在于"可复现"：当新版本 Chrome 行为变更导致回归、或被测系统只兼容旧浏览器时，selenium/standalone-chrome:110.0.5481.177-20260909这样的标签就是一个确定性的、可反复拉取的测试环境。README 也明确提示：项目并未对每一种 Grid×浏览器组合做完整全量测试，用户应根据自身测试需求评估后自行决策（CHANGELOG/README.md）。

Chrome 110 与 ChromeDriver 110 的配套逻辑

Chrome 110 是一个特殊的版本分水岭。查看 NodeChrome/install-chromedriver.sh 源码可以发现，脚本对115 之前的 Chrome 版本走了一条独立的"legacy"路径（install-chromedriver.sh）：

# Chrome versions before 115 predate Chrome for Testing and are served by the frozen # chromedriver.storage.googleapis.com API, which only ever had linux64. if [ "${ARCH}" = "amd64" ] && [ -n "${CHROME_MAJOR_VERSION}" ] && [ "${CHROME_MAJOR_VERSION}" -lt 115 ]; then DRIVER_SOURCE="legacy" DRIVER_ARCH="linux64"

即：Chrome 110 先于 Chrome for Testing（CfT）体系，其 ChromeDriver 必须从冻结的chromedriver.storage.googleapis.com/LATEST_RELEASE_110旧接口解析，且只提供linux64架构。这解释了本 changelog 中 ChromeDriver 版本 110.0.5481.77 与 Chrome 版本 110.0.5481.177 的配套来源——两者同属 110.x 系列，由旧版 LATEST_RELEASE 接口按大版本号自动匹配。

此外，NodeChrome/Dockerfile 还展示了镜像构建时的版本可配置性：

• ARG CHROME_VERSION="google-chrome-stable"：可通过google-chrome-stable=<版本>、google-chrome-beta、google-chrome-unstable指定 Chrome 的渠道或精确版本（对应 install-chrome.sh 中的 apt 精确安装分支）；
• ARG CHROME_DRIVER_VERSION：不传则自动按已安装 Chrome 的主版本号解析驱动（install-chromedriver.sh 通过google-chrome --version提取 major 版本）；
• 镜像构建时还会把 Chrome 版本写入/opt/selenium/browsers/chrome/version，供 Grid 的浏览器能力匹配使用（NodeChrome/Dockerfile）。

如何在实战中使用这些镜像标签

拿到 changelog 中的标签后，可直接用于三种典型场景。

场景一：直接拉取并验证版本组合

docker pull selenium/standalone-chrome:110.0.5481.177-chromedriver-110.0.5481.77-grid-4.48.0-20260909 docker run --rm selenium/standalone-chrome:110.0.5481.177-chromedriver-110.0.5481.77-grid-4.48.0-20260909 \ google-chrome --version docker run --rm selenium/standalone-chrome:110.0.5481.177-chromedriver-110.0.5481.77-grid-4.48.0-20260909 \ chromedriver --version

场景二：docker-compose 编排固定版本 Grid

以 Node + Standalone 形态启动 Chrome 110 节点（可与仓库 docker-compose-v3.yml 的结构类比）：

services: chrome-110: image: selenium/node-chrome:110.0.5481.177-chromedriver-110.0.5481.77-grid-4.48.0-20260909 shm_size: 2gb depends_on: - selenium-hub environment: - SE_EVENT_BUS_PUBLISH_PORT=4442 - SE_EVENT_BUS_SUBSCRIBE_PORT=4443

场景三：在测试脚本中固定浏览器能力

Selenium 客户端只需指向 Grid/Hub 地址并请求对应浏览器能力即可，由服务端根据浏览器版本文件自动匹配节点，例如：

ChromeOptions options = new ChromeOptions(); options.setBrowserVersion("110.0"); WebDriver driver = new RemoteWebDriver(new URL("http://localhost:4444"), options);

注意：Chrome 110 对应的镜像标签仅代表"已打包的确定性组合"，实际运行效果仍受宿主机平台（amd64）与 Docker 资源（共享内存、CPU、内存）影响，建议在正式使用前先做一次版本探测与冒烟验证。

从版本矩阵定位镜像与 Changelog

CHANGELOG/README.md 是一张完整的"Selenium Grid × 浏览器版本矩阵"，每一格 ✓ 都链接到对应 Grid 版本目录下的详细 changelog（如本文件4.48.0/chrome_110.md）。矩阵按浏览器（Chrome、Chrome For Testing、Edge、Firefox）分别建表，最新版本在前、降序排列；历史版本则被归档到archived/目录下（如archived/4.47.0/chrome_110.md等），供追溯旧组合使用。

这套矩阵的生成与维护由 CHANGELOG/generate-matrix-readme.py 完成，其工作分三步：

1. 归档旧版本：把当前目录下除最新版以外的 Grid 版本目录整体移入archived/；
2. 扫描 changelog：用正则([\w-]+)_(\d+)\.md解析每个版本目录下的文件，提取"浏览器 + 版本号"，构建matrix[grid_version][browser]集合；
3. 生成 README：按浏览器与 Grid 版本双向排序渲染矩阵表格，并在每格写入指向 changelog 的相对链接。

在仓库 Makefile 中，该脚本被update_browser_versions_matrix目标调用（Makefile），与fetch_version.py等版本抓取脚本串联，构成"抓版本 → 生成 changelog → 更新矩阵"的自动化发布流水线。因此，chrome_110.md这类文件不仅是版本记录，也是矩阵索引与 CI 发布状态的证据链。

使用限制与注意事项

结合源码与文档，使用这些固定版本标签时需注意以下几点：

• 覆盖范围声明：README 明确表示没有对所有 Grid×浏览器组合做完整测试，是否采用取决于用户的测试需求（CHANGELOG/README.md）；
• 架构限制：Chrome 110 时代的 ChromeDriver 仅提供linux64，legacy路径只在 amd64 下生效；arm64 下 115 之前版本需要回退到 Debianchromium-driver包（install-chromedriver.sh），这也是 Chrome 110 组合仅适合 amd64 测试场景的原因；
• 标签精度差异：110.0短版本标签会随该系列后续镜像构建被移动指向新镜像，若需严格复现应优先使用带构建日期或完整版本号的标签；
• 运行环境：上述命令与配置以当前仓库发布内容为准，使用前请以 tag_and_push_browser_images.sh 与 NodeChrome/Dockerfile 中的实际参数为准进行核对。

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