一、二维码深度原理
二维码的本质是字符串的图像化编码，通过黑白格子的矩阵来存储信息，再通过图像处理技术还原。它承担的是“数据搬运工”的角色，而非“仓库”。
1. 编码本质：字符串 ↔ 二进制 ↔ 黑白格子
完整转换链路如下：
原始字符串 → 二进制数据（0101序列）→ 添加纠错码 → 掩膜处理 → 按标准画成黑白格子矩阵
几个关键步骤：
- 字符串转二进制：不同字符类型有不同编码模式。纯数字、字母数字、二进制、汉字各有专门模式以最大化节省空间。例如纯数字模式下一个二维码最多能存 7,089 个字符，而汉字模式下最多约 1,817 个。
- 纠错码（里德-所罗门码）：在原始数据后追加冗余信息。这是二维码即使被遮挡、污损达 30%（H 级容错），仍能完整读取的核心原因。容错等级越高，留给实际数据的空间就越少。
- 掩膜：为避免原始数据产生大面积空白或黑块（影响扫描识别），用特定算法将 0 和 1 均匀打散。解码时用同样的掩膜算法复原即可。
- 绘制：最终按版本规格，从右下角以特定曲折路径依次绘制每个小格。黑色表示 1，白色表示 0，加上三个角的“回”字形定位图案和辅助对齐图案，形成完整的二维码。
2. 容量上限：标准与物理的双重天花板
二维码不是可以无限装载数据的。它的容量被两个层面的天花板严格锁死。
第一层：标准限制——版本（格子数量有上限）
国际标准 ISO/IEC 18004 规定了 40 个版本：
| 版本 | 模块数 | 最大二进制容量 |
|---|---|---|
| 版本 1 | 21×21 | 约 20 字节 |
| 版本 10 | 57×57 | 约 300 字节 |
| 版本 40 | 177×177 | 约 2953 字节 |
版本 40，即 177×177 个模块，是标准规定的最大规格。无论将图片尺寸放得多大，标准二维码的格子数绝不会超过这个上限。插入更多行列的“私订”二维码，扫码软件会直接报错。
第二层：物理限制——扫描分辨率（格子不能无限缩小）
即使打印机精度足够，扫描端摄像头也有物理分辨率的极限。当单个格子在成像中占据不到 1 个像素时，必然与周围格子糊成一团，无法分辨。在达到版本 40 的上限之前，物理分辨率极限通常已经先到了。
容量对比总结（版本 40，L 级容错）：
| 内容类型 | 最大容量 |
|---|---|
| 纯数字 | 7,089 个字符 |
| 字母 + 数字 | 4,296 个字符 |
| 二进制 / 字节 | 2,953 个字节 |
| 汉字 | 1,817 个汉字 |
关键结论：二维码本质上只是一个“指针”或“钥匙”。没人把《西游记》存进二维码，大家存的是一个几十字符的短网址，背后的海量数据全在服务器上。二维码是链接到仓库的钥匙，而非仓库本身。
3. 解码原理：扫码的两步流程
扫描二维码，本质就是“拍摄照片 + 解码还原”两个独立步骤，全程由扫码软件在本地离线完成，服务器不参与。
第一步：图像采集与预处理
摄像头捕获的原始图像需要经过以下处理：
- 灰度化：彩色图像转为黑白灰度，削减数据量。
- 二值化：灰度图强制转为纯黑纯白。深色→黑色（1），浅色→白色（0）。
- 定位：寻找三个角的“回”字形定位图案。这三个大方块让软件无论从任何角度、任何方向扫描，都能立刻确定二维码的位置和朝向。
- 几何校正：根据定位图形计算出倾斜和透视变形，通过仿射变换拉正为标准正方形网格。
第二步：解码还原
- 读取网格：按规定顺序（从右下角开始以特定曲折路径），逐格读取黑白，还原为二进制序列。
- 去掩膜：用与编码相同的掩膜算法恢复原始数据排列。
- 纠错：用里德-所罗门码自动检测并修复读取错误。
- 解析内容：按编码时的字符集和模式，将二进制翻译回原始文本。最后，扫码软件根据文本类型执行动作：URL 则访问、自定义协议则唤起 APP、纯文本则直接显示。
二、支付的底层原理
支付环节的核心，在于从下单到付款再到确认的完整链路中，信息如何在不同应用与服务器之间流转。其本质不是一个支付动作，而是一场多方、多协议的消息接力。
1. 支付链接：二维码里存的到底是什么
支付二维码和普通二维码技术上毫无区别，只是内容刚好是一段能唤起支付应用的 URL。
微信支付链接：weixin://wxpay/bizpayurl?pr=...
支付宝支付链接：https://qr.alipay.com/...
两者设计哲学截然不同，分别代表了移动端深层链接的两种实现路径。
2. 两种技术路线：私有协议 vs 标准协议
微信的 weixin:// —— 私有 URL Scheme
这完全是微信为自己定制的私有协议。微信在安装时，通过操作系统的 URL Scheme 机制注册了 weixin:// 这个暗号。
处理流程：浏览器访问 weixin:// 时完全不理解其含义，转交给操作系统，操作系统查阅注册表后直接唤醒微信 APP，微信自行解析参数完成后续操作。
设计意图：把用户牢牢锁定在微信生态内，支付过程只能在微信 APP 中完成，更封闭、更可控。
支付宝的 https:// —— 标准互联网协议
支付宝的支付链接是一个真实存在于互联网上的 HTTPS 网址，可以被任何浏览器打开。
处理流程：浏览器访问该网址后，支付宝服务器根据请求头中的设备信息判断访问来源，随后返回一个包含唤醒指令的网页（通过 JavaScript 或 alipay:// 等标准 URL Scheme），操作系统据此唤醒支付宝 APP。
设计意图：兼容最广泛的支付场景（第三方网站、线下收银、独立商户），用通用互联网协议换取最强兼容性。
| 微信支付 | 支付宝 | |
|---|---|---|
| 链接格式 | weixin://... | https://qr.alipay.com/... |
| 协议类型 | 私有 URL Scheme | 标准 HTTPS + URL Scheme 唤起 |
| 设计理念 | 封闭生态内完成 | 开放通用标准 |
| 适用场景 | 微信生态内支付 | 全场景覆盖 |
3. APP 之间的“通信”：URL Scheme 唤起机制
这是支付环节最核心的操作系统机制。关键结论：APP 之间无法直接进程间通信，一切由操作系统作为中间人统一调度。
注册
APP 在安装时向操作系统声明自己能处理的 URL Scheme。例如微信声明 weixin://，支付宝声明 alipay://、alipays://。
调用
当任何 APP 尝试打开一个自己无法处理的链接时，操作系统查阅注册表，找到对应 APP 并将其唤醒，将完整的链接参数原封不动传递给被唤醒的 APP。整个过程中发送方完全不知道接收方的存在，只与操作系统交互。
标准流程
应用 A → "我要打开 alipay://..." → 操作系统 → 查阅注册表 → 应用 B ← "这是数据"
理解此机制后，支付环节中扫码触发的连锁反应便清晰了：浏览器识别出无法处理的支付协议链接 → 操作系统查表唤起支付宝/微信 → APP 解析订单参数 → 跳转支付确认页。
三、自动化下单与支付的工程实践
前两部分讲清了“为什么”，这部分解决“怎么做”。使用 Playwright 进行电商下单自动化，其架构必须围绕支付这个不可逾越的断点来设计。
1. 整体架构：三段式设计
支付环节在技术与法律上均不可绕过。因此，整体流程必然被切割为三段：
第一段（自动） 第二段（手动） 第三段（自动）
登录 → 浏览加购 → 下单 → [人工支付] → 确认结果、后续处理
这不是技术妥协，而是法律底线与金融安全的必然要求。支付行为必须基于独立可信设备完成。
2. 第一段：登录——凭证复用方案
跳过重复登录验证的核心思路：人工完成一次登录，保存凭证，后续不断复用。
原理：首次使用时由真人在真实浏览器中完成扫码或滑块验证，登录成功后工具将浏览器返回的身份凭证（Cookie / Token）加密保存到本地。后续每次操作前先将此凭证注入浏览器，网站验证有效后直接放行，不再触发验证码。
手动提取 Token：在浏览器开发者工具中，前往 Application → Cookies，找到 session_id 或 auth_token 等字段复制即可。亦可使用工具自动持久化。
风险：凭证复用大幅降低登录时的封号风险，但风控系统的关注点会转移至使用过程中的行为模式（高频操作、固定时间精准操作、新号无互动等）。使用中仍需模拟人类随机性。
3. 第二段：下单到支付——拦截支付链接并交给人
这是自动化与人工衔接最紧密的环节。
获取支付链接
核心操作为拦截网络请求，而非解析 HTML 或解析二维码图片。
使用 Playwright 的请求监听能力，在点击提交订单前启动监听器，捕获页面发出的所有请求。匹配支付网关的特征域名（如 cashier.alipay.com 或 payapp.weixin.qq.com），一旦匹配则提取完整 URL，即为支付链接。
将支付链接交给用户
方案一：生成二维码图片。使用任意二维码生成库，将支付链接作为输入，生成的二维码图片展示给用户扫描。
方案二：直接推送链接。将链接通过邮件或消息推送给用户，用户在手机上点击同样唤起支付 APP。
不可自动化的红线
支付需在另一个用户完全掌控的独立设备上完成，且必须通过生物识别或支付密码确认。绕过此步骤将从“自动化工具”变为“金融违规”。
4. 第三段：支付结果的智能轮询
用户支付完成后，自动化程序需准确判断支付结果。
不能用 URL 变化判断的原因
支付完成这一事件发生在支付服务器与电商后台之间。电商前端页面的更新有两种实现方式：旧式的同步回调（支付网关重定向至结果页，URL 会变化），以及目前主流的异步通知配合前端轮询或长连接推送（URL 全程不变）。因此监听 URL 变化不可靠。
正确做法：可配置的元素监听
为每个目标平台单独配置成功标志。使用 YAML 等格式定义成功与失败选择器及匹配文本。轮询逻辑定期检查指定元素是否出现在页面上，以此判断支付结果。匹配到成功标志后程序自动继续后续操作。
由于各平台前端代码无统一标准（class、id、结构均不同），不存在通用万能识别代码，必须在架构上接受定制化，建立可配置的平台规则库。可提供通用关键词（“支付成功”、“交易成功”等）作为兜底，但精度较低。
5. 完整流程概览
1. 登录态准备
手动扫码登录 → 提取并保存 Cookie/Token
2. 自动化操作
注入凭证 → 浏览商品 → 加入购物车 → 提交订单
3. 支付衔接
拦截支付链接 → 生成二维码或推送链接给用户 → 程序暂停并开始轮询
4. 手动支付
用户在手机上扫码 → 在支付 APP 内完成生物识别/密码验证
5. 结果确认
程序轮询到成功标志 → 自动截图 → 后续操作
6. 核心原则总结
- 技术边界：支付不可自动化，这是法律与金融安全的红线，也是保护开发者不卷入金融违规的护栏。
- 凭证复用：用“人工登录一次 + 凭证持久化”替代“反复破解验证码”，更务实也更安全。
- 二维码角色：二维码只是 URL 的图形化运输工具，自动化场景下可直接获取支付链接，无需生成或扫描二维码。
- 支付确认：监听页面特定元素比监听 URL 变化更可靠。每个平台需定制配置，可配置的平台规则库本身就是自动化工具的核心价值。
- 跨 APP 调用：APP 之间无法直接通信，一切经由操作系统的 URL Scheme 注册表转发，这是移动端深层链接的底层基石。
- 架构思维：优秀的自动化工具不在取代所有人工操作，而在精准识别“哪些可自动化、哪些必须人工”，并在两个阶段之间提供无缝衔接。这是所有需与真实世界交互的自动化系统的基本设计哲学。
