M1 Mac上Selenium自动化测试：ARM64 Chromedriver配置与优化指南

1. 项目概述：为什么M1 Mac上的Selenium需要“特供”Chromedriver？

如果你是一名在M1/M2/M3芯片的Mac上进行Web自动化测试的开发者，大概率踩过这个坑：兴致勃勃地写好了Selenium脚本，一运行却弹出一个“无法打开‘chromedriver’，因为无法验证开发者”的提示，或者直接报错“zsh: killed”。这背后，正是我们今天要聊的核心——为M1优化的Chromedriver。这不仅仅是一个简单的驱动文件替换，而是从指令集架构到系统安全策略的一次完整适配。对于从Intel Mac迁移过来的开发者，或者新入手苹果芯片Mac的测试工程师来说，理解这其中的差异，是搭建稳定、高效自动化测试环境的第一步。

简单来说，Chromedriver是Selenium控制Chrome浏览器的“桥梁”或“遥控器”。传统的Chromedriver是为x86_64架构编译的，而苹果的M系列芯片采用的是ARM64架构。虽然MacOS内置的Rosetta 2转译层能让大部分Intel应用“无感”运行，但对于Chromedriver这种需要与底层系统、浏览器进程深度交互的二进制工具，转译运行常常会引入不稳定因素，比如内存访问异常、性能损耗，甚至直接被系统的安全机制（如Gatekeeper）终止。因此，一个原生为ARM64架构编译的Chromedriver，是确保Selenium在M1 Mac上流畅、可靠运行的基石。本文将带你彻底搞清如何为你的M1 Mac获取、配置并优化这个关键组件，避开所有常见的“坑”。

2. 核心需求解析：M1架构带来的挑战与机遇

2.1 架构差异：从x86到ARM的本质变化

Intel处理器使用的x86_64（或amd64）指令集，与苹果自研M系列芯片使用的ARM64指令集，是两种完全不同的计算语言。Rosetta 2作为翻译官，虽然强大，但并非万能。它在运行时动态将x86指令翻译成ARM指令，这个过程会带来两个直接影响：一是性能开销，对于计算密集或频繁进行系统调用的程序，性能损失可能超过20%；二是兼容性风险，某些涉及特定CPU特性或低级系统调用的操作，在转译时可能行为异常。Chromedriver需要与Chrome浏览器通过DevTools Protocol进行高速、精确的进程间通信（IPC），任何微小的延迟或不稳定都可能导致元素定位超时、脚本执行失败。因此，原生ARM64版本的Chromedriver，能彻底消除转译层带来的不确定性，实现与系统及浏览器的“原生对话”。

2.2 系统安全策略：Gatekeeper与公证（Notarization）

自macOS Catalina起，苹果强化了Gatekeeper安全机制。对于从未知开发者（即未经过苹果公证）下载的应用，系统会默认阻止其运行。从官网下载的通用版Chromedriver，通常未经过苹果的公证流程。当你在M1 Mac上首次运行它时，系统会弹出警告，甚至直接拒绝。你需要手动在“系统设置”->“隐私与安全性”中点击“仍要打开”，这显然不适合自动化流程。而为M1优化的版本，或通过Homebrew等受信任渠道安装的版本，往往已经处理了公证问题，或者提供了绕过此限制的更优方案。理解这一点，能帮你避免脚本在CI/CD流水线或定时任务中因权限问题而意外中断。

2.3 性能与稳定性诉求

自动化测试，尤其是UI层级的测试，对稳定性要求极高。一个不稳定的驱动会导致测试用例时好时坏（Flaky Tests），极大地损害测试套件的可信度。原生ARM64 Chromedriver带来的最直接好处，就是稳定性的显著提升。它减少了因架构转译导致的内存错误和进程崩溃几率。同时，由于直接使用ARM指令集，在执行一些密集型操作，如处理大量DOM元素、执行复杂JavaScript或进行截图对比时，也能获得更好的性能表现，从而缩短测试执行时间。

3. 环境准备与工具选型

3.1 确认你的Mac芯片类型

这是所有操作的起点。打开“关于本机”（屏幕左上角苹果菜单 -> 关于本机），查看“芯片”一项。如果显示“Apple M1”、“Apple M2”等，那么你就需要ARM64版本的Chromedriver。也可以打开终端（Terminal），输入以下命令：

