1. 项目概述：为什么我们需要OpenWPM这样的工具？

在今天的互联网上，浏览网页早已不是简单的“点击-查看”过程。当你打开一个新闻网站，页面背后可能同时有几十个甚至上百个第三方脚本在运行。它们有的负责广告展示，有的收集用户行为数据，有的进行A/B测试，还有的可能是恶意的追踪器或加密货币挖矿脚本。作为一名开发者、安全研究员，或者仅仅是关心自己数字隐私的普通用户，你可能会好奇：这个网页到底在我背后做了什么？它向哪些服务器发送了数据？这些数据包含了什么？那些自动执行的JavaScript代码，除了渲染页面，还在偷偷执行什么操作？

传统上，要回答这些问题，我们得搬出一套组合工具：用浏览器开发者工具看网络请求，用Wireshark抓包分析底层流量，再手动写一些脚本去拦截和解析JavaScript。这个过程不仅繁琐、割裂，而且难以规模化——你很难用这套方法去自动化地分析成千上万个网站。这正是OpenWPM诞生的背景。它不是一个单一的工具，而是一个为大规模、自动化网页测量而设计的完整平台。你可以把它理解为一个“可编程的浏览器机器人”，它不仅能像普通浏览器一样访问网页，还能以极高的精度记录下访问过程中发生的一切：每一个HTTP请求和响应的头信息与内容、每一个Cookie的设置与发送、每一段JavaScript的执行与它对DOM的修改、甚至每一个Web API的调用。

我最初接触OpenWPM是在研究第三方追踪器时。手动分析几个网站后我就意识到，没有自动化工具，这项工作根本不可能完成。OpenWPM让我能够编写一个简单的脚本，就自动完成打开浏览器、访问网站、滚动页面、点击按钮等一系列操作，并在这个过程中捕获所有相关的隐私与安全数据。它输出的结构化数据（通常是SQLite数据库）为后续的分析提供了极大的便利。无论是学术研究、企业安全审计，还是合规性检查，OpenWPM都提供了一个强大而可靠的起点。

2. 核心需求解析：从流量捕获到行为分析的全链路

一个完整的Web隐私与安全分析，远不止于看看网络请求列表。我们需要一个分层的、深入的视角。OpenWPM的设计正好覆盖了从网络层到应用层，再到代码执行层的完整链条。

2.1 网络层：超越Wireshark的HTTP/S流量捕获

提到抓包，很多人第一反应是Wireshark。它是一个强大的网络协议分析器，能捕获网卡上的所有流量。使用Wireshark，你可以完成热搜词里的所有操作：过滤特定流量、分析TCP三次握手、查看HTTP报文结构、还原传输的文件、分析DNS查询，甚至从PCAP文件中提取明文密码。这些是网络分析的基石。

然而，对于现代Web分析，仅靠Wireshark有几个明显的局限：

1. HTTPS解密困难：绝大多数网站已启用HTTPS，Wireshark捕获的是加密后的TLS流量。要解密，你需要在客户端安装自定义根证书并配置SSL密钥日志，过程复杂且可能影响浏览器正常行为。
2. 浏览器上下文缺失：Wireshark看到的是原始网络包，它不知道哪个包对应哪个浏览器标签页，也不知道这个请求是由页面加载触发的，还是由某个JavaScript事件触发的。
3. 难以关联行为：一个JavaScript函数可能触发多个网络请求，Wireshark难以建立代码执行与网络活动之间的因果关系。

OpenWPM解决了这些问题。它通过直接集成浏览器（默认为Firefox）并在其内部进行代理或扩展程序注入，能够以明文形式记录所有HTTP和HTTPS请求与响应，无需复杂的TLS解密设置。更重要的是，它能将每个请求与具体的浏览器实例、浏览上下文（如哪个iframe）关联起来。

2.2 应用层：JavaScript执行与DOM操作的透视

