浏览器四类选型：本地、指纹、云端与自动化专用

选浏览器这件事，问法常常是错的：哪一款更好用。换个问法就顺得多——我要在这个浏览器里干什么活。按职责划，能用的其实是四类：本机上的普通浏览器、为账号身份服务的指纹浏览器、跑在云端的云手机或云浏览器、给脚本和 AI 调用的自动化专用浏览器。

本机浏览器：最省事，也最先撞墙

日常上网、查资料、登录自己的几个账号，本机浏览器就是最优解。装个隐私扩展、关掉不必要的同步，成本几乎为零。

问题出现在账号变多之后。多用户配置能解决 Cookie 不串，但底层设备特征还是同一套；代理通常只能全局设置，没法给每个配置单独定出口；配置一多，没有分组和标签，找起来都费劲。更麻烦的是身份一致性——几个账号挤在一台机器、一套环境里，平台侧看到的更像是同一个操作主体。

这类工具的设计目标是让你更难被追踪，手段是增加随机性、降低指纹的熵。多账号要的恰好相反：长期稳定、参数自洽。目标相反的两件事，没法互相替代。

指纹浏览器：一个账号一套自洽的身份

指纹浏览器的做法是给每个账号建一个独立环境，里面的指纹参数成套生成并固定下来，涵盖 IP、时区、User-Agent、Canvas、WebGL、音频指纹、字体指纹、媒体设备 ID 这些维度，Cookie 和本地存储彼此隔离。创建之后参数不再变，账号下次登录还是同一台设备的样子。

代理按环境绑定，每个环境走自己的出口，支持 HTTP、HTTPS、SOCKS5 这类主流协议；绑好代理之后，时区、语言可以跟着一起匹配，避免出现 IP 在美国、语言和时区却在别处的破绽。平台判断一个环境是不是真实用户，看的从来不只是 IP。

管理能力是它的另一半价值：分组、标签、备注、批量导入导出、批量改配置、批量开关，环境的创建与回收能通过接口完成，脚本和 AI 可以直接调用。

局限也说清楚。它不是给日常上网准备的，复杂度和花费都高。另一个容易忽略的长期问题是内核要跟得上平台风控的更新节奏，选的时候值得翻翻更新日志，看是套话居多还是能写清改了什么。

云手机与云浏览器：把设备搬到云端

这两类的共同点是把运行位置从本机挪到云端。云手机给的是云端上的移动设备，适合要真机环境、要装 App 的移动端场景；云浏览器给的是云端的浏览器实例，本机不承担内存和算力压力。

代价很直接：按时间计费，跑得越久、开得越多，账单越线性；网络往返带来的延迟，对需要精细交互的任务不友好；本地素材要先传上去。换来的是接入方便，跨设备、跨地点，团队里几个人可以连到同一台云端设备。

还有一点常被忽略：云端实例通常只是执行位置，账号身份不会自动长在上面，身份和隔离仍然得另外规划。

自动化专用浏览器：给脚本和 AI 用的执行器

这类浏览器的目标只有一个，把流程执行好。它支持编程控制，可以通过 CDP 协议被外部框架连上，也能被 AI 工具通过接口调起来做页面操作、截图、读取内容、填表。

适合的活是采集、回归测试、批量重复动作。它自己不带账号身份，多账号场景下通常的做法是让它连到一个已存在的隔离环境，执行归执行，身份归身份。

局限在于没有业务判断。页面改版、元素消失，脚本就失败，需要有人在前面做决策、在后面处理例外。

按任务特征走一遍

判断顺序可以这么走。

先问这件事要不要长期维持多个账号身份。要，就往指纹浏览器上找；不要，继续往下。

再问有没有真机或者移动 App 的硬要求。有，看云手机；只是想把负载挪出本机，看云浏览器。

接着问任务是不是由脚本或 AI 驱动、反复跑同一套流程。是，用自动化专用浏览器，同时把账号身份交给环境层，让它连过去。

三条都不是，本机浏览器加隐私设置就够了，没必要上重工具。

实际项目里这几类经常叠着用：环境层放指纹浏览器管身份，执行层用自动化浏览器跑流程，需要真机或异地接入的部分放云端。规模化的多账号场景里，PurpleMark 这类环境管理工具承担的就是环境层那一环，把每个账号的身份和会话分开，上层执行器才调得动。

一句话：先定身份怎么管，再定活在哪跑。