Gmail API 分页与同步详解

Gmail API 的 nextPageToken 和 maxResults 如何工作？

Gmail API 的 maxResults 参数控制 users.messages.list 单页返回多少条邮件 ID，上限为 500。当还有更多匹配邮件时，响应会包含 nextPageToken。把该令牌作为 pageToken 传回下一次请求，直到响应不再包含新的令牌为止。

对于常见的搜索查询 gmail api nextPageToken maxResults，关键规则是：maxResults 只是页大小，不是结果总数上限。一个有 10,000 封匹配邮件的邮箱仍然需要重复请求、令牌持久化、重试处理，以及对每封邮件再调用一次 messages.get 来获取正文。

Gmail API 分页如何工作

Gmail API 分页把大结果集拆分到多个 HTTP 响应中，每个响应包含一个 nextPageToken，调用方必须把它传回去才能获取下一批。messages.list 端点每次请求最多返回 500 条结果，所以一个有 10,000 封邮件的收件箱至少需要 20 次串行 API 调用才能翻完。

根据 Gmail API messages.list 文档，每次调用消耗 5 个配额单位，默认页大小为 100（可通过 maxResults 配置到最高 500）。每个请求都需要有效的 OAuth2 访问令牌。下面的循环用 Python 演示了这一模式——它反复调用 messages.list、收集邮件 ID，并在 nextPageToken 不存在时退出：

from googleapiclient.discovery import build

service = build("gmail", "v1", credentials=creds)

all_messages = []
page_token = None

while True:
    response = service.users().messages().list(
        userId="me",
        maxResults=500,
        pageToken=page_token,
    ).execute()

    all_messages.extend(response.get("messages", []))
    page_token = response.get("nextPageToken")

    if not page_token:
        break

print(f"Fetched {len(all_messages)} message IDs")

仅仅收集邮件 ID 就要 18 行代码。你还需要对每个 ID 调用 messages.get 来获取主题、发件人和正文——按当前 Gmail 配额表，每次调用又要消耗 20 个配额单位。

Gmail 增量同步如何工作

Gmail 增量同步通过一个单调递增的 historyId 跟踪邮箱变更，这样你只需获取自上次同步以来发生变化的内容。对一个 10,000 封邮件的收件箱做完整重新分页，仅 messages.list 调用就至少消耗 100 个配额单位，history.list 端点的存在就是为了避免这种开销——它只返回新增、删除或标签变更的邮件。

你保存上次同步得到的 historyId。下次运行时，调用 history.list 并传入 startHistoryId，只获取此后的变更。Gmail 同步指南推荐把它作为保持本地副本同步的主要方式。historyTypes 参数可以按变更类型过滤：messageAdded、messageDeleted、labelAdded 和 labelRemoved。每次 history.list 调用消耗 2 个配额单位——比消耗 5 个单位的 messages.list 便宜 60%。下面的 Python 函数循环遍历分页的历史记录，收集变更并返回最新的 historyId 供下次同步使用：

def get_changes_since(service, start_history_id):
    """Fetch all mailbox changes since the given historyId."""
    changes = []
    page_token = None

    while True:
        response = service.users().history().list(
            userId="me",
            startHistoryId=start_history_id,
            historyTypes=["messageAdded", "messageDeleted"],
            pageToken=page_token,
        ).execute()

        changes.extend(response.get("history", []))
        page_token = response.get("nextPageToken")

        if not page_token:
            break

    new_history_id = response.get("historyId")
    return changes, new_history_id

这里有个坑：history ID 大约 30 天后过期。如果你保存的 historyId 太旧，history.list 会返回 404 Not Found（有时是 410 Gone），你需要回退到完整同步。你的代码必须同时处理这两条路径。

自己实现会遇到的问题

构建生产级的 Gmail 同步客户端意味着要处理 OAuth2 令牌生命周期、过期 history 回退、限流和部分失败——所有这些都在你自己维护的代码里。一开始 20 行的分页循环，加上令牌刷新回调、针对 429 响应的指数退避，以及增量同步与完整同步的双代码路径之后，会膨胀到 80-120 行。边界情况不断累积：