网络流量告诉我们“数据去了哪里”，而JavaScript行为分析则告诉我们“这些数据是怎么被收集和送出去的”。这是OpenWPM最核心的能力之一。现代网站大量使用JavaScript进行动态内容加载、用户交互处理和数据分析。许多隐私追踪行为，如指纹采集（收集浏览器字体、屏幕分辨率、Canvas特征等）、行为事件监听（鼠标移动、点击、滚动）、以及数据打包发送，都是通过JavaScript完成的。

OpenWPM通过浏览器扩展程序，能够注入检测脚本，监控以下关键行为：

• JavaScript调用栈：当调用特定的敏感API（如navigator.userAgent,canvas.getContext(‘2d’).toDataURL()用于指纹采集，或XMLHttpRequest.send用于发送数据）时，记录是网页中哪一行源代码发起的调用。
• DOM修改：记录JavaScript对网页文档对象模型（DOM）的增删改操作。这对于分析广告插入、内容篡改或恶意脚本行为至关重要。
• Web Storage访问：监控对localStorage、sessionStorage的读写，这些都是持久化追踪用户身份的常用手段。
• Cookie操作：记录Cookie的设置、读取和删除，不仅是HTTP Cookie，还包括JavaScript通过document.cookie操作的Cookie。

2.3 自动化与规模化：研究级工具的关键

手动分析一两个网站或许可行，但要做横向对比研究或大规模扫描，自动化是唯一途径。OpenWPM提供了一个Python自动化框架，允许你通过脚本控制浏览器的所有行为：启动配置、访问URL列表、执行自定义的点击或滚动操作、管理Cookie和缓存策略、以及最终的数据导出。你可以轻松地将其部署到服务器上，进行持续数天、覆盖数万个网站的数据采集任务。这种能力是Wireshark等交互式工具无法比拟的。

3. 环境搭建与基础配置实战

理论讲完了，我们动手搭建一个可用的OpenWPM环境。这里我会以macOS/Linux系统为例，Windows系统在步骤上大同小异，主要注意路径和个别命令的差异。

3.1 系统与依赖准备

OpenWPM基于Python 3.7+，推荐使用Python 3.8或3.9以获得最佳兼容性。首先确保你的系统已安装Python和pip。

# 检查Python版本 python3 --version pip3 --version

我强烈建议使用虚拟环境（virtual environment）来管理项目依赖，避免污染系统Python环境。

# 安装虚拟环境工具（如果尚未安装） pip3 install virtualenv # 创建并进入项目目录 mkdir openwpm-tutorial && cd openwpm-tutorial # 创建虚拟环境 python3 -m venv venv # 激活虚拟环境 # macOS/Linux: source venv/bin/activate # Windows: # venv\Scripts\activate # 激活后，命令行提示符前通常会出现 (venv) 标识

接下来，安装OpenWPM。最直接的方式是通过pip从GitHub安装。由于OpenWPM依赖较多，这个过程可能需要几分钟。

pip install git+https://github.com/openwpm/OpenWPM.git

注意：直接pip install可能会遇到某些系统依赖的问题，特别是与密码学相关的库（如cryptography）。如果安装失败，请先确保你的系统已安装Python开发工具和SSL开发库。

• Ubuntu/Debian:sudo apt-get install build-essential libssl-dev libffi-dev python3-dev
• macOS:brew install openssl，然后可能需要设置环境变量告知编译器openssl的位置。
• 如果遇到cryptography安装错误，通常按照错误提示安装上述系统包即可解决。

3.2 验证安装与首次运行

安装完成后，我们可以写一个最简单的脚本demo.py来测试OpenWPM是否能正常工作。这个脚本将启动一个受控的浏览器，访问一个示例网站，并打印出捕获到的请求数量。

