简介：基于Selenium自动注册Apple ID的Python脚本以zip封装，面向需要批量创建账号、研究浏览器自动化或搭建注册流程验证的开发者与测试人员。脚本已实现浏览器模拟提交、表单信息自动输入、Apple邮箱验证码读取与回填、注册提交等核心流程；图片验证码环节采用保存截图并在控制台手动输入的方式，同时预留了第三方打码平台接入接口，便于后续升级为全自动方案。压缩包共45个文件，以Python源码、验证码截图、Chrome/Firefox驱动及说明文档为主，并适配macOS与Linux常见环境，整体约20MB。目录内包含README说明、启动脚本和示例驱动配置，可帮助快速理解运行逻辑并进行二次开发。当前已有267人学习下载，适合具备基础Python/Selenium知识、希望获得可直接运行参考实现的用户。
1. 自动注册 Apple ID 的 selenium 脚本，真正的难点在注册页状态机
一个新入坑的同事拿到“基于 selenium 自动注册 apple id 的 python 脚本（下载即用）.zip”，第一反应通常是装好 Python，把 main.py 一跑，然后盯着浏览器看它表演。真实情况远不是这样：Apple 注册页不是一张静态表单，而是“资料填写、身份创建、验证码、安全设置”几个页面状态连续切换的单页应用，任何一个状态没等到位，下一步按钮就是灰的，或者点击之后页面无响应。selenium 本身只是把浏览器操作翻译成协议的引擎，真正决定自动化能否跑通的是你对页面状态机的理解，以及对等待、重试、失败现场的工程处理。下面按“流程拆解 → 工程化 → 运行排错 → 合法自用”这条链路，把这类脚本里最值得留住的细节讲清楚。
2. 拆解 Apple ID 注册页状态，搭出 selenium 的最小自动化骨架
2.1 注册流程被 UI 包装后的五个状态
Apple 的网页注册入口在 account.apple.com 里点“创建你的 Apple 账户”，整体流程可以拆成五个状态：初始向导、资料表单、创建身份、验证码校验、完成跳转。前两个状态在一个带遮罩的弹层里完成，中间第三个会切换到全屏页面，验证码状态又可能被短信或邮箱两种通道拆分。这不只是页面变化，而是每个状态背后都有一组异步请求，请求返回之前，界面上的按钮即使渲染出来了也是 disabled 状态。
这也是 selenium 自动注册 apple id 脚本里最容易翻车的地方。页面结构对自动化并不友好，原生 HTML 的 name 属性并不完整，不少输入框要等焦点事件之后才会把值写进前端状态库。也就是说，你即便用element.clear()和send_keys()把文字填进去了，React 表单仍然认为这个字段是空的。这种情况用“等待元素出现”解决不了，必须对输入框做事件触发处理。
判断当前处于哪个状态，有一个非常实用的方法：不要靠time.sleep()猜，而是看“下一步”按钮的可点击状态。每个状态页的 CTA 按钮都有自己独立的文案和属性，用element_to_be_clickable等它变可点，再点击，然后等下一个 CTA 出现。把流程做成这种状态链，要比一次性从头填到尾可靠得多，这也是“下载即用”脚本里最值得保留的代码结构。
2.2 最小可运行骨架：显式等待加事件触发
我一般会把自动化注册拆成一个fill_input()函数和一个状态推进函数，下面这段是一个可以独立运行的最小骨架，选择器需要根据你访问时页面实际 DOM 调整：
from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def create_driver() -> webdriver.Chrome: """创建浏览器实例，注册场景不建议直接开 headless""" opts = webdriver.ChromeOptions() opts.add_argument("--start-maximized") # 保证页面弹层可见 return webdriver.Chrome(options=opts) def fill_input(driver, wait, css_selector, text): """带事件触发的可控输入，适配前端框架受控组件""" element = wait.until(EC.element_to_be_clickable((By.CSS_SELECTOR, css_selector))) driver.execute_script("arguments[0].focus();", element) element.clear() element.send_keys(text) driver.execute_script( "arguments[0].dispatchEvent(new Event('input', {bubbles: true}));", element ) def create_account(driver, cfg: dict) -> None: wait = WebDriverWait(driver, 20, poll_frequency=0.5) driver.get(cfg["start_url"]) # 状态一：入口按钮 entry = wait.until( EC.element_to_be_clickable((By.CSS_SELECTOR, cfg["entry_selector"])) ) entry.click() # 状态二：资料页 fill_input(driver, wait, 'input[name="firstName"]', cfg["first_name"]) fill_input(driver, wait, 'input[name="lastName"]', cfg["last_name"]) select_region = wait.until( EC.element_to_be_clickable((By.CSS_SELECTOR, cfg["region_toggle"])) ) select_region.click() continue_btn = wait.until( EC.element_to_be_clickable((By.CSS_SELECTOR, cfg["continue_selector"])) ) continue_btn.click() # 状态三：创建 Apple ID 身份信息 fill_input(driver, wait, 'input[name="username"]', cfg["email_prefix"]) fill_input(driver, wait, 'input[name="password"]', cfg["password"]) submit = wait.until( EC.element_to_be_clickable((By.CSS_SELECTOR, cfg["submit_selector"])) ) submit.click()这段代码里有两个细节值得注意。第一，WebDriverWait的poll_frequency我设成了 0.5 秒，默认 0.5 就是 0.5，这里其实不用改，但如果你网络波动大，可以把超时时间调大到 30 秒，轮询频率不要动，太频繁反而会干扰页面自身的请求。第二，dispatchEvent(new Event('input', {bubbles: true}))是给 React 等现代框架看的，单纯send_keys之后，框架内部状态没更新，点击下一步还是会提示“请填写必填项”。
2.3 等待策略和元素定位的参数取舍
selenium 脚本里最被滥用的是time.sleep()，注册这种流程，网络抖动 2 到 10 秒都可能，sleep 短了白等，长了拖沓。真正该用的是显式等待，注册脚本里元素有几种不同状态，对应的等待方式不一样，我把常用组合整理成一张表：
| 页面元素的用途 | 推荐等待方式 | 参数建议 |
|---|---|---|
| 等待按钮可点 | element_to_be_clickable | 超时 20 秒，忽略ElementClickInterceptedException |
| 等待弹层渲染 | visibility_of_element_located | 超时 10 秒，轮询 0.5 秒 |
| 等待提交后的跳转 | url_contains | 超时 30 秒，配合当前页 URL 判断 |
| 等待字段值写入 | text_to_be_present_in_element_value | 超时 5 秒，校验事件触发 |
定位方式上，Apple 页面不像老式网站那样给每个表单元素稳定 id，所以优先用CSS_SELECTOR配合input[name=...]。这类选择器在前后端分离项目里通常稳定。真要复用某个脚本，第一件事就是把写死的 id 换成 name 或>apple_id_autoreg/ ├─ main.py # 入口脚本 ├─ config.ini # 账户与运行参数 ├─ requirements.txt # 依赖清单 └─ webdriver/ # 或 chrome driver 的存放目录
先看requirements.txt，如果里面是selenium>=4.0这种宽泛写法，说明依赖没锁版本。正确的做法是锁到小版本。你本机 Chrome 版本和打包者不一致的话，旧驱动根本启动不了。
配置文件建议长这样，用configparser读取，个人信息和运行参数分离：
[account] first_name = Zhang last_name = San email_prefix = test_user_20240501 password = YourPassword123 [run] start_url = https://account.apple.com/ entry_selector = a[data-analytics*="create"] continue_selector = button[type="submit"] region_toggle = #countrySelector region_value = CHN headless = false timeout = 20参数说明：region_value是下单品牌区号，比如 CHN 代表中国区，写成 ISO 代码而不是中文名字，是为了避免页面上校验“国家或地区”字段时出现歧义；headless建议在调试阶段保持 false，等注册流程稳定后再考虑是否打开；timeout是全局等待上限，单位秒，配置外置之后，调试时临时调大就不要再改代码。
3.2 不要用 time.sleep 代替显式等待
工程化脚本里最不该出现的函数是time.sleep，尤其是在注册这种多状态页面里。睡 3 秒，慢网络下页面还没加载完，下一行点击就报错；睡 8 秒，快网络下又白白浪费整个执行时长。
正确的替换方案是把每个操作设计成幂等推进。比如“如果当前在资料页，点下一步；如果没有，就说明已经过了这一步”，这就是状态机思想。落到 selenium 注册脚本上，我会把显式等待封装成一个带重试的函数：
def click_state_button(wait, selector, fallback_selector=None): try: wait.until(EC.element_to_be_clickable((By.CSS_SELECTOR, selector))).click() except TimeoutException: if fallback_selector: fallback = wait.until( EC.element_to_be_clickable((By.CSS_SELECTOR, fallback_selector)) ) fallback.click() else: raise这里面的逻辑是：主选择器没出现时，不要立刻判定失败，先看备用选择器是否对应另一个状态。Apple 经常根据地区或本地化文案切换按钮，选择器一变整个流程就断，这个 fallback 机制可以让脚本在页面小幅调整时继续跑。
3.3 失败重试必须有日志和页面快照
注册流程一旦失败，直接重跑往往没用，因为服务端可能已经记住了这个浏览器环境，或者短信验证码已经消耗。所以真正的重试策略不是“脚本内部死循环”，而是记录现场、保存快照，人工判断后再续跑。
推荐的日志结构是每次运行建立一个独立目录：
logs/ └─ 20240812_103005/ ├─ runtime.log # 步骤级日志 └─ failure.html # 失败时页面的 DOM 快照Python 里用 logging 模块写运行日志，失败时把driver.page_source写入 failure.html。下次启动脚本时读取上次快照，先分析卡在哪个状态，再决定是从头开始还是跳到对应状态。很多“下载即用”脚本的失败重试就是整个函数递归调用，这个做法在注册场景里效率很低，因为验证码和输入框的状态已经被消耗过一轮了。
4. 跑通 selenium 注册脚本的四个排查点：驱动、验证码、焦点与脏数据
4.1 驱动与浏览器版本错位的 WebDriverException
运行脚本最先撞见的异常基本是WebDriverException: session not created，十有八九是 chromedriver 和 Chrome 大版本对不上。Apple 这类页面测试时浏览器会自动更新，几天不关注，驱动就不认了。你不需要每次手工下载，常见做法是用 webdriver-manager 自动匹配：
from selenium.webdriver.chrome.service import Service from webdriver_manager.chrome import ChromeDriverManager service = Service(ChromeDriverManager().install()) driver = webdriver.Chrome(service=service)ChromeDriverManager().install()逻辑是，读取本机 Chrome 的主版本号，从缓存里找对应驱动，找不到再去下载。这个方案对在线开发环境很省心。拿到别人压缩包时，把里面固定的 chromedriver 删掉，用这段代码替换，能少踩一半坑。
4.2 卡在验证码与人工复核环节时的处置策略
注册 Apple 账户到“身份创建”那一步之后，页面大概率会要求验证码，可能是邮箱也可能是手机短信。这类验证码脚本是收不到的，所以“下载即用”脚本不可能在这里完全全自动。我看过不少脚本是绕过验证码，直接 sleep 长等待，但服务端早就在这个环节做了行为校验，等待时间越长越像机器。
合理的做法是给脚本留一个“人工接管点”。具体实现是：自动填完前面所有表单，到验证码输入框时停下来，用控制台提示用户手动输入，脚本用显式等待等验证码通过后页面跳转。这种半自动半人工的模式，才是这类注册脚本在工程上真正可落地的形态。
captcha_input = wait.until( EC.presence_of_element_located((By.CSS_SELECTOR, 'input[autocomplete="one-time-code"]')) ) print("请手动输入验证码，脚本将等待验证结果...") wait.until(EC.url_changes(driver.current_url))url_changes在这里是验证码是否通过的直接信号。一直等，直到 URL 变化说明验证成功并进入下一状态，比固定 sleep 20 秒精准得多。这个模式的代价是中间有一个人工等待时间，但换来的是成功率，对注册这类风控敏感业务来说，成功率远比速度重要。
4.3 headless 模式下焦点和弹层的问题
很多人拿到脚本为了跑得快，直接给 ChromeOptions 加上--headless，结果发现到了“国家或地区”下拉框就点不动。原因是 Apple 注册页用了大量焦点事件，弹层打开后要计算元素坐标，无头浏览器没有实际视口，坐标偏移会导致点击落到别处。
我一般会把这个参数做成配置项，默认开图形界面，只有做连通性冒烟测试时才切 headless。而且即便是冒烟测试，也要额外做两步处理：固定窗口尺寸，以及把浏览器 UserAgent 保持默认。注册这种页面，没必要去伪造特定 UA，反而容易触发风控层的标记。
4.4 清理上一次运行的脏数据
注册脚本跑一次失败后，浏览器 profile 里可能残留了上一次的 Cookie 和 LocalStorage。Apple 页面会记住上次填写到一半的邮箱或手机号，新的一轮自动化就会闪回数据，导致名称对不上、验证码发到旧号码上。
解决方法是每次启动时新建临时 profile 目录：
from tempfile import mkdtemp opts = webdriver.ChromeOptions() opts.add_argument(f"--user-data-dir={mkdtemp(prefix='apple_reg_')}")每次mkdtemp生成新目录，用完整个目录删掉，就相当于一个干净的全新浏览器环境。这个手法对于反复调试注册流程非常有用，可以避免大量由残留状态引起的假性失败。要注意，--user-data-dir路径不能放在项目目录里，否则日志里会混入无关临时文件，而且也不方便后续清理。
5. 把 selenium 注册脚本改造成合法的账号自测工具
5.1 验证注册成功与否的三个证据
脚本跑到最后，页面 URL 跳回 account.apple.com 首页，只凭这一点不能算成功。更可靠的验证方式有三个：第一，浏览器出现“验证已通过，账户创建成功”的提示块；第二，填写的邮箱在几分钟内收到 Apple 发送的验证邮件；第三，用刚才填写的邮箱密码重新登录一次。最后这个最直接，也是把注册脚本顺手扩展成登录脚本的契机。
验证逻辑可以写成一个独立的验证函数，不在注册流程内联判断，而是注册完成后单独调用登录接口去确认。好处是注册脚本和登录脚本各自独立，以后改注册流程不会污染登录验证逻辑。
5.2 把方向切到自己的业务：用 Selenium 自测 Apple 登录集成
这个 zip 脚本拿来跑 Apple 官方注册存在合规风险，Apple 的账户使用条款本质上是要求真实用户注册的，脚本批量注册会破坏平台规则，也很可能被封禁。但同样一套 selenium 技术，完全可以合法地用到自己产品里。最常见场景是：你的 App 集成了 Apple 登录，你需要自动化回归“登录按钮是否正常跳转、回调是否携带用户信息、异常取消是否处理”。你可以造一个测试专用账号，脚本负责登录，然后用它验证自己业务方的 token 校验链路。
def test_apple_signin_flow(): driver.get("https://your-app.example.com/login") apple_btn = wait.until( EC.element_to_be_clickable((By.CSS_SELECTOR, 'button[data-provider="apple"]')) ) apple_btn.click() # 切换到 Apple 认证跳出的新窗口 wait.until(EC.number_of_windows_to_be(2)) driver.switch_to.window(driver.window_handles[-1]) fill_input(driver, wait, 'input[name="username"]', "test_account") fill_input(driver, wait, 'input[name="password"]", "test_password") wait.until(EC.url_contains("your-app.example.com/callback"))这段代码的价值在于端到端验证的是两边页面交互，单元测试和接口测试都覆盖不到。这时的 selenium 不再是“注册机器”，而是你业务质量的守护者，既规避了违反平台规则的问题，又保住了整套自动化技术栈。
5.3 存档验证码现场，沉淀成错误码表
最后留一个工程习惯：脚本里所有异常分支都记录一个短错误码，比如E_CAPTCHA_TIMEOUT、E_DRIVER_VERSION、E_STATE_CHANGE，对应到日志文件里统一格式。等脚本跑过几轮后，翻看错误码分布，就能知道瓶颈到底在等待策略、选择器失效还是验证码环节。这套方法不限于 Apple ID 注册，任何 selenium 驱动的网页自动化都可以照搬。记录、分类、重放，比在浏览器前盯着每一个弹窗要有效得多。
本文还有配套的精品资源，点击获取