• OAuth2 令牌管理 — Gmail 访问令牌每 3,600 秒过期一次。你的同步循环需要检测过期令牌、用刷新令牌进行刷新，并重试失败的请求。这意味着令牌刷新回调、错误处理和重试逻辑。
• 过期 historyId 回退 — 当 history.list 返回 404 时，你需要放弃增量同步，改为运行一次完整分页同步。两条代码路径，都必须正确工作。
• 限流 — 新的 Gmail API 项目每用户每项目每分钟有 6,000 个配额单位。一次 messages.list 调用消耗 5 个单位，messages.get 消耗 20 个单位，history.list 消耗 2 个单位。如果要同步大邮箱，你需要客户端节流，并对 429 Too Many Requests 做指数退避。
• 页中途失败 — 分页中途出现网络错误意味着你只拿到一半结果。是从头重试，还是从最后一个页令牌重试？你需要跟踪状态。
• Gmail API 设置开销 — 在写任何调用 Gmail API 的代码之前，你需要一个 Google Cloud 项目、一个 OAuth 同意屏幕、一对客户端 ID 和密钥，以及在 console.cloud.google.com 中配置好的重定向 URI。这意味着 15-20 分钟的网页表单点击。

覆盖上述全部 5 个问题的可靠同步循环要写 80-120 行 Python——这还没算日志、持久化或多账户支持。

相关 API 分页与邮件工作流指南

Gmail 分页通常和相邻的集成工作摆在一起：日历事件同步、与提供商无关的收件箱列表、webhook 投递、API 配额规划，以及面向代理的安全邮件访问。需要更具体的实现路径时，请参考下表。

一条命令列出 Gmail 邮件

Nylas CLI 用一条终端命令取代整套分页加同步的技术栈，在内部处理 OAuth2 令牌刷新、限流和多页抓取。Gmail API 方案需要 80-120 行 Python 和 15-20 分钟的 Google Cloud 配置，而 CLI 把它压缩成一行命令和 2 分钟的安装。

下面三条命令展示常见模式：列出最近邮件、按主题过滤、按发件人过滤。每条命令底层只发起一次 API 调用，CLI 负责管理跨提供商响应的分页：

# List the 50 most recent emails
nylas email list --limit 50 --json

# Filter by subject
nylas email search "invoice" --json

# Filter by sender
nylas email list --from "boss@company.com" --json

CLI 在幕后对 Gmail API 进行分页，自动刷新过期的 OAuth2 令牌，并以 JSON 返回结果。不用注册 Gmail API 项目，不用配置同意屏幕，也不用设置重定向 URI。初次使用 CLI？入门指南涵盖安装与首次认证。

搜索与过滤

Nylas CLI 支持全文搜索和字段级过滤，它们映射到 messages.list 使用的同一个 Gmail q 参数，但不需要分页循环或 OAuth2 管线。Gmail 的 API 至少需要 3 次串行 API 调用才能完成搜索、分页和获取邮件正文——CLI 把这些折叠成一条命令。

下面三个示例覆盖最常见的搜索模式：关键词搜索、未读过滤和日期范围过滤。日期过滤位于 nylas email search 的 --after 和 --before 标志上，接受 YYYY-MM-DD 格式的日期，并接受 "*" 作为匹配所有内容的查询。每个示例都返回包含主题、发件人和正文的完整邮件 JSON：

# Full-text search
nylas email search "quarterly report" --json

# Unread emails only
nylas email list --unread --json

# Emails received in the last 7 days
nylas email search "*" --after 2026-06-02 --json

Gmail API 的等价做法是：构造查询字符串、传给 messages.list、用 nextPageToken 翻页，再对返回的每个邮件 ID 调用 messages.get 获取主题和正文。这是 4 个步骤，每页至少 10 个配额单位。

读取邮件内容，而不只是 ID

Gmail API 的 messages.list 端点只返回邮件 ID——从不包含主题、发件人或正文。要读取实际内容，你得对收集到的每个 ID 调用 messages.get，每次调用又要消耗 20 个配额单位。翻完 10,000 封邮件后，你还要再发 10,000 次 API 调用，总计 200,000 个配额单位——按 2026 年每用户项目限额计算，要消耗超过 33 个用户分钟的配额。

CLI 把这两步折叠成一条命令。nylas email read <id> 一次调用即可获取包含完整正文的单封邮件。nylas email search 执行服务端查询，并在同一响应中返回匹配邮件及其内容。两者都通过全局 --format 标志支持三种输出模式——table、json 和 yaml——其中 --json 是 JSON 模式的简写。要获取 messages.get 配合 format=raw 返回的原始 RFC822 源文，可向 nylas email read 传 --mime。JSON 输出可以干净地通过管道传给 jq 做后续 shell 处理。