# demo.py from openwpm import CommandSequence from openwpm import TaskManager from openwpm.config import BrowserParams, ManagerParams # 1. 配置管理器参数 manager_params = ManagerParams(num_browsers=1) # 启动1个浏览器实例 # 2. 配置浏览器参数 browser_params = [BrowserParams() for _ in range(manager_params.num_browsers)] # 3. 创建任务管理器 with TaskManager( manager_params, browser_params, ) as manager: # 定义要访问的URL url = "http://example.com" # 4. 为第一个（也是唯一一个）浏览器创建命令序列 command_sequence = CommandSequence(url, reset=True) # 5. 添加命令：访问并等待页面加载 command_sequence.get(sleep=3) # sleep参数是加载后等待的秒数，确保资源加载完毕 # 6. 将命令序列交给浏览器执行 manager.execute_command_sequence(command_sequence, index=0) print("首次运行测试完成！") # 数据默认会保存在当前目录下的 `openwpm_profile` 文件夹中

运行这个脚本：

python demo.py

如果一切顺利，你会看到Firefox浏览器（OpenWPM的默认浏览器）自动启动，访问example.com，然后关闭。控制台输出“首次运行测试完成！”。同时，当前目录下会生成一个openwpm_profile文件夹，里面包含了浏览器的配置文件、扩展程序和最重要的——一个名为crawl-data.sqlite的数据库文件。所有的捕获数据都存储在这里。

3.3 核心配置文件深度解读

在刚才的demo中，我们使用了默认配置。要发挥OpenWPM的全部威力，必须理解并配置BrowserParams和ManagerParams。

ManagerParams控制整个任务管理器的行为，关键参数包括：

• num_browsers: 并行运行的浏览器实例数。提高此数可加速数据收集，但会显著增加内存和CPU占用。根据你的机器性能（特别是内存）谨慎设置，一般4-8个是常见范围。
• data_directory: 数据存储目录。默认为./openwpm_profile。建议为大型爬虫任务指定一个独立的、空间充足的路径。
• log_directory: 日志存储目录。调试时查看日志至关重要。
• memory_watchdog: 是否启用内存监控。如果单个浏览器内存占用过高，会自动重启该实例，防止崩溃。

BrowserParams控制每个浏览器实例的行为，这是功能配置的核心：

• http_instrument和js_instrument: 这是最重要的两个开关。必须将其设置为True才能启用HTTP流量和JavaScript行为捕获。

  browser_params = BrowserParams() browser_params.http_instrument = True # 开启HTTP/S流量捕获 browser_params.js_instrument = True # 开启JavaScript行为检测

• cookie_instrument: 是否记录Cookie事件。
• navigation_instrument: 是否记录页面导航事件（如前进、后退）。
• save_content: 决定保存哪些HTTP响应的内容体。
  • save_content:“script”只保存JavaScript文件内容；“all”保存所有响应内容（慎用，数据量巨大）；None不保存。
  • 对于隐私研究，通常我们关心请求的URL、头部和参数，而非完整的页面或图片内容。设置为“script”有助于分析第三方JS的行为。
• display_mode: 浏览器显示模式。“headless”（无头模式，不显示GUI，适合服务器）、“native”（完整显示，适合调试）。生产环境强烈建议使用“headless”以节省资源。

一个功能齐全的研究配置示例：

from openwpm.config import BrowserParams, ManagerParams manager_params = ManagerParams( num_browsers=2, data_directory="./my_crawl_data", log_directory="./logs", memory_watchdog=True ) browser_params = [] for _ in range(manager_params.num_browsers): bp = BrowserParams() bp.http_instrument = True bp.js_instrument = True bp.cookie_instrument = True bp.navigation_instrument = True bp.save_content = “script” # 只保存JS文件内容 bp.display_mode = “headless” browser_params.append(bp)

4. 实战：编写一个完整的隐私爬虫脚本

现在，我们整合所学，编写一个更有实际意义的脚本。这个脚本将：