uname -m

如果输出是arm64，那么你的系统是运行在Apple Silicon原生模式下的。如果输出是x86_64，则可能是你通过Rosetta 2打开的终端，此时可以打开终端，在“简介”中确认“使用Rosetta打开”是否被勾选。

3.2 浏览器与驱动的版本对齐原则

这是Selenium工作的黄金法则：Chromedriver的主版本号必须与已安装的Chrome浏览器的主版本号完全一致。例如，你安装了Chrome 124，那么就必须使用Chromedriver 124.x.x.x。版本不匹配是绝大多数“无法启动浏览器”或“连接失败”错误的根源。

• 查看Chrome版本：打开Chrome，在地址栏输入chrome://version/，第一行“Google Chrome”后面就是完整版本号，记下主版本号（如124）。
• 驱动命名：从官网下载时，文件名通常包含版本号和平台信息，如chromedriver-mac-arm64.zip就是ARM64版本。

3.3 包管理工具推荐：Homebrew vs 手动管理

对于Mac用户，管理Chromedriver主要有两种方式：

1. Homebrew（推荐）：这是最优雅、最省心的方式。Homebrew Cask可以直接安装匹配当前Chrome版本的Chromedriver，并自动处理路径和更新。

   # 安装Homebrew（如果尚未安装） /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" # 使用Homebrew安装Chromedriver brew install --cask chromedriver

   安装后，Homebrew会提示你进行一些安全设置（例如将chromedriver从隔离区移出），并告诉你驱动被安装到了哪个路径（通常是/usr/local/bin/chromedriver或/opt/homebrew/bin/chromedriver），这个路径通常已在系统的PATH环境变量中。
2. 手动下载与管理：这种方式更灵活，适合需要固定特定版本或进行多版本并存的场景。你需要前往 Chromedriver官方下载站 或 Chrome for Testing 页面，找到对应版本和平台（mac-arm64）的zip包，下载后解压，并将可执行文件放置到系统路径下。

注意：从官网直接下载的chromedriver，在首次运行时大概率会遇到“无法打开，因为无法验证开发者”的提示。除了在系统设置中手动允许外，更一劳永逸的命令行解决方法是（在解压出chromedriver文件后，于其所在目录执行）：

xattr -c chromedriver

这个命令会移除其上的“扩展属性”（quarantine属性），Gatekeeper便不会再拦截。但请注意，这略微降低了安全门槛，请确保你从官方渠道下载文件。

4. 详细配置与集成步骤

4.1 使用Homebrew安装并配置

假设你选择Homebrew方式，安装完成后，还需要进行验证和可能的路径配置。

1. 验证安装：在终端输入chromedriver --version。如果正确输出版本信息，且与你的Chrome主版本号一致，说明安装成功。
2. 处理公证警告（如果出现）：首次运行chromedriver命令时，可能仍会弹出安全警告。按照提示进入“系统设置”->“隐私与安全性”，点击“仍要允许”即可。之后便不会再出现。
3. 在Selenium代码中指定路径（通常不需要）：如果Homebrew安装后，直接在终端输入which chromedriver能找到路径，那么在Python的Selenium代码中，通常不需要显式指定驱动路径，WebDriver会自动在PATH中查找。但为了绝对可靠，你可以显式指定：

   from selenium import webdriver from selenium.webdriver.chrome.service import Service # 指定chromedriver的绝对路径 service = Service('/opt/homebrew/bin/chromedriver') # 根据你的实际路径调整 driver = webdriver.Chrome(service=service)

4.2 手动下载与配置流程

如果你需要手动管理特定版本，请遵循以下步骤：

1. 确定Chrome版本：如前所述，访问chrome://version/记录主版本号（例如124）。
2. 下载对应驱动：访问 Chrome for Testing 页面。这是一个更现代的、专门为测试提供的渠道。找到“Stable”频道下对应版本（如124.0.6367.91），下载chromedriver-mac-arm64.zip。
3. 解压与放置：

   # 解压下载的zip文件 unzip ~/Downloads/chromedriver-mac-arm64.zip -d ~/Downloads/ # 将解压出的二进制文件移动到系统可执行路径，并赋予执行权限 sudo mv ~/Downloads/chromedriver-mac-arm64/chromedriver /usr/local/bin/ sudo chmod +x /usr/local/bin/chromedriver

   • /usr/local/bin是一个常见的用户级可执行文件存放路径。你也可以选择~/bin（需要确保该目录在PATH中）。
