测试安装包时，建议用“安装前后对比 + 实时监控”两种方式记录注册表改动。

方法一：用 Regshot 做前后对比

适合快速查看安装包新增、修改或删除了哪些键值。

1. 以管理员身份运行 Regshot。
2. 选择 64 位扫描（如果系统和安装包涉及 64 位注册表），点击 1st shot。
3. 安装软件，按需要启动一次并完成配置。
4. 回到 Regshot，点击 2nd shot，再生成比较报告。
5. 保存报告，重点检查 HKLM、HKCU、HKCR、HKU 等项。

为避免干扰，测试前尽量关闭其他程序，并在干净的虚拟机快照中操作。

方法二：用 Process Monitor 实时记录

适合确认哪个进程在安装时修改了注册表。

1. 以管理员身份运行 Microsoft Sysinternals 的 Process Monitor（Procmon）。
2. 清空当前事件：Ctrl+X。
3. 设置过滤条件，例如：
   • Operation 是 RegCreateKey、RegSetValue、RegDeleteKey 或 RegDeleteValue
   • Process Name 是安装程序进程名，或其子进程名
4. 开始捕获，运行安装包，再停止捕获。
5. 用 Ctrl+F 搜索软件名、厂商名或安装目录相关路径。
6. 通过 File → Save 保存为 .PML（保留完整事件），必要时另存为 CSV。

安装程序可能会启动 msiexec.exe、服务进程或自解压子进程；只过滤最初的安装程序可能漏掉实际改动者。Procmon 中可查看事件的进程、操作、注册表路径和数据。

MSI 安装包的补充

如果是 .msi，可以启用 Windows Installer 日志：

msiexec /i package.msi /L*V install.log

该日志有助于追踪安装流程，但不一定能完整替代注册表快照或 Procmon。

推荐组合：在虚拟机快照中用 Regshot 获取整体差异，同时用 Procmon 定位具体进程和操作。注意注册表中可能包含用户名、路径或其他敏感信息，分享日志前应先检查并脱敏。

可以用 Sandboxie-Plus 把来路不明的安装包放在隔离环境里初步观察，但沙盒不是绝对防护：恶意程序仍可能利用漏洞、尝试联网或诱导你把文件带出沙盒。不要在里面输入真实账号、密码或支付信息，也不要把测试结果当作“安全证明”。

建议步骤

1. 先做基础检查

   • 从 Sandboxie-Plus 官方来源下载安装，并保持系统和安全软件更新。
   • 对安装包查看来源、数字签名和哈希；用杀毒软件扫描。来源明显可疑或要求关闭安全软件的，最好直接删除。
   • 重要文件先备份。测试时使用普通账户，不要以管理员身份启动安装包。

2. 创建专用沙盒

   • 在 Sandboxie-Plus 中新建一个专用沙盒，例如“未知安装包测试”。
   • 使用隔离程度较高的设置；不要允许它访问真实桌面、文档、下载目录、浏览器数据或其他个人文件。
   • 关闭或限制沙盒对主机文件的写入和恢复权限。不同版本的选项名称可能略有区别。

3. 尽量限制网络

   • 如果只是观察安装过程，先断网或在 Sandboxie 中禁用该沙盒的网络访问。
   • 若必须观察联网行为，使用没有真实账号的独立测试环境；不要访问网银、邮箱或工作系统，也不要开放局域网共享。

4. 在沙盒中运行

   • 右键安装包，选择 “在沙盒中运行”，确认启动的是沙盒内进程。
   • 安装过程中留意它是否索要管理员权限、关闭防护、安装驱动或证书、创建服务、修改浏览器设置、弹出异常联网请求。遇到这些情况立即停止，不要批准权限。
   • 可以观察沙盒内新建的文件、进程和注册表改动；这些迹象有助于判断，但不能单独证明文件恶意或安全。

5. 结束后清理

   • 关闭沙盒内所有程序，使用 Sandboxie 的 删除/清空沙盒内容 功能，而不是只删除安装包。
   • 不要把沙盒中生成的程序、脚本、文档或快捷方式恢复到真实系统，除非经过独立验证。
   • 如果测试时曾授予管理员权限、允许访问真实文件，或出现异常，建议断开网络并用可信安全软件进行完整扫描。

对高风险文件，最稳妥的做法是在一次性虚拟机里测试，并在测试前创建快照；不要在存有个人资料的日常电脑上直接运行。