# Read a single message
nylas email read 18b9a3f2cd47e102 --json

# Search and return full bodies in one round-trip
nylas email search "urgent" --from boss@example.com --json

按会话线程而非邮件分页

Gmail 把邮件组织成会话线程，threads.list 端点是独立于 messages.list 的分页资源。一个 10,000 封邮件的收件箱通常对应 2,000-4,000 个线程（取决于会话密度），所以按线程列出可以把总页数减少 60-80%。每个线程响应遵循与 messages.list 相同的 nextPageToken 约定，外加一个包含会话中所有邮件的 threads[].messages[] 数组。

CLI 中的线程操作面通过 5 条命令与邮件操作面一一对应。nylas email threads list 按线程分页。nylas email threads show 按 ID 获取单个线程。nylas email threads search 接受 Gmail 风格的查询字符串。nylas email threads mark 一次性更改线程中所有邮件的已读状态。nylas email threads delete 删除整个会话。

# Paginate threads in pages of 50
nylas email threads list --limit 50 --json

# Mark a whole conversation as read in one command
nylas email threads mark <thread-id> --read

在特定标签或文件夹内分页

Gmail 按标签组织邮件——系统标签如 INBOX、SENT、STARRED、UNREAD、SPAM 和 TRASH，外加用户自建标签。Microsoft Graph 和 IMAP 提供商则使用文件夹。Gmail 的 messages.list 端点对系统标签接受 labelIds 数组，对自定义标签则通过 q 参数使用 label:Receipts 这样的搜索语法。分页令牌携带过滤范围，所以一个限定到单个标签的 50,000 封邮件归档会按比例返回更少的页数。

nylas email search 接受 --in 把查询限定到一个标签或文件夹——传 "*" 作为查询即可匹配其中的所有邮件。nylas email folders list 返回已连接账户上的所有标签或文件夹，因此同一个标志无需改语法即可跨 Gmail 标签、Outlook 文件夹和 IMAP 文件夹名工作。搜索命令的标志面还包括 --unread、--starred 和 --has-attachment。

# List every label or folder on the connected account
nylas email folders list --json

# Paginate only inside the Receipts label
nylas email search "*" --in Receipts --limit 100 --json

# Combine label scope with a query
nylas email search "stripe" --in Receipts --json

跨多个账户分页

生产环境的同步客户端往往要处理多个已连接邮箱——销售运营团队聚合 4 个共享收件箱、AI 代理操作 5 个用户账户、CRM 从工作区的每个账户拉取邮件信号。Gmail API 按 OAuth 授权（grant）分配配额，所以并行同步 10 个账户不会产生跨账户限流，但应用代码必须管理 10 个独立的刷新令牌、10 个令牌过期计时器和 10 个 historyId 检查点。

授权在 CLI 中是一等公民。nylas auth list 显示所有已连接账户。nylas auth whoami 打印下一条命令将使用哪个授权。nylas auth switch 切换活动授权。邮件和日历命令还接受授权 ID 作为可选的位置参数，因此一个 shell 脚本无需切换活动状态即可遍历所有授权。

# Show every connected grant as JSON
nylas auth list --json

# Run the same sync across every Google grant
for grant in $(nylas auth list --json | jq -r '.[] | select(.provider == "google") | .id'); do
  nylas email search "*" "$grant" --after 2026-05-01 --json
done

在 CI、cron 任务和无头环境中同步

Gmail API 的 OAuth2 浏览器弹窗在 CI、Docker 容器、AI 代理沙箱以及任何无人值守环境中都是硬性障碍。Google 的离线访问流程要求应用在一次性交互式设置中捕获刷新令牌，然后把它存入密钥管理器并以编程方式刷新。官方推荐的替代方案（带域级委托的服务账号）仅限 Google Workspace 管理员使用，且需要工作区级别的配置变更。

Nylas CLI 用 API 密钥认证完全绕开浏览器。nylas auth config --api-key 在本地存储密钥，全程不碰浏览器。nylas auth token 生成限定范围的 bearer 令牌供下游 API 调用使用。nylas auth status 报告当前认证状态——对容器化部署中的健康检查很有用。