1. 启用所有关键的检测功能。
2. 访问一组预设的网站（包括一个电商和一个新闻站）。
3. 在页面上执行简单的交互（滚动）。
4. 将数据保存到指定的SQLite数据库。

# privacy_crawler.py import sqlite3 from openwpm import CommandSequence, TaskManager from openwpm.config import BrowserParams, ManagerParams # 定义要爬取的网站列表 SITES_TO_VISIT = [ “https://httpbin.org/headers”, # 一个很好的测试站，会回显你的请求头 “https://example.com”, # 注意：出于法律和道德，请仅爬取允许公开访问或你拥有权限的网站。 # 大规模爬取商业网站前，请务必检查其robots.txt文件。 ] def crawl_sites(): # ========== 配置阶段 ========== manager_params = ManagerParams( num_browsers=2, # 两个浏览器并行 data_directory=“./crawl_output”, log_directory=“./crawl_logs”, ) browser_params = [] for i in range(manager_params.num_browsers): bp = BrowserParams() # 核心仪器：全部打开 bp.http_instrument = True bp.js_instrument = True bp.cookie_instrument = True bp.navigation_instrument = True # 内容保存策略：只存JS，节省空间 bp.save_content = “script” # 启用弹窗拦截和幽灵模式（不记录历史、不保存密码等） bp.preferences = { “privacy.trackingprotection.enabled”: True, “privacy.trackingprotection.pbmode.enabled”: True, “browser.privatebrowsing.autostart”: True, # 每次会话都是私密模式 } # 为每个浏览器设置不同的代理（示例，需要你有可用的代理服务器） # bp.proxy = f“http://your-proxy-{i}:8080” browser_params.append(bp) # ========== 执行爬取 ========== with TaskManager(manager_params, browser_params) as manager: for idx, site in enumerate(SITES_TO_VISIT): # 决定由哪个浏览器实例来执行这个任务（简单的轮询分配） browser_index = idx % manager_params.num_browsers # 创建命令序列 cs = CommandSequence(site, reset=True) # reset=True表示每次访问前清除缓存和Cookie # 命令1：访问页面 cs.get(sleep=5) # 等待5秒，确保页面及异步资源加载 # 命令2：模拟滚动页面（触发懒加载或滚动监听事件） cs.scroll_to_bottom(sleep=2) # 命令3：可以添加更多交互，比如点击特定CSS选择器的元素 # cs.click(selector=“button.primary”, timeout=5) # 执行命令序列 manager.execute_command_sequence(cs, index=browser_index) print(f“已爬取: {site} (使用浏览器实例 {browser_index})”) print(“\n所有站点爬取完成！”) print(f“数据已保存至: {manager_params.data_directory}/crawl-data.sqlite”) if __name__ == “__main__”: crawl_sites()

运行此脚本：python privacy_crawler.py。你会看到两个无头Firefox浏览器（没有图形界面）依次启动并访问列表中的网站，执行滚动操作，然后关闭。所有数据都被记录到./crawl_output/crawl-data.sqlite数据库中。

实操心得：

1. sleep参数的艺术：get或scroll_to_bottom后的sleep时间至关重要。时间太短，页面资源（尤其是通过AJAX加载的内容）可能还没加载完，导致漏抓。时间太长，则效率低下。对于复杂单页应用（SPA），可能需要更长的等待时间或使用wait_for_element命令来等待特定元素出现。
2. reset=True的代价与收益：CommandSequence(url, reset=True)会在每次访问前重置浏览器状态（清除缓存、Cookie、LocalStorage等）。这确保了每次访问都是独立的，避免了站点间状态的污染，对于测量首次访问行为非常有用。但这也使得模拟真实的用户连续浏览会话变得困难。根据你的研究目标决定是否启用。
3. 道德与法律红线：务必尊重robots.txt，控制爬取速率（避免对目标服务器造成DoS攻击），仅爬取公开数据。对于敏感或个人数据，必须确保你的研究符合相关法律法规（如GDPR）并获取必要同意。