4. 移除隔离属性：

   sudo xattr -c /usr/local/bin/chromedriver

5. 验证：打开新终端，执行chromedriver --version，确认版本输出正确。

4.3 在Python项目中集成（以pytest为例）

一个良好的测试项目结构有助于管理驱动。假设你的项目结构如下：

my_automation_project/ ├── drivers/ │ └── chromedriver (你的ARM64版本驱动放在这里) ├── tests/ │ ├── conftest.py │ └── test_example.py └── requirements.txt

你可以在conftest.py中配置一个pytest fixture来管理浏览器的生命周期，并指定驱动路径：

# conftest.py import pytest from selenium import webdriver from selenium.webdriver.chrome.service import Service from pathlib import Path def pytest_addoption(parser): parser.addoption("--headless", action="store_true", default=False, help="Run tests in headless mode") @pytest.fixture(scope="session") def driver(request): """提供WebDriver实例的Fixture""" chrome_options = webdriver.ChromeOptions() # 根据命令行参数决定是否无头运行 if request.config.getoption("--headless"): chrome_options.add_argument("--headless=new") # 推荐使用new headless模式 # 其他常用选项 chrome_options.add_argument("--no-sandbox") # 在CI环境或某些配置下可能需要 chrome_options.add_argument("--disable-dev-shm-usage") # 解决共享内存问题 chrome_options.add_argument("--window-size=1920,1080") # 关键：指定ARM64 chromedriver的路径 driver_path = Path(__file__).parent.parent / "drivers" / "chromedriver" service = Service(executable_path=str(driver_path)) driver_instance = webdriver.Chrome(service=service, options=chrome_options) driver_instance.implicitly_wait(10) # 设置隐式等待 yield driver_instance # 测试结束后退出浏览器 driver_instance.quit() # test_example.py def test_visit_homepage(driver): """使用fixture提供的driver进行测试""" driver.get("https://www.example.com") assert "Example" in driver.title

这样，你只需将对应版本的ARM64 chromedriver放入drivers/目录，所有测试用例都能通过driverfixture使用它。

5. 高级配置与性能优化

5.1 ChromeOptions的针对性配置

针对M1 Mac和自动化测试场景，一些ChromeOptions的设置能极大提升体验：

chrome_options = webdriver.ChromeOptions() # 1. 使用新的Headless模式（性能更好，更接近真实浏览器） chrome_options.add_argument("--headless=new") # 2. 禁用GPU加速（在无头模式下有时可避免问题） chrome_options.add_argument("--disable-gpu") # 3. 禁用沙盒（仅在受信任的测试环境或容器中使用，有安全风险） # chrome_options.add_argument("--no-sandbox") # 4. 避免使用/dev/shm，使用/tmp替代（防止内存不足） chrome_options.add_argument("--disable-dev-shm-usage") # 5. 设置默认下载目录（避免弹窗） prefs = {"download.default_directory": "/path/to/downloads"} chrome_options.add_experimental_option("prefs", prefs) # 6. 忽略证书错误（用于测试环境） chrome_options.add_argument('--ignore-certificate-errors')

5.2 使用Driver Manager简化版本管理

手动管理驱动版本很繁琐。社区库webdriver-manager可以自动下载、缓存并匹配正确版本的驱动。虽然它主要面向x86，但通过一些配置也能支持ARM64。

from selenium import webdriver from selenium.webdriver.chrome.service import Service from webdriver_manager.chrome import ChromeDriverManager from webdriver_manager.core.os_manager import ChromeType service = Service(ChromeDriverManager(chrome_type=ChromeType.CHROMIUM).install()) driver = webdriver.Chrome(service=service)

注意：webdriver-manager需要正确识别系统架构。在M1 Mac上，确保你运行在原生ARM终端下，它应该能自动下载mac_arm64版本。但有时可能需要指定版本，建议先手动确认其下载的驱动是否为ARM64格式。

5.3 容器化方案：Docker for Mac (Apple Silicon)