# In a GitHub Action or cron job — no browser needed
export NYLAS_API_KEY="nyk_..."
nylas auth config --api-key "$NYLAS_API_KEY"
nylas email search "*" --after $(date -u -v-1d +%Y-%m-%d) --json > /var/log/digest.json

在 Manus、Replit 以及类似的没有浏览器的 AI 代理沙箱中，同样的流程也适用——代理只需配置一次密钥并持久化到自己的环境中，后续的每条命令都无需交互步骤即可运行。

用 webhook 取代轮询

每 5 分钟轮询一次 Gmail 收件箱，每个收件箱每天会产生 288 次 API 调用。在 1,000 个已连接用户的规模下就是每天 288,000 次调用，而且大多数调用返回的都是零封新邮件。Gmail 通过 Cloud Pub/Sub 提供推送通知替代方案：你要创建一个 Pub/Sub 主题，给 gmail-api-push@system.gserviceaccount.com 授予 pubsub.publisher 角色，对每个邮箱调用 users.watch，并每 7 天续订一次 watch（因为 Google 会让它过期）。搭建成本很高，而且一次漏掉的续订会让同步悄无声息地中断。

CLI 中的 webhook 无需 Pub/Sub 主题即可工作。nylas webhook create 注册一个 HTTPS 端点和一组触发器。nylas webhook list 显示已注册的内容。nylas webhook triggers 打印所有支持的事件类型（message.created、message.updated、thread.replied，以及日历和联系人事件）。nylas webhook test send 向你的端点发送一个示例载荷，让你在上线前验证接收器。nylas webhook verify 校验传入载荷上的 HMAC 签名。

# Register a webhook for new message events
nylas webhook create \
  --url https://example.com/hooks/nylas \
  --triggers message.created \
  --json

# Verify a payload from your receiver
nylas webhook verify \
  --payload-file ./incoming.json \
  --signature "$X_NYLAS_SIGNATURE" \
  --secret "$WEBHOOK_SECRET"

webhook 只在实际事件发生时触发，对普通用户来说每个收件箱每天通常少于 100 次。同样这 1,000 个收件箱，每天 288,000 次调用的轮询负载缩减到大约 100,000 个事件，而新邮件到达与应用感知到它之间的延迟从最长 5 分钟降到大约 1 秒。

其他邮件提供商如何处理分页

Gmail 不是唯一一个分页约定值得了解的提供商。Microsoft Graph（Outlook 和 Exchange Online）使用 @odata.nextLink——一个客户端原样跟随的完整 URL。IMAP（Yahoo Mail、iCloud Mail、托管 IMAP）没有传统意义上的分页：UID SEARCH 在一个响应中返回所有匹配的 UID，在大邮箱上可能较慢，但省去了客户端游标逻辑。Exchange Web Services（EWS，旧版 Exchange 部署使用）通过 IndexedPageItemView 和 BasePoint 偏移量做索引分页。

各提供商指南在各自的约定下讲解同一个分页问题：从命令行列出 Outlook 邮件、列出 Exchange 邮件、列出 Yahoo 邮件、列出 iCloud 邮件，以及列出 IMAP 邮件。文档中说明同一条 nylas email list 命令能以完全相同的标志在每个提供商上运行。

上文描述的 Outlook、Exchange、Yahoo、iCloud 和 IMAP 提供商侧行为来自各提供商的公开文档，并非在每个后端上端到端验证过的结果。部署提供商特定的工作流之前，请先在本地测试。

同步一个 Gmail 收件箱需要多久？

在家用宽带连接（到 Google 服务器约 150 ms 中位延迟）上对测试邮箱进行的合成基准测试，展示了手动分页与一条 CLI 命令之间的成本差异。Python 循环一列包含 messages.list + messages.get 调用以及对 429 响应的指数退避。CLI 的数字包含同样的内部调用，但做了批处理和并行化。

配额成本由 Gmail 的按调用计价决定，与客户端无关。CLI 没法让一次 messages.list 调用变得更便宜，但它能把分页和重试行为挡在你的应用代码之外。一个朴素的 Python 循环抓取 10,000 封完整正文，仅 messages.get 调用就要花掉约 200,000 个配额单位。在规划一次全新的完整同步时，这些数字很重要；控制批处理和并发的标志见 nylas email list。

常用配方