5. 数据分析：从SQLite数据库中挖掘洞察

爬虫跑完了，生成了crawl-data.sqlite文件，这才是宝藏所在。我们来看看里面有什么，以及如何分析。

5.1 数据库结构初探

使用任何SQLite浏览器（如DB Browser for SQLite）或命令行，连接数据库并查看表。

sqlite3 ./crawl_output/crawl-data.sqlite .tables

你会看到一系列表，最重要的几个包括：

• http_requests: 存储所有HTTP请求的详细信息。
• http_responses: 存储所有HTTP响应的详细信息，与http_requests通过request_id关联。
• javascript: 存储JavaScript执行记录，特别是对特定API的调用。
• javascript_cookies: 存储通过JavaScript (document.cookie) 设置的Cookie。
• crawl_history: 爬取任务的历史记录。

5.2 基础SQL查询示例

让我们运行一些查询来获得直观感受。

查询1：查看访问了哪些站点，以及发出了多少个请求

SELECT h.url AS visited_site, COUNT(r.id) AS total_requests FROM crawl_history h LEFT JOIN http_requests r ON h.browser_id = r.browser_id AND h.visit_id = r.visit_id GROUP BY h.url ORDER BY total_requests DESC;

这个查询将展示每个目标URL触发了多少个HTTP请求，帮助你一眼看出哪个网站最“繁忙”。

查询2：找出最常见的第三方域名（追踪器嫌疑）

SELECT -- 使用SQLite的net_extract_host函数从URL中提取域名 net_extract_host(r.url) AS request_domain, COUNT(*) AS request_count, GROUP_CONCAT(DISTINCT h.url) AS visited_from_sites -- 哪些主站发起了对此域名的请求 FROM http_requests r JOIN crawl_history h ON r.visit_id = h.visit_id AND r.browser_id = h.browser_id WHERE r.url IS NOT NULL GROUP BY request_domain HAVING request_count > 5 -- 只看请求次数较多的域名 ORDER BY request_count DESC LIMIT 20;

这个查询是隐私研究的核心。它列出了被请求最多的第三方域名。像google-analytics.com、doubleclick.net、facebook.com、scorecardresearch.com等频繁出现的域名，通常是广告或分析追踪器。

查询3：检查是否有脚本尝试进行Canvas指纹采集Canvas指纹采集是一种常见的浏览器指纹技术。我们可以查询javascript表来寻找相关API调用。

SELECT j.script_url, j.symbol, -- 被调用的API函数名 h.url AS visited_site, COUNT(*) AS call_count FROM javascript j JOIN crawl_history h ON j.visit_id = h.visit_id AND j.browser_id = h.browser_id WHERE j.symbol LIKE ‘%Canvas%’ OR j.symbol LIKE ‘%toDataURL%’ OR j.symbol LIKE ‘%getImageData%’ GROUP BY j.script_url, j.symbol, h.url ORDER BY call_count DESC;

如果发现来自第三方域的脚本频繁调用HTMLCanvasElement.toDataURL()或CanvasRenderingContext2D.getImageData()，这很可能是在进行指纹采集。

5.3 使用Python进行高级分析

SQL适合初步探索，更复杂的分析通常需要借助Python的pandas和sqlite3库。