用 Sandboxie 隔离公共电脑上的浏览痕迹

Sandboxie（建议使用 Sandboxie-Plus）可以把浏览器运行在一个受限环境中。关闭或清空沙箱后，沙箱内的缓存、Cookie、历史记录等通常会一并删除，减少它们留在 Windows 用户配置文件中的机会。

但它不是匿名工具，也不能保证公共电脑上不留下任何痕迹：网络管理员仍可能看到访问记录；系统监控、键盘记录、屏幕截图、恶意软件或管理员权限都可能绕过它。请遵守电脑所属机构的使用规定，不要用它规避管理或访问限制。

基本操作

1. 确认环境允许

   • 只在允许安装或运行 Sandboxie 的电脑上使用。
   • 公共电脑若禁止安装软件，不要尝试绕过限制；可改用自己的设备和网络。

2. 安装并创建沙箱

   • 从 Sandboxie-Plus 官方渠道获取软件，检查安装来源。
   • 新建一个沙箱，例如命名为“临时浏览”。
   • 默认隔离设置通常足以用于一般网页浏览；不要随意启用允许程序访问沙箱外文件、注册表或设备的选项。

3. 在沙箱内启动浏览器

   • 在 Sandboxie-Plus 中选择沙箱，使用“运行程序”或“运行网页浏览器”，启动浏览器。
   • 确认浏览器窗口显示为沙箱进程（Sandboxie 通常会用边框或窗口提示标识）。
   • 不要从未隔离的普通桌面浏览器继续操作，也不要把个人密码保存到浏览器中。

4. 浏览时注意

   • 不要下载并打开来源不明的文件。沙箱可以限制部分影响，但不能保证文件安全。
   • 如需保存文件，保存到沙箱内；完成后确认是否需要取回。取回文件会把它写到沙箱外，文件名、内容或最近使用记录可能因此留在系统中。
   • 避免登录高度敏感的账号；公共电脑可能存在看不见的监控软件或硬件记录设备。
   • 不要依赖隐私浏览模式替代沙箱：隐私模式通常只减少浏览器本地保存，不隔离程序对系统的访问。

5. 结束后清理

   • 先退出浏览器，并确认相关浏览器进程已关闭。
   • 在 Sandboxie-Plus 中选择该沙箱，使用“删除内容 / 清空沙箱”之类的功能，并确认清理完成。
   • 如果登录过账号，最好先正常退出账号；但这不能消除网络端或监控系统已有的记录。
   • 不要只删除浏览器历史记录：Cookie、缓存、下载内容和浏览器配置也可能残留在沙箱中。

需要了解的边界

Sandboxie 主要隔离本机上的文件、注册表和部分进程操作。它通常不能隐藏：

• 访问过的网站、IP 地址、DNS 请求或网络流量；
• 公共电脑管理员的系统日志、网络监控和安全软件记录；
• 屏幕内容、键盘输入或被恶意软件收集的信息；
• 你主动保存到沙箱外的文件，以及登录服务端留下的记录。

因此，较稳妥的做法是：不在公共电脑上处理敏感账号或资料，使用自己的设备；确实需要临时浏览时，再用独立沙箱并在结束后清空。

要阻止沙盘内程序提权，重点是不给它多余权限，并让沙盘边界由多个独立机制共同保护。沙盘并非绝对安全：若程序利用了内核或虚拟机监控器漏洞，仍可能逃逸，因此系统更新和隔离方式同样重要。

通用做法

• 使用独立的低权限账号运行，不要以管理员、root 或服务账号启动；避免授予 sudo、管理员组或类似权限。
• 遵循最小权限原则：只开放程序必需的文件、目录、网络和系统接口；不要把宿主机敏感目录、凭据、套接字或设备映射进沙盘。
• 限制特权接口：关闭不需要的设备访问、挂载、调试、进程注入和管理接口；在 Linux 上可结合 seccomp、Linux capabilities、user namespace、AppArmor 或 SELinux。
• 启用强制访问控制，而不只是依赖文件权限。策略应限制程序能访问的文件、系统调用、进程和网络资源。
• 避免共享高权限通道：例如让沙盘程序通过一个以管理员权限运行的辅助服务执行任意命令。若必须有辅助服务，应限定可调用的操作并严格校验输入。
• 及时更新宿主机、内核、容器运行时和沙盘软件，并移除不必要的软件与内核模块。
• 限制资源并监控异常行为：设置 CPU、内存、进程数和网络限制；记录权限变更、异常进程及对敏感文件的访问。
• 对不可信程序使用虚拟机或专用主机。容器通常共享宿主机内核，隔离强度低于虚拟机；高风险样本应考虑一次性虚拟机、快照回滚和禁用共享剪贴板/文件夹。