下面是 4 个把邮件分页和标准 UNIX 工具结合起来的 shell 模式。每个模式都用 jq 解析 JSON 输出，并用 --json 获得机器可读格式。

统计所有未读邮件

把 nylas email list --unread --json 通过管道传给 jq 'length' 得到一个数字。适合脚本化仪表盘或值班告警。配合 watch -n 60 可以得到每分钟刷新一次的实时计数器。JSON 输出会自动分页——你不需要在封装脚本里处理 nextPageToken。

nylas email list --unread --json | jq 'length'

每日摘要 cron 任务

一个在 cron 下每天运行一次的摘要脚本：用 nylas email search 配合绑定到昨天日期的 --after，把 JSON 写入临时文件，再把每封邮件一行的摘要通过管道传给 mail。在运行 cron 的机器上用 nylas auth config --api-key 替换 nylas auth login，这样就不需要浏览器。

# /etc/cron.daily/email-digest.sh
yesterday=$(date -u -v-1d +%Y-%m-%d)
nylas email search "*" --after "$yesterday" --json > /tmp/digest.json
jq -r '.[] | "\(.from) - \(.subject)"' /tmp/digest.json \
  | mail -s "Daily digest" you@example.com

查找特定发件人的所有带附件邮件

把 nylas email search 与 nylas email attachments list 串联起来，在一条管道里找到某个发件人的所有附件。email search 在服务端应用 --from 和 --has-attachment 过滤器，然后 attachments list 枚举每个匹配项。想把文件保存到磁盘时，再通过管道传给 nylas email attachments download。

nylas email search "*" --from billing@stripe.com --has-attachment --json \
  | jq -r '.[].id' \
  | xargs -I{} nylas email attachments list {} --json

自动从最近的登录邮件中提取 OTP 验证码

拉取昨天以来收到的所有登录相关邮件，从正文中提取 6 位数字并打印第一个匹配项。关键词查询 verification 能覆盖最常见的事务性邮件主题；换成 OTP 或 code 重新运行可以覆盖其他发件人。单独来看，这就是专门的 OTP 提取指南的基础。需要超出简单计数的收件箱分析时，见 nylas email ai analyze。PowerShell 用户可以在 PowerShell 邮件报表中改写这些模式。

nylas email search "verification" \
  --after "$(date -u -v-1d +%Y-%m-%d)" \
  --json \
  | jq -r '.[].body' \
  | grep -oE '[0-9]{6}' \
  | head -1

并排对比

下表在生产环境中重要的 9 项能力上对比 Gmail API Python 方案与 Nylas CLI。最大的差异是搭建时间：Gmail API 路径需要 15-20 分钟的控制台配置外加 80-120 行代码，而 CLI 安装加认证只要大约 2 分钟。

常见问题

Gmail API 中的 nextPageToken 是什么？

调用 messages.list 时，Gmail API 每页最多返回 500 条结果。如果还有更多邮件，响应会包含一个 nextPageToken 字符串。你把该令牌作为 pageToken 参数传入下一次请求来获取下一页。一直循环到响应不再包含 nextPageToken，就说明已经到底了。

Gmail 增量同步如何配合 historyId 工作？

Gmail 邮箱中的每次变更（新邮件、删除、标签更改）都会获得一个单调递增的 historyId。你保存上次同步的 historyId，然后调用 history.list 并传入 startHistoryId，只获取此后的变更。history ID 大约 30 天后过期。如果保存的 ID 太旧，API 会返回 404，你需要回退到完整同步。

可以不设置 Gmail API 就列出 Gmail 邮件吗？

可以。Nylas CLI 在内部处理 OAuth2 和提供商认证。运行 nylas email list --limit 50 --json 即可列出 Gmail 收件箱，无需在 Google Cloud 注册 Gmail API 客户端、配置 OAuth 同意屏幕或管理访问令牌。CLI 在 6 个提供商上的用法完全相同。

CLI 能处理 Gmail API 限流吗？

能。Gmail API 给新项目每用户每项目每分钟 6,000 个配额单位，一次 messages.list 调用消耗 5 个单位。CLI 在内部管理限流、分页、令牌刷新和重试逻辑。你直接拿到结果，无需编写任何配额跟踪或退避代码。

可以按线程而不是按邮件对 Gmail 分页吗？