# analyze_data.py import sqlite3 import pandas as pd from urllib.parse import urlparse # 连接数据库 conn = sqlite3.connect(‘./crawl_output/crawl-data.sqlite’) # 1. 将http_requests表读入DataFrame df_requests = pd.read_sql_query(“SELECT * FROM http_requests”, conn) print(f“共捕获 {len(df_requests)} 个HTTP请求”) print(df_requests[[‘url’, ‘method’, ‘referrer’, ‘headers’]].head()) # 2. 提取请求的顶级域名（eTLD+1） def get_etld1(url): try: # 使用urlparse提取网络位置，再提取主机名 netloc = urlparse(url).netloc # 简单处理：取最后两部分。对于复杂情况，应使用如‘tldextract’库 parts = netloc.split(‘.’) if len(parts) >= 2: return ‘.’.join(parts[-2:]) return netloc except: return None df_requests[‘request_domain’] = df_requests[‘url’].apply(get_etld1) # 3. 统计各第三方域名的请求频次 third_party_domains = df_requests[‘request_domain’].value_counts().head(15) print(“\n请求最频繁的15个域名：”) print(third_party_domains) # 4. 关联浏览历史，分析每个主站的第三方请求 df_history = pd.read_sql_query(“SELECT visit_id, url AS site_visited FROM crawl_history”, conn) df_merged = pd.merge(df_requests, df_history, on=‘visit_id’, how=‘left’) df_merged[‘site_domain’] = df_merged[‘site_visited’].apply(get_etld1) # 找出主站及其对应的第三方请求 third_party_map = df_merged[df_merged[‘site_domain’] != df_merged[‘request_domain’]] grouped = third_party_map.groupby(‘site_domain’)[‘request_domain’].apply(lambda x: x.value_counts().head(5).to_dict()) print(“\n各主站的前5大第三方域名：”) for site, domains in grouped.items(): print(f“{site}: {domains}”) conn.close()

这个脚本提供了比纯SQL更灵活的分析能力，比如更精确的域名提取和复杂的分组统计。

6. 高级技巧与避坑指南

在实际使用OpenWPM进行大规模或长期研究时，你会遇到一些挑战。以下是我踩过坑后总结的经验。

6.1 性能优化与稳定性

• 内存泄漏与浏览器崩溃：长时间运行多个浏览器实例，Firefox可能会内存泄漏。务必启用memory_watchdog。同时，定期重启浏览器实例（例如，每爬取50-100个站点后，通过TaskManager重启所有browser）可以大幅提升稳定性。
• 数据库锁与写入性能：所有浏览器实例并发写入同一个SQLite数据库，在极高负载下可能遇到锁问题。对于超大规模爬取（>10万站点），考虑将数据先写入临时文件或使用更强大的数据库后端（如PostgreSQL，但需要修改OpenWPM源码）。
• 无头模式下的资源加载：有些网站会检测无头浏览器并返回不同的内容或直接屏蔽。OpenWPM的默认配置已经尝试伪装，但更高级的反爬可能需要你自定义BrowserParams中的preferences来调整User-Agent、WebGL渲染器等指纹特征。

6.2 JavaScript检测的粒度与性能开销

js_instrument=True会显著增加页面负载和执行时间，因为它需要包装和监控大量的JavaScript API。OpenWPM允许你进行精细化配置，只监控你关心的API，从而减少开销。

你可以在BrowserParams中设置js_instrument_settings：