Linux 容器的重点检查项

确保容器不是特权容器；不要挂载宿主机的 /、Docker socket 或敏感设备；以非 root 用户运行；删除不需要的 capabilities；启用 seccomp 和 AppArmor/SELinux；限制可写目录。不要仅因为进程显示为容器内的 root 就认为它安全。

Windows 沙盒的重点检查项

使用标准用户运行程序，启用 Windows Sandbox、AppContainer 或受控文件夹访问等合适机制；不要向程序授予管理员权限，也不要共享包含凭据的目录或管理接口。对高风险程序，优先使用一次性虚拟机。

如果你告诉我使用的是 Windows、Linux、Docker、虚拟机还是某个具体沙盒软件，我可以给出对应的配置检查清单。

在沙盘中分析病毒样本时，安全边界应以“样本即使逃逸，也无法接触真实网络、数据或设备”为目标：

• 使用专用隔离环境：优先采用专用分析主机或独立虚拟化环境；不要在日常办公电脑、生产服务器或含有敏感资料的设备上运行样本。
• 严格限制网络：默认断网。确需观察网络行为时，使用隔离的模拟网络或受控实验网，禁止连接企业内网、家庭局域网及真实互联网。
• 关闭宿主机通道：禁用共享文件夹、剪贴板、拖放、USB 直通和不必要的虚拟设备；不要把宿主机目录映射给虚拟机。
• 使用快照并减少持久性：运行前创建干净快照，分析后回滚或销毁环境；不要在分析环境中保存真实账号、密钥或个人文件。
• 隔离样本与产物：样本及其生成文件应放在受控存储中，避免通过邮件、网盘或普通共享目录传递。不要在隔离边界之外打开可疑文件。
• 控制访问与操作：仅由获授权人员在有记录的流程中分析；使用非管理员账户，并限制样本、虚拟机及日志的访问权限。
• 准备应急措施：确认如何立即断开虚拟网络、暂停或关闭虚拟机，并监控宿主机和网络异常。分析结束后检查宿主环境，必要时重新构建。
• 不要把沙盘视为绝对安全：虚拟机逃逸、配置错误和恶意利用都可能突破隔离。高风险样本应使用专用实验设备和经审查的隔离方案。

如果只是观察行为，优先使用信誉良好的离线分析工具或受控沙盘，不要为“测试效果”解除隔离限制。

对比“沙盘内”和“沙盘外”的浏览器性能，关键是只改变沙盘这一项，其余条件尽量一致，并重复测试。否则浏览器版本、扩展、缓存或网络差异都可能掩盖结果。

建议的测试流程

1. 统一环境

   • 同一台设备、操作系统、电源模式和网络。
   • 同一浏览器版本、启动参数、扩展、页面和用户配置。
   • 分别使用干净且相同的配置文件，避免缓存和历史数据造成偏差。
   • 测试期间关闭其他高负载程序。

2. 测试多个方面

   • 启动与页面加载：冷启动、热启动、页面加载时间。
   • JavaScript 与渲染：用 Speedometer、JetStream 等基准测试。
   • 图形性能：测试 WebGL、动画帧率或图形基准。
   • 资源占用：记录浏览器进程的 CPU、内存、磁盘和 GPU 占用。
   • 实际工作负载：例如打开常用网站、滚动长页面、播放视频、运行 Web 应用。

3. 重复并记录结果

   • 每种模式先运行几次预热，再正式测试至少 5 次。
   • 交替测试顺序，例如“沙盘内、沙盘外、沙盘外、沙盘内”，减少温度和后台负载的影响。
   • 记录中位数和波动范围；不要只比较单次最快成绩。

可用浏览器开发者工具的 Performance 面板观察加载、脚本执行和渲染时间；操作系统任务管理器或 top/htop 可记录资源占用。测试页面加载时，尽量使用本地页面或固定网络环境，避免网速波动影响结果。

注意事项