可以。nylas email threads list 对 threads.list 端点而不是 messages.list 进行分页。典型邮箱大约每 3-4 封邮件对应 1 个线程，所以页数低 60-80%。配合 nylas email threads mark，一条命令即可把会话中的所有邮件标记为已读。

如何只列出某个 Gmail 标签下的邮件？

把标签名传给 nylas email search 的 --in。命令 nylas email search "*" --in Receipts --json 只返回带 Receipts 标签的邮件。用 nylas email folders list 查看账户上的所有标签或文件夹。同一个标志对 Outlook 文件夹、Yahoo IMAP 文件夹和 iCloud 文件夹同样适用，语法不变。

可以在 cron 任务中同步 Gmail 而不弹出 OAuth 窗口吗？

可以。用 nylas auth config --api-key 代替 nylas auth login。API 密钥流程不会打开浏览器，因此可以在无头机器、Docker 容器、CI 流水线以及 Manus 这类 AI 代理沙箱中运行。把密钥作为机密存储在运行 cron 任务的环境中即可。

如何只同步最近 24 小时的邮件？

给 nylas email search 传 --after。最近 24 小时：nylas email search "*" --after $(date -u -v-1d +%Y-%m-%d) --json。该标志接受 YYYY-MM-DD 格式的日期，CLI 会把它翻译成底层提供商使用的过滤语法——对 Gmail 来说就是对 API 发起 q=after: 查询。

CLI 在 Outlook、Yahoo 和 iCloud 上的用法一样吗？

一样。同样的 nylas email list、nylas email search 和 nylas email read 命令在 Gmail、Outlook、Exchange、Yahoo、iCloud 和 IMAP 上都能用。该工具把每条命令翻译成提供商特定的 API 调用：Gmail 的 REST API、Microsoft Graph、IMAP UID SEARCH 或 EWS。各提供商的详细步骤见列出 Outlook 邮件、列出 IMAP 邮件和列出 Exchange 邮件。

如果我的 historyId 超过 30 天会怎样？

Gmail 会从 history.list 返回 404，你必须回退到完整分页同步。CLI 会自动处理这一回退——你看不到 404，也不用写两条代码路径。基于 ETag 的并发控制和 If-Match 处理见 Gmail API If-Match 与 ETag 处理。

可以用推送通知代替轮询吗？

可以。nylas webhook create 为 message.created、thread.replied 等事件注册一个 HTTPS 端点，无需 Cloud Pub/Sub 主题，也不需要 Google Workspace 管理员。运行 nylas webhook triggers 查看所有支持的事件类型。

后续步骤

Gmail 分页和增量同步是最常见的两类 API 集成难题，但并非仅有的两类。下面这些相关指南覆盖相邻的工作流，包括邮件发送、基于 ETag 的并发控制，以及完整的 CLI 命令面。

• 从命令行列出 Gmail 邮件 — 按发件人、主题、日期和已读状态过滤
• 从命令行发送 Gmail — 无需 Gmail API 客户端代码或 SMTP 配置的 Gmail 专属发送
• Gmail API 搜索查询示例 — q、标签、分类、附件与 CLI 等价用法
• 用 historyId 和 ETag 做 Gmail API 增量同步 — 深入讲解 ETag、If-Match 与 412 处理
• 2026 年 Gmail API 配额 — 当前配额单位、各方法成本、计费门槛与适合代理的模式
• Gmail API 为什么会让 AI 代理出问题 — OAuth 弹窗、分页状态、MIME 解析与配额压力
• 面向 AI 代理的邮件 API 对比 — Gmail、Microsoft Graph、IMAP 与提供商中立 API 的权衡
• Google Calendar API 分页与同步 — 同样的模式应用到 events.list 和 syncToken
• 在本地测试邮件 webhook — 在替换轮询循环之前验证事件驱动同步
• 从命令行列出 Outlook 邮件 — 使用 @odata.nextLink 的 Microsoft Graph 分页
• 从命令行列出 IMAP 邮件 — 通过 UID SEARCH 访问 Yahoo、iCloud 和托管 IMAP
• 从终端发送邮件 — bash、zsh 与跨平台发送工作流
• 从邮件中提取 OTP 验证码 — 在脚本中自动获取验证码
• PowerShell 邮件报表 — 同样的分页模式适配到 Windows shell
• 快速上手 — 安装方式（Homebrew、shell 脚本、PowerShell、Go）与首次认证
• 完整命令参考 — 每个标志和子命令的文档