browser_params.js_instrument_settings = [ # 只监控特定的、与隐私相关的API “collection_fingerprinting”, # 指纹收集相关API（如canvas, audio, fonts） “properties”, # 访问navigator, screen等对象属性 “cookies”, # document.cookie操作 “events”, # 事件监听器 # “all” # 监控所有，开销最大 ]

根据你的研究问题选择合适的检测集合，能在数据质量和爬取速度之间取得更好平衡。

6.3 处理复杂交互与单页应用（SPA）

现代网站很多是SPA，内容动态加载。简单的get()和sleep可能抓不到所有内容。

• 使用wait_for_element：等待特定CSS选择器的元素出现后再继续，这比固定sleep更可靠。

  command_sequence.wait_for_element(selector=“div.lazy-loaded-content”, timeout=10)

• 组合交互命令：模拟真实用户行为链。

  cs.get(sleep=3) cs.click(selector=“#loadMoreButton”, timeout=5) cs.scroll_to_bottom(sleep=2) cs.click(selector=“.tab-item:nth-child(2)”, timeout=5) # 点击第二个标签页

• 执行自定义JavaScript：对于极其复杂的交互，可以直接注入并执行JS代码。

  cs.run_custom_function(“() => { window.scrollBy(0, 500); }”, timeout=5)

6.4 数据管理与清洗

原始数据非常庞大。定期进行数据清洗和聚合是必须的。

• 及时备份与归档：爬取完成后，立即将crawl-data.sqlite备份。分析时，最好在备份副本上进行。
• 提取核心特征：不要每次都全表扫描。将分析结果（如每个站点的第三方域名列表、特定API调用次数）提取到更小的汇总表中，方便后续统计和可视化。
• 处理重复和噪声：有些请求是浏览器预加载、favicon请求或健康检查，在分析时可能需要过滤掉。

7. 常见问题排查实录

即使按照教程操作，你也可能会遇到一些问题。这里记录一些典型问题和解决方法。

Q1: 运行脚本时出现‘WebDriverException: Message: Process unexpectedly closed with status 1’错误。A1:这是最常见的错误之一，通常是浏览器启动失败。首先检查：

• 依赖是否完整：确保已安装所有系统依赖（如libgtk，对于无头模式）。在Ubuntu上，可以尝试sudo apt-get install -y firefox xvfb。
• Firefox版本兼容性：OpenWPM对Firefox版本有要求。确保系统安装的Firefox是较新的ESR版本或稳定版。可以通过which firefox和firefox --version检查。有时需要手动指定Firefox二进制文件路径：browser_params.browser_binary = ‘/usr/bin/firefox’。
• 端口冲突：确保没有其他进程占用了OpenWPM要用的调试端口（默认从9000开始）。可以尝试重启电脑或修改ManagerParams中的testing参数来改变端口范围。

Q2: 爬取过程中浏览器卡住或无响应。A2:

• 检查超时设置：在CommandSequence中，为每个可能耗时的操作（如get,click,wait_for_element）设置合理的timeout参数。超时后命令会抛出异常，你可以用try…except捕获并记录，然后继续下一个任务。
• 启用更详细的日志：在ManagerParams中设置log_level=‘DEBUG’，查看日志文件./crawl_logs/openwpm.log，里面可能有错误堆栈信息。
• 减少并行数：将num_browsers从4或8降低到2或1，看看是否是资源（CPU/内存）不足导致的。

Q3: 数据库中没有javascript表的数据，或者数据很少。A3:

• 确认开关已打开：检查脚本中是否设置了browser_params.js_instrument = True。
• 检查检测配置：确认js_instrument_settings没有设置成一个过于狭窄的集合，导致你想监控的API不在其中。初次调试可以设置为[“all”]。
• 页面可能没有JS：你访问的页面可能非常简单，没有或只有极少的JavaScript。换一个复杂的现代网站（如带有视频播放器、社交分享按钮的新闻站）测试。

Q4: 如何爬取需要登录的网站？A4:OpenWPM本身不直接处理登录，但可以通过命令序列模拟。

1. Cookie注入：如果你已有登录后的Cookie，可以在CommandSequence之前，通过cs.add_cookie()方法将Cookie注入浏览器。
2. 自动化填写表单：使用cs.run_custom_function()执行JavaScript来填充用户名/密码输入框并点击提交按钮。注意：此方法需在脚本中硬编码凭证，极不安全，仅用于测试你有权限的账户。
3. 使用配置文件：更安全的方式是预先使用一个普通浏览器登录目标网站，导出其Cookie文件（可以使用浏览器扩展），然后在OpenWPM启动时加载这个配置文件目录。这涉及到更复杂的BrowserParams配置。

OpenWPM是一个功能强大但也有一些复杂度的工具，入门时的配置和调试可能会花费一些时间。但一旦跑通，它为你打开的这扇Web隐私与安全测量的大门，其价值远超这些前期投入。从简单的流量统计到深度的JS行为关联分析，你可以根据自己的研究兴趣不断深入挖掘。