如果这里的“沙盘”指浏览器的安全沙箱，不要为了测试而随意关闭沙箱，尤其不要在日常浏览或处理不可信网页时这样做。关闭沙箱会降低安全性；而且沙箱可能增加少量进程和内存开销，实际性能差异往往需要通过具体工作负载测量，不能只凭单一基准判断。

如果你指的是在 Playwright 沙盘环境里并行运行多个浏览器实例，可以按下面配置。每个 worker 启动一个独立浏览器进程；同一浏览器内也可以用多个 BrowserContext 隔离会话。

// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  testDir: './tests',
  fullyParallel: true,
  workers: 4, // 并行 worker 数；通常不超过可用 CPU 核数
  use: {
    headless: true,
    browserName: 'chromium',
  },
});

容器中运行时，建议使用 Playwright 官方镜像，并为 Chromium 分配足够的共享内存：

docker run --rm \
  --shm-size=1g \
  -v "$PWD:/work" -w /work \
  mcr.microsoft.com/playwright:v1.51.0-noble \
  npx playwright test

如果是在自己的 Node.js 脚本中启动多个实例：

import { chromium } from 'playwright';

const browsers = await Promise.all(
  Array.from({ length: 3 }, () =>
    chromium.launch({ headless: true })
  )
);

try {
  // 每个 browser 是独立进程；context 用于隔离 cookie、缓存和页面
  const contexts = await Promise.all(
    browsers.map(browser => browser.newContext())
  );
  // 在各 context 中创建页面并执行任务
} finally {
  await Promise.all(browsers.map(browser => browser.close()));
}

建议根据内存和 CPU 调整实例数；浏览器实例过多会导致内存不足或测试变慢。通常优先增加 BrowserContext，只有需要独立进程或不同浏览器配置时才增加浏览器实例。生产或 CI 环境尽量不要使用 --no-sandbox；如果沙盘本身限制了 Chromium 启动，再根据具体运行环境处理。

如果你使用的不是 Playwright（例如 Puppeteer、Selenium 或某个云端沙盘），请告诉我框架和运行方式，我可以给出对应配置。

如果你说的 BlockDrivers 是“阻止驱动程序加载”的功能，它在测试未知程序时主要用于降低风险：防止程序安装或加载内核驱动，从而减少其获取高权限、直接访问硬件、持久驻留或导致系统崩溃的机会。

但这也可能影响测试结果：若程序本来就依赖驱动，拦截后可能无法正常运行，导致行为分析不完整。因此通常应在隔离的虚拟机或沙箱中测试，并把驱动拦截视为安全措施，而不是完整的隔离手段。若你指的是某个具体产品里的 BlockDrivers，请提供产品或界面名称。

测试绿色软件时，沙盘运行和直接运行的主要区别是：软件对系统的改动是否被隔离。

怎样测试更合适

• 先用沙盘初步检查：看软件能否启动、主要功能是否正常，以及它尝试创建或修改哪些文件、注册表项。
• 再用虚拟机或专用测试电脑验证：如果要确认它是否真的无需安装、是否会留下配置和卸载残留，这比沙盘更可靠。
• 不要只凭沙盘结果判断“绿色”：沙盘可能隐藏了软件对真实系统的写入，甚至让某些功能失效。
• 谨慎直接运行来源不明的软件：直接运行可能带来持久性改动；重要测试最好在虚拟机快照中进行。

简单说：沙盘适合安全地初筛，直接运行更能观察真实影响；要兼顾安全和准确性，优先用可回滚的虚拟机测试。

有可能，取决于浏览器运行在哪个沙盒里，以及沙盒的配置。

浏览器的自动更新通常需要更新程序或后台服务访问网络、写入浏览器安装目录，并在必要时创建计划任务或更新服务。沙盒可能会：

• 隔离浏览器写入的文件，导致更新只存在于沙盒中；清空沙盒后更新可能消失。
• 阻止更新程序访问网络、系统服务、计划任务或受保护的安装目录。
• 让浏览器显示更新失败，或反复提示需要重启、重新更新。

如果浏览器和更新程序都在沙盒外运行，通常不受 Sandboxie 影响。若浏览器在沙盒内运行，建议检查 Sandboxie 的拦截日志和沙盒设置；也可以退出沙盒后手动更新。不要为了更新而随意放宽整个沙盒的权限，尤其是浏览器用于访问不可信网站时。