对于追求环境一致性的团队，使用Docker是终极方案。你需要寻找或构建包含ARM64架构Chrome和Chromedriver的Docker镜像。

1. 确保你的Docker Desktop已更新到支持Apple Silicon的版本。
2. 使用官方的selenium/standalone-chrome镜像，并确认其有ARM64标签的版本。
3. 编写Dockerfile或使用docker-compose，将你的测试代码挂载到容器中运行。

# docker-compose.yml 示例 version: '3.8' services: selenium: image: seleniarm/standalone-chromium:latest # 注意是seleniarm，这是ARM64版本的Selenium镜像 shm_size: 2gb ports: - "4444:4444" - "7900:7900" tests: build: . depends_on: - selenium environment: - SELENIUM_REMOTE_URL=http://selenium:4444/wd/hub volumes: - ./tests:/tests

这种方式完全隔离了宿主机环境，无论在Intel Mac、M1 Mac还是Linux服务器上，测试运行环境都完全一致。

6. 实战问题排查与调试技巧

6.1 常见错误与解决方案

以下是在M1 Mac上使用Selenium和Chromedriver时，我遇到并总结的典型问题：

6.2 诊断与日志收集

当遇到复杂问题时，启用详细日志能帮你快速定位。

• 启用Chromedriver日志：在Service对象中指定日志输出。

  service = Service(executable_path='/path/to/chromedriver', service_args=['--verbose', '--log-path=chromedriver.log'])

• 启用Chrome浏览器日志：

  chrome_options.add_argument('--enable-logging') chrome_options.add_argument('--v=1') # 日志详细级别

• 使用浏览器开发者工具：对于非无头模式，你可以直接按F12打开开发者工具，在Console和Network面板查看错误和请求，这对于调试页面交互问题至关重要。

6.3 稳定性增强实践

1. 显式等待优于隐式等待：隐式等待（implicitly_wait）是全局设置，不够灵活。推荐使用WebDriverWait配合expected_conditions进行显式等待，针对特定条件轮询。

   from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC element = WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.ID, "myDynamicElement")) )

2. 页面加载策略：设置page_load_strategy为none或eager可以避免在加载缓慢的页面上长时间阻塞，但需要配合良好的等待策略。

   chrome_options.page_load_strategy = 'eager' # 等待DOMContentLoaded，不等待图片等资源

3. 进程清理：确保测试结束后正确调用driver.quit()，而不是driver.close()。quit()会关闭所有窗口并终止WebDriver进程，释放资源。在fixture或teardown方法中实现。

7. 持续集成（CI）环境下的考量

在CI流水线（如GitHub Actions, GitLab CI, Jenkins）中运行Selenium测试，环境是全新的，配置必须自动化且可靠。

1. GitHub Actions (macos-latest runner)：GitHub提供的Mac运行器已经是Apple Silicon芯片。你的工作流步骤需要包括：

   jobs: test: runs-on: macos-latest steps: - uses: actions/checkout@v4 - name: Set up Python uses: actions/setup-python@v5 with: { python-version: '3.11' } - name: Install Chrome run: | brew install --cask google-chrome - name: Install Chromedriver run: | brew install --cask chromedriver - name: Install dependencies run: pip install -r requirements.txt - name: Run tests run: pytest --headless

   注意，CI环境中通常需要以无头模式 (--headless) 运行。

2. 使用官方Docker镜像：如前所述，使用seleniarm/standalone-chromium等ARM64 Docker镜像是最佳实践，它能保证环境绝对一致。在CI中，你可以启动一个Selenium服务容器，然后让你的测试运行器容器与之通信。

3. 驱动缓存：为了加速CI构建，可以将下载的Chromedriver缓存起来。在GitHub Actions中可以使用actions/cache动作，缓存Homebrew的安装目录或手动下载的驱动路径。

踩过几次坑之后，我的体会是，在M1 Mac上玩转Selenium，第一步也是最关键的一步，就是搞定那个“对”的Chromedriver。它就像一把精准的钥匙，架构对得上（ARM64），版本对得上（与Chrome一致），系统才认（公证或属性处理）。一旦这个基础打牢了，剩下的写脚本、搞框架、上CI，都是水到渠成的事。别再让版本不匹配或架构错误这种低级问题浪费你的时间了，从源头把它配置好，你的自动化测试之路就成功了一大半。