再谈杀软性能测试

在安全产品的性能评测报告中，目前最为广泛采用的是 AV-Comparatives 与 AV-TEST。它们在标准硬件上执行文件复制、压缩解压、应用安装启动、网页浏览等日常操作，区分首次与后续运行，取多次测试的中位数，并在每次测试前还原系统镜像。AV-Comparatives 还引入了 UL Procyon 办公基准套件作为第三方参照。这套体系主要面向消费者场景，衡量的是”安装杀软后日常操作的放缓程度”，其结论直观且具有显著的参考价值。

然而，性能测试本身是一项复杂的工程。熟悉手机评测的人可能对此深有体会：跑分软件的排名年年变化，厂商针对特定基准测试进行优化已非秘密，而单纯的 Geekbench 分数可能无法反映日常使用的流畅度。杀软评测面临同样的问题：选定的工作负载直接决定了结论的适用范围。AV-Comparatives 测试的是”复制文件、安装软件、启动 Office”，其结论自然仅适用于这些场景；一旦变更场景（例如代码编译），排名完全可能逆转。因此，”某款杀软在 AV-TEST 中排名第一”并不等同于”它不会拖慢你的 Rust 构建速度”。

此外，上述测试场景均以完整的应用操作为单位，虽然能给出整体延迟数据，却无法定位延迟的具体来源——究竟是 minifilter 回调开销、云信誉查询，还是对新建可执行文件的深度扫描？这对开发者而言尤为关键。编译过程会在短时间内触发数十万至数百万次文件系统操作（包括打开文件、查询元数据、读取依赖、写入中间产物及最终二进制文件），每次操作都可能被杀软的内核驱动或用户态 Hook 拦截。编译器还会执行杀软最为敏感的行为——写入可执行代码。与此同时，vibe coding 的兴起正在把”写代码、编译、运行”这一循环从专业开发者扩展到越来越多的普通用户，构建频率随之提高；包生态系统（NuGet/npm/Cargo）也在不断扩张，但传统评测仍以”复制数 GB 文件”来代表 I/O 压力，这与编译工作负载的特征（海量小文件元数据查询加新建可执行产物）存在本质差异。此类场景在现有测试体系中的缺失，构成了一个显著的盲区。

测试计划

我搭建了一套测试环境，设计了两条互补的测试线：

编译工作负载（2个测试项）。 我选取了 ripgrep（Rust/Cargo 原生构建）与 Roslyn（.NET/MSBuild 托管构建），各执行全量与增量编译。二者的文件系统访问模式截然不同：ripgrep 路径少（约 3,400 条唯一路径）但写入密集，产物以 PDB、导入库及链接器原生输出为主，检验的是杀软对原生可执行产物创建的处理能力；Roslyn 路径极多（约 15.4 万条），元数据查询密集——MSBuild 项目求值、SDK/NuGet/引用程序集遍历、编译器服务器读取，检验的是杀软在海量文件路径遍历时的每次打开/查询开销。两者恰好覆盖”编译”家族中压力形态截然不同的两极。

微基准（20个测试项）。 将杀软可能介入的系统调用逐一拆分测量，涵盖文件系统（创建删除、压缩包解压、目录枚举、硬链接与 junction）、可执行内容处理（按 .exe/.dll/.js/.ps1 扩展名写入相同内容以测试扩展名敏感性、写入 PE 格式内容、加载 DLL、运行全新可执行文件以及附加 MOTW 标记后的差异）、进程与线程（进程创建、线程创建）、内存（保护属性 RW→RX 翻转、文件映射）、网络（环回连接、DNS 解析）、注册表读写、命名管道、签名验证，以及 COM 实例化。每场景执行 50–50,000 次操作，主要采集总耗时（wall time）与相对基线的性能损耗百分比，同时记录 CPU 时间和变异系数用于稳定性评估。具体关注哪些场景取决于工作流：CI/CD 可重点看进程创建与文件写入，前端看目录枚举与 .js 扩展名敏感性。

测试环境基于 VM 快照。虚拟机配置为 24 vCPU、16 GB RAM，运行 Windows 10 22H2（NT 10.0.22621.0）。工具链在快照内预装完毕：Rust 1.85.0、.NET SDK 8.0.303、Visual Studio Build Tools 2022（18.5）及 Windows SDK 10.0.26100.0。基线环境（无杀软）与 16 款待测产品各执行五轮，每轮开始前由外部调度脚本还原至同一干净快照，确保每次运行的起始状态完全一致。执行顺序上，微基准优先于编译场景以确保延迟敏感的测量在系统最稳定时进行；微基准场景之间冷却 10 秒，编译场景之间冷却 20 秒，留出时间让杀软的后台活动（扫描缓存写入、云信誉回调等）结束。每次测试开始前，系统会连续 3 秒采样 CPU 占用率，若平均值超过 20% 则中止运行，以排除后台扫描干扰。编译工作负载在 Windows Job Object 内执行，可精确采集整个进程树的用户态/内核态 CPU 时间与峰值内存；微基准则在进程内运行，使用 QueryPerformanceCounter 级别的 Stopwatch 计时并记录逐操作延迟直方图（p50/p95/p99/max）。所有场景还通过 PerformanceCounter 快照采集全系统磁盘读写量，以捕获杀软服务进程在 Job Object 之外产生的 I/O 开销。每次运行均记录完整 manifest（包括仓库 SHA、工具版本、文件路径哈希等），确保结果可复现、可审计。

受篇幅所限，本文仅展示各场景的均值相关指标（稳态均值耗时与相对基线的增幅百分比）。完整的统计数据——包括中位数、首次运行冷启动耗时、CPU 时间分解、峰值内存、尾部延迟百分位（p50/p95/p99/max）、变异系数及全系统磁盘 I/O 等——均可在 GitHub 仓库 中查阅。

测试产品

产品名称	版本	设置
360 Total Security	11.0.0.1314	默认**
Avast	26.3.10886g (build 26.3.10886.978)	CyberCapture 关闭*
小红伞	1.1.115.3317	默认
比特梵德	27.0.58.324	默认
Dr.Web	12.0	默认
Emsisoft	2026.1.0.12700	默认
ESET	19.1.12.0	默认
G DATA	25.5.20	默认
火绒	6.0.9.3	默认
卡巴斯基	21.25.7.504	默认
Malwarebytes	5.5.4.252	默认
迈克菲	1.38.166.1	默认
Microsoft Defender	4.18.26030.3011	默认
Sophos	2024.3.3.1.0	默认
腾讯电脑管家	18.0.29988.215	默认
趋势科技	17.9.1161	默认

* Avast 的 CyberCapture 功能须关闭，否则测试程序无法正常完成。关闭该功能可能降低了 Avast 的实时防护开销，因此其性能数据仅供参考。

** 此处测试的是 360 Total Security（国际版）而非 360 安全卫士（国内版）。后者的云端 QVM 引擎会将测试编译产物误报为病毒并直接删除，导致测试无法完成，故以国际版替代。

ripgrep 编译测试

ripgrep 是一款用 Rust 编写的高性能文本搜索工具，其 cargo build --release 过程涉及约 3,400 条唯一文件路径，产物包括 PDB、导入库及链接器原生输出，属于路径数量适中但写入密集的典型原生编译场景。Process Monitor 跟踪显示，ripgrep 全量构建产生约 20.2 万个核心文件系统事件，活动高度集中在 cargo.exe 编排、多个 rustc.exe crate 编译、MSVC link.exe 链接及构建脚本执行上。从杀软的视角来看，这构成了一道极为聚焦的原生构建考题：可信的开发工具在短时间内密集产出 PDB、导入库、Rust 元数据（.rmeta/.rlib）和最终可执行文件——路径虽不多，但每一条都直接触发杀软对新建原生产物的扫描与信誉判断逻辑。

测试设置了全量构建与增量构建两个子场景。全量构建在删除 target/ 目录后从零开始，主要检验杀软对大量新建中间产物和最终可执行文件的处理开销；增量构建则基于已有产物仅 touch 一个源文件后重编译，侧重衡量杀软在少量文件变更时的额外开销——理想情况下，增量构建的杀软开销应当远小于全量构建，因为需要扫描的新文件数量大幅减少。

先看云端冷启动的情况。所谓云端冷启动，是指杀软尚未积累任何云端信誉与本地缓存时的首次运行。每次运行前重置虚拟机以移除本地缓存，因此首次构建可能触发杀软的云端查询与信誉评估流程，反映的是”全新环境下第一次构建”的真实体验。

全量构建中，绝大多数产品的冷启动增幅落在 12%–36% 之间。火绒（12.7%）、卡巴斯基（13.7%）、Malwarebytes（14.1%）、Emsisoft（14.2%）表现最佳，均控制在 15% 以内；ESET（17.1%）至 G DATA（27.0%）构成 17%–27% 的中间梯队；趋势科技（31.1%）和腾讯电脑管家（36.1%）接近或超过三成。迈克菲（261.6%）和小红伞（756.7%）则大幅偏离主群体，图中以红色断轴标注；二者的变异系数均较高（标记为噪声偏高），表明首次运行时的云端查询或深度扫描不仅开销显著，而且波动较大。增量构建方面，各产品增幅普遍收窄至个位数——ESET 仅 0.9%，迈克菲 1.6%，火绒 2.4%——由于需要扫描的新文件极少，增量构建的额外开销被大幅摊薄。G DATA（15.8%）和 Sophos（13.0%）则是例外，这暗示即使新增文件很少，其对非新建文件的元数据查询或进程监控仍会产生可观的开销。

接下来看所有运行的平均耗时增幅。这一指标剔除了首次运行的冷启动波动，更能反映日常重复构建的稳态体验。

整体排名与冷启动基本一致。Malwarebytes（11.5%）和火绒（11.9%）在全量均值中表现最佳；ESET 全量 17.3%，但增量仅 0.1%，是增量场景下的标杆。迈克菲均值从冷启动的 261.6% 回落至 179.4%，说明部分开销具有首次运行的一次性特征；而小红伞从 756.7% 反而升至 861.3%——均值比冷启动更高，说明其扫描开销在重复构建中持续存在，并非仅限于冷启动阶段。

Roslyn 编译测试

Roslyn 是 .NET 编译器平台，其解决方案 Roslyn.slnx 包含数百个项目，dotnet build -c Release /m /nr:false 构建过程涉及约 15.4 万条唯一文件路径。MSBuild 项目求值、SDK/NuGet/引用程序集遍历、VBCSCompiler.exe 编译器服务器读取共同构成了极为密集的元数据查询负载。Process Monitor 跟踪显示，Roslyn 全量构建产生约 1,260 万个核心构建事件——是 ripgrep 的 63 倍——其中文件操作占比高达 77.9%，以 CreateFile、QueryOpen、QueryDirectory 和 QueryNetworkOpenInformationFile 为主。这并非简单地”编译大量 .cs 文件”：在真正开始编译之前，MSBuild 就已经对文件系统发起了反复追问——这个文件是否存在？哪个 target 生效？哪个引用胜出？输出是否已过期？与 ripgrep 相比，Roslyn 的产物以托管程序集（.dll）而非原生可执行文件为主，路径数量高出一个数量级以上，压力形态从”写入密集”转向”打开/查询密集”——它考验的并非杀软对原生产物创建的扫描效率，而是在面对海量文件访问时，能否将每次打开/查询的 minifilter 回调开销控制在低水平。

同样设置全量构建与增量构建两个子场景。全量构建在删除 artifacts/bin 与 artifacts/obj 后从零开始，增量构建则 touch 一个 C# 源文件后重编译。构建命令通过 /nr:false 禁用 MSBuild 节点重用，确保每次测量都经历完整的进程启动流程。

先看云端冷启动的表现。

Roslyn 的冷启动分布与 ripgrep 呈现出截然不同的格局，排名发生了显著逆转。全量构建中，360 Total Security（-0.3%）和火绒（2.6%）几乎无感，迈克菲（4.1%）、Avast（5.1%）、腾讯电脑管家（5.1%）也控制在 5% 左右——这些产品在 ripgrep 上的开销显著更高，说明其 minifilter 对托管程序集的敏感度远低于原生 PE 文件。另一方面，ESET（27.6%）和卡巴斯基（33.2%）在 ripgrep 中分别仅为 17.1% 和 13.7%，在 Roslyn 上反而更高，表明它们在海量路径遍历下的每次打开/查询开销更为突出。Dr.Web（59.7%）明显拉开差距；Sophos（144.3%）和小红伞（175.0%）在这一规模的托管构建上存在显著瓶颈。增量构建方面，大部分产品收窄至 2%–20%，但 Emsisoft（24.1%）、G DATA（20.5%）和 Sophos（80.8%）仍然较高。

接下来看均值增幅。

均值数据延续了冷启动的趋势。Avast（2.4%）、360 Total Security（2.6%）、迈克菲（3.8%）、火绒（3.9%）和腾讯电脑管家（3.9%）在全量均值中几乎无感——这恰好印证了前述分析：对于 Microsoft SDK/NuGet 路径信誉积累充分、元数据 Hook 开销较低的产品而言，Roslyn 输入侧的大量已知内容可以走快速通道。ESET（22.2%）和 Microsoft Defender（24.2%）均超两成；Dr.Web（43.5%）意味着每次全量构建需要多等近一半的时间。小红伞均值从冷启动的 175.0% 大幅回落至 33.4%，首次运行的极端开销具有明显的一次性特征；Sophos 则以 134.2% 稳居末位，冷启动与稳态持平，说明其开销是持续性的。增量构建中，迈克菲（0.2%）和腾讯电脑管家（0.2%）几乎零开销；Sophos 增量均值仍达 80.8%。

微基准测试 - 文件创建/删除

编译工作负载给出的是端到端的整体开销，但无法定位到底是哪个系统调用路径被杀软拖慢了。微基准的作用正在于此：将杀软可能介入的 API 逐一拆开测量，让每条路径的开销无处遁形。

文件创建/删除是最基础的文件系统微基准。测试在进程内循环执行 5,000 次操作，每次操作的完整流程为：通过 .NET File.Create 创建一个临时文件（底层走 CreateFile + WriteFile），写入 64 字节内容，关闭流，再通过 File.Delete（底层走 DeleteFile）删除该文件。操作以 100 个一组进行批处理，计时覆盖从创建到删除的完整周期。这一场景直接对应编译过程中最高频的文件系统行为——中间产物的反复创建与清理，也是杀软 minifilter 回调最密集的触发路径之一。

基线环境下 5,000 次操作的平均耗时约 1,479 毫秒。迈克菲以 6.5% 的增幅表现最佳，几乎不增加额外开销；Avast（23.9%）同样控制在较低水平。Microsoft Defender（52.1%）、卡巴斯基（53.2%）、火绒（62.3%）、腾讯电脑管家（68.2%）和小红伞（73.7%）构成 50%–74% 的中间梯队，意味着每次文件创建/删除的平均延迟增加了大约一半到四分之三。ESET（96.5%）接近翻倍。从 360 Total Security（123.7%）开始进入高开销区间：Emsisoft（164.1%）、G DATA（191.2%）、Sophos（194.5%）和 Dr.Web（207.6%）均超过基线的两倍。Malwarebytes（253.9%）和比特梵德（324.0%）在这一场景下的开销尤为突出——后者基线下约 1.5 秒完成的操作需要 6.3 秒。趋势科技以 751.0% 的增幅位居末位（图中红色断轴标注），5,000 次操作耗时从 1.5 秒飙升至 12.6 秒，说明其 minifilter 在每次 CreateFile/DeleteFile 调用上施加了极其显著的额外开销。

值得注意的是，这一排名与编译工作负载的结果存在明显差异。例如 Malwarebytes 在 ripgrep 全量构建中仅增加 11.5%，但在文件创建/删除微基准中高达 253.9%；比特梵德在 Roslyn 全量构建中为 17.4%，文件创建/删除却达 324.0%。百分比的落差根源在于编译本身是 CPU 密集型工作：微基准测的是纯 I/O 操作，杀软延迟即全部延迟；而编译总耗时中解析、类型检查、优化、代码生成等 CPU 计算才是大头——即使杀软在每次文件创建上施加了相同的绝对延迟，它在编译总耗时中占比也会小得多。此外，Cargo 和 MSBuild 均支持多核并行构建，杀软在一个核心上扫描某个输出文件时，其他核心仍在执行编译，I/O 延迟与 CPU 计算在时间上大量重叠，进一步压缩了百分比增幅。这正是设计两条互补测试线的价值：编译工作负载给出端到端的真实体验，微基准则剥离了 CPU 计算的掩盖效应，直接暴露特定 API 路径上的原始代价。

微基准测试 - 压缩包解压

压缩包解压测试通过 .NET ZipFile.ExtractToDirectory 将一个预先生成的 zip 包解压到独立目录，随后递归删除该目录，共执行 10 轮。zip 包内含 2,000 个确定性随机文件，扩展名在 .cs、.js、.json、.xml、.dll、.exe、.txt、.md 之间循环，大小从 64 字节到 64 KB 不等，其中 .dll 和 .exe 条目以 MZ 开头以模拟可执行内容。这一场景模拟的是包管理器还原、安装程序解包等批量文件创建/写入/删除的突发行为，压力介于单文件创建/删除与完整编译构建之间。

迈克菲（3.1%）依然是开销最低的产品，Avast（13.5%）和卡巴斯基（15.9%）同样控制在较低水平。Dr.Web（22.2%）、ESET（23.6%）和小红伞（23.8%）处于 22%–24% 的窄幅区间。腾讯电脑管家（42.0%）和火绒（42.6%）接近一半，Microsoft Defender（54.5%）超过一半。从 360 Total Security（79.1%）开始进入高开销区间，Emsisoft（116.4%）、Sophos（137.4%）、G DATA（155.3%）和 Malwarebytes（211.5%，5 轮中有 2 轮因 Malwarebytes 对解压文件持有扫描锁导致清理失败，报告数据基于 3 轮成功结果）依次攀升。趋势科技（428.2%）和比特梵德（463.9%）位居末位——解压 2,000 个文件的耗时从基线约 13 秒飙升至 70 秒以上，说明二者对批量新建文件（尤其是包含可执行内容的条目）施加了极重的逐文件扫描开销。

微基准测试 - 大目录枚举

大目录枚举测试预先创建一个包含 10,000 个文件的目录（文件大小 256 字节，扩展名在源码、脚本、配置、可执行和文本类名称间循环），然后通过 .NET Directory.EnumerateFiles（底层走 NtQueryDirectoryFile）对该目录执行 50 次完整枚举，每次验证枚举结果恰好为 10,000 个条目。目录创建在计时之外完成，计时仅覆盖枚举本身。这一场景直接对应 IDE 文件树刷新、源码管理状态检查、搜索/索引路径等大目录遍历行为。

迈克菲（2.7%）几乎无感，卡巴斯基（15.4%）和 Avast（18.9%）同样较低。Dr.Web（37.7%）和 ESET（43.1%）处于中等水平。腾讯电脑管家（54.6%）、小红伞（62.1%）、360 Total Security（84.1%）、Microsoft Defender（119.4%）和 Emsisoft（131.9%）依次递增——Microsoft Defender 在目录枚举上的开销超过一倍，值得开发者注意。火绒（153.5%）在这一场景下的排名明显后移，G DATA（185.7%）和 Malwarebytes（283.2%）超过两倍。Sophos（299.1%）接近三倍。趋势科技（649.4%）和比特梵德（745.6%）再次以断轴标注位居末位，10,000 文件目录的 50 次枚举从基线约 2.4 秒膨胀至 18–20 秒，说明二者的 minifilter 在目录枚举的每次回调中施加了极高的单次开销。

微基准测试 - 创建硬链接与目录联接

硬链接与目录联接（junction）是两种 NTFS 特有的文件系统对象类型，被包管理器、构建缓存和工作区工具广泛使用。硬链接测试通过 Win32 CreateHardLink P/Invoke 为同一个 4 KB 源文件创建 5,000 个硬链接并逐一删除；目录联接测试则通过 DeviceIoControl(FSCTL_SET_REPARSE_POINT) 创建 2,000 个 junction 并逐一删除。二者都涉及安全敏感的文件系统路径——硬链接改变引用计数，junction 通过 reparse point 改变路径解析行为——因此杀软可能对其施加额外的检查逻辑。

硬链接场景中，迈克菲（18.9%）表现最佳，Avast（37.2%）、ESET（42.5%）、小红伞（44.2%）和 Microsoft Defender（46.0%）处于 37%–46% 的中低区间。Dr.Web（53.4%）和腾讯电脑管家（81.4%）逐步攀升。Malwarebytes（105.6%）、火绒（130.4%）、Sophos（153.0%）和 360 Total Security（156.3%）超过一倍。Emsisoft（180.7%）、卡巴斯基（182.4%）、G DATA（216.2%）和比特梵德（249.1%）构成高开销区间——值得注意的是，卡巴斯基在硬链接场景下的排名大幅后移（文件创建/删除仅 53.2%，硬链接达 182.4%），说明其对 CreateHardLink 路径施加了比普通 CreateFile 更重的检查。趋势科技（504.9%）继续垫底。

目录联接场景的整体增幅低于硬链接，这可能与 junction 的操作次数较少（2,000 vs. 5,000）以及 reparse point 操作路径的差异有关。迈克菲（1.8%）几乎零开销，Dr.Web（12.7%）、ESET（18.3%）和 Microsoft Defender（21.6%）均控制在较低水平。火绒（41.3%）、腾讯电脑管家（46.2%）、小红伞（56.0%）、Sophos（60.8%）和 Avast（66.6%）构成中间梯队。卡巴斯基（68.9%）和 Malwarebytes（84.1%）接近或超过八成。Emsisoft（113.7%）和 G DATA（119.5%）超过一倍。比特梵德（166.7%）和趋势科技（241.3%）位居末位。360 Total Security 在此场景中运行失败（测试结果为 0），未纳入比较。

两个场景对比可见，硬链接普遍比 junction 触发更高的杀软开销——前者通过 CreateHardLink 创建新的目录条目指向已有数据，后者通过 reparse point 重定向路径。部分产品（如 Dr.Web）在 junction 上的开销远低于硬链接，暗示其对 reparse point 的处理采用了不同的过滤逻辑。

微基准测试 - 扩展名敏感度

扩展名敏感度测试是本套微基准中信息密度最高的场景之一。它将完全相同的 4 KB 随机内容分别以 .exe、.dll、.js、.ps1 四种扩展名写入并删除各 10,000 次——文件内容、大小、写入路径完全相同，唯一变量是扩展名。如果某款杀软对特定扩展名施加了更重的检查（例如对 .ps1 触发脚本内容扫描，对 .exe 触发 PE 头解析），那么同一产品在不同扩展名下的增幅差异将直接暴露这一行为。

迈克菲在四种扩展名下的增幅均在 2%–5%，几乎不区分扩展名。卡巴斯基（20%–30%）和 Avast（18%–36%，其中 .exe 子项有 1 轮因采集器异常失败，报告数据基于 4 轮结果）同样保持较低且相对均匀的开销。Microsoft Defender 在四种扩展名下表现一致（43%–47%），说明其文件写入路径上的检查逻辑不以扩展名为条件。

分化从中间梯队开始显现。火绒对 .exe（232.8%）和 .dll（259.9%）的增幅远高于 .js（56.3%）和 .ps1（60.7%），说明其引擎对可执行格式扩展名有明确的差异化处理。ESET 则呈现相反的模式：.exe（106.7%）和 .dll（102.4%）的开销反而低于 .js（157.1%）和 .ps1（159.7%），暗示其对脚本类扩展名施加了额外的内容检查。

最引人注目的是比特梵德和趋势科技。比特梵德对 .ps1 的增幅高达 4071.0%（图中红色断轴标注）——基线下约 3 秒完成的 10,000 次写入/删除操作飙升至 125 秒，而其 .exe（604.3%）和 .dll（638.1%）虽然也很高，但与 .ps1 相比差了一个数量级，说明比特梵德对 PowerShell 脚本文件触发了极为深入的内容分析。趋势科技对 .js（1935.9%）的增幅最为极端，.dll（1225.1%）和 .ps1（1260.5%）次之，.exe（767.8%）相对最低——这一模式表明趋势科技对脚本和库文件的检查强度甚至超过了可执行文件本身。Dr.Web 在四种扩展名下的增幅相对均匀（377%–399%），Malwarebytes 的 .js（584.8%）明显高于 .exe（443.7%），也呈现出脚本扩展名敏感性。

微基准测试 - 文件写入（PE 内容）

前面的扩展名敏感度测试使用的是随机内容，而文件写入测试进一步升级——写入的是真实的 PE 格式内容。测试在准备阶段编译一个无操作的 noop.exe，运行时将其字节读入内存作为模板，每次迭代在内存中修改偏移 0x40..0x43 处的 4 字节（DOS stub 填充区域）为当前迭代索引，使得每个写入文件拥有唯一哈希，然后通过 File.WriteAllBytes 写入磁盘并立即删除，共执行 10,000 次，交替使用 .exe 和 .dll 扩展名。这一设计绕过了杀软的扫描结果缓存（每个文件哈希唯一），直接测量的是杀软对”全新的、从未见过的可执行内容”的逐文件扫描代价。

基线约 3,299 毫秒完成 10,000 次写入/删除。迈克菲（1.0%）几乎无感。Avast（28.3%）、Microsoft Defender（42.5%）、卡巴斯基（48.4%）和小红伞（57.9%）构成低开销区间。腾讯电脑管家（62.2%）和 360 Total Security（108.9%）过渡至中间水平。Emsisoft（148.4%）和 Sophos（248.2%）接近或超过两倍。从比特梵德（471.9%）开始进入断轴区间：Malwarebytes（495.3%）、G DATA（973.4%）均为高开销。ESET（2602.1%）和趋势科技（2744.8%）的增幅令人瞩目——这两款产品在前面的扩展名敏感度测试（使用随机内容）中开销虽然也高，但远不及此处对真实 PE 内容的反应。Dr.Web（26066.9%）和火绒（31552.6%）以红色断轴标注位居末位，10,000 次写入从基线 3.3 秒飙升至数百秒。火绒在其他文件系统场景中一直表现优秀，却在 PE 内容写入上出现了极端开销，说明其引擎对可执行内容的实时扫描策略与单纯的文件创建/删除路径截然不同。

微基准测试 - 文件系统监视器

在真实的开发环境中，文件操作几乎不会在”干净”的目录下孤立执行——VS Code、JetBrains IDE、Vite/Webpack 的 watch 模式、热重载框架以及 OneDrive/Dropbox 同步客户端都会在工作目录上长期保持活跃的 FileSystemWatcher（底层走 ReadDirectoryChangesW）。目录上一旦存在活跃的变更监听器，文件系统在每次创建、写入、删除时，不仅要完成原始 I/O 操作，还需要维护目录变更通知缓冲区并唤醒用户态消费者——这部分工作并非零成本；若杀软的 minifilter 对相关文件 I/O 或目录控制操作注册了回调，其回调也可能在这些路径上被触发，从而带来额外开销，但其具体表现取决于实现细节。

测试在一个受监视的目录中执行 5,000 次文件操作，每次迭代的完整流程为：通过 File.WriteAllBytes 写入 64 字节内容，再通过 File.AppendAllText 追加一次写入，最后通过 File.Delete 删除该文件。FileSystemWatcher 注册了文件名和最后写入时间变更的通知回调（Created/Changed/Deleted），回调仅执行一次原子计数器递增，在线程池后台异步接收，不阻塞测量循环。计时覆盖完整的文件操作周期。

迈克菲（7.1%）再次表现最佳，卡巴斯基（23.0%）和 Avast（24.4%）同样较低。Microsoft Defender（58.9%）、腾讯电脑管家（66.6%）和火绒（74.8%）构成中间梯队。小红伞（85.3%）和 ESET（122.9%）接近或超过一倍。360 Total Security（127.2%）、Emsisoft（154.3%）、Dr.Web（154.4%）和 Malwarebytes（192.6%）依次攀升。Sophos（236.3%）和 G DATA（274.7%）超过两倍。比特梵德（778.7%）和趋势科技（817.5%）再次以红色断轴标注位居末位。对于在 IDE 中频繁保存文件、依赖 watch 模式进行增量构建或热重载的开发者而言，这一场景的数据比纯文件创建/删除更能反映日常体感。

微基准测试 - 进程创建/等待

进程创建/等待测试通过 .NET Process.Start（底层走 CreateProcessW，UseShellExecute=false）反复启动同一个预编译的 noop.exe，重定向标准输出/错误流，同步等待进程退出，共执行 500 次。这一场景测量的是杀软在进程创建路径上的拦截开销——包括映像加载通知（PsSetLoadImageNotifyRoutine）、进程创建回调（PsSetCreateProcessNotifyRoutine）以及可能的启发式/签名检查。对于编译工作负载而言，进程创建是核心操作之一：cargo 反复调用 rustc.exe，dotnet build 启动 MSBuild 节点和编译器进程。

这一场景的排名与文件系统微基准截然不同。Microsoft Defender（19.1%）表现最佳——在文件系统场景中通常处于中间位置的 Defender，在进程创建路径上的优化做得更到位。火绒（36.6%）、G DATA（37.5%）和小红伞（38.2%）紧随其后，均控制在 40% 以内。ESET（46.9%）、Dr.Web（50.3%）和腾讯电脑管家（55.4%）处于中间水平。迈克菲（63.5%）在这一场景下的排名反常地靠后——它在几乎所有文件系统微基准中都位居前列，但进程创建路径上的开销明显更高。Malwarebytes（67.8%）、趋势科技（86.3%）、Avast（87.9%）和 Emsisoft（92.8%）逐步攀升。卡巴斯基（106.8%）和 Sophos（108.8%）超过一倍。比特梵德（136.2%）居于高位，360 Total Security（222.6%）以断轴标注位居末位。

微基准测试 - 加载唯一 DLL

DLL 加载测试从 System32 目录复制一个系统 DLL（优先选择 urlmon.dll），为每次迭代生成唯一路径的副本，然后通过 Win32 LoadLibrary/FreeLibrary P/Invoke 加载并释放，最后删除副本，共执行 2,000 次。由于每次加载的 DLL 路径都是全新的，杀软无法利用路径缓存——它必须对每个”从未见过的 DLL 文件”执行完整的映像加载检查。这一场景直接对应构建过程中工具链加载、插件加载、分析器加载等行为。

DLL 加载场景的开销整体远高于其他微基准，大部分产品都超过了基线的数倍。Avast（6.2%）表现异常出色，几乎不增加额外开销。腾讯电脑管家（27.1%）、ESET（30.2%）和 360 Total Security（31.4%）也控制在较低水平。比特梵德（97.0%）接近翻倍——值得注意的是，比特梵德在文件创建/删除和目录枚举中通常排名靠后，但在 DLL 加载场景中的表现反而优于许多对手。从火绒（246.5%）开始进入高开销区间：小红伞（453.7%）、趋势科技（469.2%）、G DATA（481.8%）、迈克菲（501.5%）、Emsisoft（503.7%）密集聚集在 450%–504%。Microsoft Defender（598.1%）和卡巴斯基（609.5%）超过六倍。Sophos（732.3%）和 Malwarebytes（1556.1%）继续攀升。Dr.Web（4301.5%）以断轴红色标注位居末位——2,000 次 DLL 加载从基线约 8 秒飙升至 341 秒。迈克菲在此场景下的高开销（501.5%）与其在文件系统微基准中的一贯低开销形成鲜明反差，说明其对映像加载路径施加了比文件创建/删除路径重得多的检查逻辑。

微基准测试 - 线程创建

线程创建测试通过 .NET Thread.Start/Thread.Join 创建 5,000 个后台线程，每个线程执行空委托后立即 join。这一场景测量的是杀软对线程创建通知（PsSetCreateThreadNotifyRoutine）的处理开销——大多数杀软需要在线程创建时检查是否存在远程注入或 APC 注入行为。

线程创建是所有微基准中开销最低的场景之一，绝大多数产品的增幅在 10% 以内。火绒（0.4%）几乎零开销，Dr.Web（3.1%）、迈克菲（3.7%）、360 Total Security（3.7%）、腾讯电脑管家（3.8%）紧随其后。Microsoft Defender（6.1%）、ESET（6.6%）、Emsisoft（9.3%）、比特梵德（10.4%）和 G DATA（11.4%）均在低位。Sophos（22.4%）、小红伞（23.2%）和 Avast（26.2%）略高但仍属较低。Malwarebytes（54.0%）和趋势科技（59.8%）接近六成。唯一的异常值是卡巴斯基（148.6%），以红色标注位居末位——这一结果暗示卡巴斯基在线程创建回调中执行了比其他产品更重的检查逻辑，可能与其行为监控引擎对线程注入检测的实现有关。

微基准测试 - 新 EXE 运行序列

新 EXE 运行序列是本套微基准中最接近真实”首次执行未知程序”场景的测试。每次迭代的流程为：将预编译的 noop.exe 及其支持文件复制到一个全新目录，在磁盘上修改可执行文件偏移 0x40..0x43 处的 4 字节使其哈希唯一，然后启动该程序并等待退出，最后递归删除整个目录，共执行 50 次。图表展示的是两轮顺序执行的结果：第 1 次为冷启动（无 MOTW），第 2 次在第 1 次之后紧接着运行、添加了 Zone.Identifier 替代数据流（ZoneId=3，标记为网络下载来源）且不重置虚拟机——这使得第 2 次运行同时具备缓存已预热和 MOTW 标记两个条件，二者的对比可揭示杀软对首次/重复执行以及网络来源标记的差异化处理。

火绒（34.7%/32.1%）在两轮中均表现最佳且几乎无差异，说明其对新 EXE 的检查策略不因 MOTW 而改变。G DATA 冷启动 108.4%、缓存预热+MOTW 98.8%，略有改善。ESET 的变化最为显著：冷启动 173.6% 降至 MOTW 轮的 59.8%，说明 ESET 在首次见到未知可执行文件时施加了较重的扫描，但一旦缓存建立后开销大幅下降，MOTW 标记本身并未增加额外负担。Avast 呈现类似模式：冷启动 220.3% 降至 68.7%。Emsisoft（189.8%/191.1%）和 Sophos（410.5%/264.4%）在两轮间也有差异。360 Total Security（389.5%/386.0%）几乎不变。卡巴斯基（871.2%/168.8%）的反差极大——冷启动时的极高开销在缓存预热后大幅下降，说明其云端信誉查询在首次执行时产生了巨大延迟，但后续执行受益于本地缓存。比特梵德（634.1%/525.9%）在两轮中均处于高位。Microsoft Defender 呈现相反的模式——冷启动 167.3%，但 MOTW 轮飙升至 3342.4%（图中红色标注），说明 Defender 的未知文件上传机制对带有网络来源标记的未知可执行文件触发了极为严格的检查。迈克菲（2780.4%/2388.9%）和腾讯电脑管家（2463.7%/2437.7%）在两轮中均处于极高水平。小红伞（6631.8%/127.6%）的冷启动增幅最为极端，但 MOTW 轮大幅回落，暗示因其首次运行而触发APC云端上传是主要瓶颈。趋势科技在 MOTW 轮运行失败，未纳入该轮比较。

微基准测试 - 内存分配/保护

内存分配/保护测试通过 Win32 VirtualAlloc（MEM_RESERVE | MEM_COMMIT，PAGE_READWRITE）分配一个 4 KB 页面，在偏移 0 写入字节 0x41，随后调用 VirtualProtect 将保护属性切换为 PAGE_EXECUTE_READ，最后以 MEM_RELEASE 释放页面，共执行 50,000 次。注意测试从不使用 PAGE_EXECUTE_READWRITE——安全敏感的部分恰恰在于从可写到可执行的保护属性转换，这是 shellcode 注入的经典模式，杀软的行为监控可能会对此路径设置钩子。

这是所有微基准中分化最极端的场景之一：16 款产品中有 10 款的测量结果为 0.0%（或微小负值被截断为零），表明绝大多数杀软完全不拦截 VirtualAlloc/VirtualProtect/VirtualFree 的用户态调用路径。ESET（2.0%）和 Avast（13.9%）略有开销。Microsoft Defender（17.1%）和 Emsisoft（33.1%）开始显现可测量的影响。Sophos（51.2%）超过五成。趋势科技（132.4%）以红色标注位居末位，是唯一超过一倍的产品——说明趋势科技在内存保护属性变更路径上部署了比其他产品重得多的检查逻辑，可能通过内核回调或 ETW 跟踪了 PAGE_READWRITE 到 PAGE_EXECUTE_READ 的转换。

微基准测试 - 内存映射文件

内存映射文件测试通过 .NET MemoryMappedFile.CreateFromFile（底层走 CreateFileMapping/MapViewOfFile）反复映射同一个 4 KB 的零填充文件，以读写方式映射到内存，在偏移 0 写入一个字节后读回，然后释放映射和句柄，共执行 10,000 次。与普通的缓冲 I/O 不同，内存映射文件将文件内容直接映射到进程的虚拟地址空间，通过指针读写而非 ReadFile/WriteFile 调用——杀软的 minifilter 需要在 section object 创建和映射路径上进行检查，这与普通缓冲 I/O 走的是不同的内核路径。

迈克菲（5.5%）表现最佳，火绒（10.8%）和 Dr.Web（14.9%）紧随其后。Avast（15.1%）和卡巴斯基（34.1%）控制在较低水平。腾讯电脑管家（42.4%）、ESET（51.9%）、360 Total Security（54.0%）和 Emsisoft（58.3%）构成中间梯队。G DATA（89.3%）接近翻倍。Malwarebytes（115.8%）和 Sophos（116.6%）超过一倍。Microsoft Defender（137.4%）的排名靠后——在普通文件 I/O 场景中 Defender 通常处于中间水平，但在内存映射路径上的开销明显更高，说明其 minifilter 对 section object 的检查逻辑更重。小红伞（197.5%）、比特梵德（231.0%）和趋势科技（268.2%）依次位居末位，均以红色标注。

微基准测试 - 回环连接

回环连接测试通过 .NET TcpListener/TcpClient（底层走 Winsock WSASocketW、bind/listen/accept、WSAConnect、send/WSARecv）在 127.0.0.1 上执行完整的 TCP 连接/发送/接收/关闭周期：测试前启动一个本地回环 TcpListener，每次迭代创建一个新的 TcpClient（NoDelay=true），连接到服务端，发送 1 KB 随机 payload 并同步读回 1 KB 回显数据，然后释放连接，共执行 2,000 次。这一场景测量的是杀软对本地网络活动的拦截开销——许多杀软会在 Winsock 或 WFP（Windows Filtering Platform）层注册过滤器，检查连接目标和数据流。

Microsoft Defender（3.7%）在网络场景中表现最佳，几乎不增加开销。G DATA（9.9%）、迈克菲（11.6%）和火绒（12.8%）紧随其后。趋势科技（18.8%）和 360 Total Security（23.0%）控制在合理范围。Dr.Web（28.7%）和 Malwarebytes（28.9%）接近三成。腾讯电脑管家（37.7%）和卡巴斯基（49.9%）逐步攀升。小红伞（56.2%）和 Sophos（100.0%）分别突破五成和翻倍。Avast（113.5%）、比特梵德（156.1%）、Emsisoft（167.2%）和 ESET（171.8%）位居末位——ESET 在文件系统微基准中通常处于中间位置，但在网络连接路径上的开销却是最高的之一，暗示其 WFP 过滤器或网络检查模块对本地连接也执行了较重的分析。

微基准测试 - DNS 解析

DNS 解析测试通过 .NET Dns.GetHostAddresses（底层走 Winsock GetAddrInfoW）同步解析主机名 localhost，共执行 5,000 次。由于查询的是 localhost 而非互联网域名，这里测量的不是 DNS 网络延迟，而是杀软在本地解析器/缓存路径上的拦截开销——部分杀软会在 DNS 层部署过滤器以实现域名黑名单、DNS-over-HTTPS 重定向或网络威胁检测。

G DATA（0.0%）完全无开销，迈克菲（5.2%）和 ESET（5.7%）紧随其后。Microsoft Defender（9.8%）和趋势科技（11.7%）保持低位。Dr.Web（15.0%）、卡巴斯基（15.5%）和火绒（16.1%）处于中间水平。Avast（21.3%）、360 Total Security（24.3%）、比特梵德（28.5%）和腾讯电脑管家（29.8%）依次攀升。Sophos（46.1%）和 Malwarebytes（48.0%）接近五成。Emsisoft（71.3%）超过七成。小红伞（572.1%）以红色断轴标注位居末位，是唯一超过一倍的产品——5,000 次 localhost 解析从基线约 959 毫秒飙升至 6,438 毫秒，说明小红伞在 DNS 解析路径上部署了极为沉重的拦截逻辑，很可能与其”安全 DNS”功能将所有解析请求重定向至自有服务器有关。

微基准测试 - 注册表增删改查

注册表增删改查测试通过 .NET RegistryKey（底层走 Advapi32 RegCreateKeyEx/RegSetValueEx/RegQueryValueEx/RegDeleteTree）在 HKCU\Software\AvBench\Temp 下创建 5,000 个唯一子键，每个子键写入 5 种类型的注册表值（String、DWord、4 字节 Binary、3 项 MultiString、ExpandString），读回所有值，枚举值名称，关闭键句柄，最后递归删除该子键树。注册表操作是安装程序、组策略管理、系统配置工具的核心路径——杀软对注册表变更的监控（尤其是对 Run/Services 等自启动键的保护）可能在此场景中产生显著开销。

注册表场景的分化程度极为惊人，从迈克菲（21.3%）到 Emsisoft（2689.2%）跨越了两个数量级。迈克菲和 Microsoft Defender（30.7%）表现最佳。G DATA（52.5%）和 Dr.Web（56.3%）紧随其后。卡巴斯基（68.3%）、火绒（78.7%）和 ESET（81.4%）构成中间梯队。360 Total Security（104.8%）刚刚超过翻倍。腾讯电脑管家（127.0%）和 Malwarebytes（134.0%）继续攀升。从 Avast（288.7%）开始进入断轴区间——值得注意的是 Avast 的 CV 高达 49.8%，说明其测量值波动极大（可能存在间歇性的深度注册表扫描）。比特梵德（1067.2%）和小红伞（1137.5%）超过十倍。Sophos（1313.8%）和趋势科技（2137.1%）继续攀升。Emsisoft（2689.2%）以红色断轴标注位居末位——5,000 次注册表 CRUD 操作从基线约 452 毫秒飙升至 12.6 秒，说明 Emsisoft 对注册表变更路径施加了极为密集的行为监控钩子。

微基准测试 - 管道往返

管道往返测试通过 .NET NamedPipeServerStream/NamedPipeClientStream（底层走 CreateNamedPipe/ConnectNamedPipe 和管道句柄上的流式读写）测量稳态 IPC 延迟。测试前创建一对已连接的命名管道和一个专用回显服务线程，生成 4 KB 随机 payload 并执行 100 次不计时的预热往返。随后的 2,000 次测量往返中，每次向已连接的管道写入 4 KB payload 并同步读回 4 KB 回显数据——管道在整个测量过程中保持连接，不涉及每次迭代的管道创建或线程池开销。

管道往返与线程创建类似，是开销最低的场景之一。360 Total Security（0.0%）和腾讯电脑管家（0.0%）完全无开销。Microsoft Defender（1.3%）、小红伞（3.1%）和卡巴斯基（4.6%）几乎不可测量。趋势科技（8.4%）、迈克菲（8.9%）和 Malwarebytes（9.3%）控制在 10% 以内。Avast（10.4%）和火绒（11.0%）略高。ESET（13.5%）、G DATA（18.3%）、比特梵德（23.1%）和 Sophos（27.4%）逐步攀升但仍属较低。Emsisoft（28.7%）接近三成。唯一的显著异常值是 Dr.Web（99.6%），以红色标注位居末位——尽管其原始 CSV 中 CV 高达 57.7%（说明波动极大），但平均值仍接近翻倍，暗示 Dr.Web 在命名管道通信路径上可能存在间歇性的深度数据检查。

微基准测试 - 加密哈希校验

加密哈希校验测试通过 .NET SHA256.HashData 和 RSA.VerifyHash 执行纯计算型安全操作。测试前生成一个 64 KB 的随机 payload、一个 RSA-2048 密钥对和一个 PKCS#1 v1.5 SHA-256 签名。每次迭代对同一 64 KB payload 计算 SHA-256 哈希，然后用预计算的公钥和签名执行 RSA.VerifyHash，共执行 5,000 次。密钥生成和签名均在计时之外——测量的纯粹是哈希+验签的 CPU 计算路径。这一场景作为对照组存在：它不触发任何文件/进程/网络 API，理论上不应受杀软影响。

正如预期，加密哈希校验是所有微基准中开销绝对最低的场景。所有 16 款产品的增幅均在 8.2% 以内，且大部分在统计噪声范围内。G DATA（0.0%）和 Sophos（0.0%）完全无影响。ESET（0.1%）、小红伞（0.3%）和 Malwarebytes（0.5%）几乎为零。腾讯电脑管家（1.0%）、Dr.Web（2.4%）、趋势科技（2.9%）、卡巴斯基（3.5%）和 Avast（3.6%）保持低位。Microsoft Defender（3.6%）、360 Total Security（5.3%）、火绒（5.4%）和迈克菲（5.8%）略高但仍微不足道。Emsisoft（6.9%）和比特梵德（8.2%）位于末位但绝对值极低。这一结果确认了纯 CPU 计算路径几乎不受杀软拦截影响——杀软的性能代价集中在文件系统、进程创建、网络连接和注册表等 I/O 密集型 API 路径上。

微基准测试 - COM 实例创建

COM（Component Object Model）是 Windows 上历史最悠久、渗透最深的进程内/跨进程组件互操作机制。尽管现代应用程序很少直接编写 COM 组件，COM 激活仍然是大量日常操作的底层路径：Office 自动化与插件加载、Windows Shell 扩展（右键菜单、缩略图、预览处理器）、WMI 查询、DirectX/媒体基础设施、以及 MSI 安装程序事务均通过 CoCreateInstance 驱动。在开发者工作流中，Visual Studio 的设计器与项目系统、MSBuild 的部分任务、PowerShell 的 New-Object -ComObject 调用、以及脚本语言通过 Scripting.FileSystemObject 或 WScript.Shell 操控文件系统和注册表，都会触发 COM 实例创建。每次 CoCreateInstance 调用至少涉及一次注册表 CLSID 查询和一次 DLL 加载（若服务端尚未缓存），杀软可在这两个环节——注册表路径拦截与映像加载通知——施加检查；对于进程外（out-of-process）COM 服务器，还额外触发进程创建路径。因此，COM 激活延迟的测量实质上是对杀软在注册表查询、DLL 加载和对象创建这三条路径上综合拦截开销的端到端度量。

COM 实例创建测试通过 .NET Activator.CreateInstance 和 Marshal.FinalReleaseComObject 反复激活和释放 COM 对象。测试前将 ProgID Scripting.FileSystemObject 解析为 COM 类型。每次迭代实例化一个 FileSystemObject COM 对象（底层走 CoCreateInstance），验证返回的对象非空，然后调用 Marshal.FinalReleaseComObject 释放 COM 引用计数，共执行 5,000 次。COM 激活涉及注册表查询（CLSID 解析）、DLL 加载（加载 scrrun.dll）和进程内对象创建——这些路径都是杀软可能拦截的环节。

卡巴斯基（13.9%）表现最佳，Microsoft Defender（15.0%）和迈克菲（16.0%）紧随其后。ESET（33.4%）和腾讯电脑管家（36.2%）控制在较低水平。Avast（42.7%）和小红伞（53.2%）处于中间梯队。Dr.Web（56.6%）和 Malwarebytes（82.2%）逐步攀升。火绒（87.6%）接近翻倍——火绒在文件系统和进程创建场景中一直表现优异，但 COM 激活路径上的开销明显更高，可能与其对 Scripting.FileSystemObject 这类安全敏感 COM 对象的特殊处理有关。Emsisoft（162.4%）超过一倍半。360 Total Security（219.2%）和比特梵德（240.9%）超过两倍。趋势科技（294.9%）和 G DATA（301.0%）接近三倍。Sophos（430.6%）以红色标注位居末位——基线约 479 毫秒的 5,000 次 COM 激活被拉伸至 2.5 秒，说明 Sophos 在 COM 激活路径上施加了极为沉重的检查。

结果汇总

前面 22 个场景逐一剖析了每款杀软在特定 API 路径上的表现，但信息量过大——还需要一张全景图来快速定位每款产品的强项与短板，以及一个综合指标来回答”总体而言哪款杀软对性能影响最小”。为此我设计了两张汇总图表：一张热力图和一张严重度加权综合评分。

热力图

热力图将 16 款杀软 × 22 个场景的平均耗时增幅铺在一张表中，每个格子显示实际增幅百分比，颜色按该列（场景）内所有产品的数据进行对数归一化后映射到七个等级：本项最低、很低、低、中等、高、很高、本项最高。之所以选择对数而非线性归一化，是因为许多场景的产品间增幅跨越了数个数量级（如文件写入 PE 内容从 1% 到 31,552%），线性映射会导致大部分产品挤在同一色段中失去区分度。对数映射公式为 \(\text{score} = \frac{\ln(1 + v - v_{\min})}{\ln(1 + v_{\max} - v_{\min})} \times 100\)，然后将 0–100 的分数等分为 7 个等级。颜色归一化是按列独立进行的——同一颜色在不同列中代表不同的绝对增幅，这确保了每个场景内部的相对排名都能被清晰呈现。编译工作负载列采用全量构建 25%、增量构建 75% 的加权均值（日常开发以增量构建为主）；新 EXE 运行序列取无 MOTW 与有 MOTW 两轮中的较大值（反映最坏情况）；扩展名敏感度取 .exe、.dll、.js、.ps1 四种扩展名的平均值。

热力图最直观的观察是：没有任何一款产品在所有场景中都是最快的。迈克菲在文件系统微基准中几乎全线浅色（文件创建/删除 6.5%、压缩包解压 3.1%、文件写入 1.0%），但在 DLL 加载（501%）和新 EXE 运行序列（2,816%）中突然转为深紫色。火绒在进程创建（36.6%）和线程创建（0.4%）中表现优异，却在文件写入 PE 内容（31,552%）和扩展名敏感度（154%）中出现极端开销。卡巴斯基在文件创建/删除（53.2%）和压缩包解压（15.9%）中保持低位，但线程创建（148.6%）和 DLL 加载（609%）暴露了其在特定内核回调路径上的重检查策略。

纵向来看，各场景的分化程度差异极大。线程创建和加密哈希校验两列几乎全为浅色——前者说明大多数杀软对线程创建通知的处理非常轻量，后者确认了纯 CPU 计算路径不受杀软影响。与之形成鲜明对比的是文件写入 PE 内容、DLL 加载和注册表增删改查三列，深色区域占据大半——这些正是杀软需要执行内容扫描、映像检查或行为监控的核心路径。比特梵德和趋势科技在文件系统相关列中几乎全线深紫色，说明二者的 minifilter 在每次文件操作上施加的检查逻辑普遍较重。Sophos 的深色区域同样广泛但更分散，从注册表（1,314%）到 COM 实例创建（431%）均有显著开销。

综合评分

热力图提供了逐场景的详细视图，但仍然需要一个单一数字来排序。综合评分的设计目标是：单项严重变慢的产品应当受到比多项轻微变慢更重的惩罚——这与用户体验的直觉一致：一个场景慢 10 倍比十个场景各慢 10% 的影响更为显著。

为实现这一目标，评分采用了指数惩罚机制：将每款产品在每个场景中的热力图等级（0–6）转换为 \(2^{\text{level}}\) 的惩罚分——本项最低=1，很低=2，低=4，中等=8，高=16，很高=32，本项最高=64。这意味着从”低”到”高”的跳跃（4→16）比从”本项最低”到”低”的跳跃（1→4）在评分中的权重大得多。最终分数为所有场景惩罚分的均值乘以场景总数（22），若某款产品在部分场景中缺少数据（如测试失败），则按已有数据的均值估算缺失项，避免因数据缺失而获得虚假低分。

\[\text{总分} = \frac{\sum_{c \in \text{可用场景}} 2^{\text{level}_c}}{|\text{可用场景}|} \times 22\]

迈克菲以 242 分排名第一。腾讯电脑管家（271）和 ESET（272）紧随其后，差距极小。Avast（289）在文件系统微基准中的一贯低开销为其积累了优势。Microsoft Defender（337）和火绒（340）几乎并列——二者各有显著的单项弱点（Defender 的 MOTW 新 EXE 运行、火绒的 PE 内容写入），但在大多数场景中都控制在合理水平。卡巴斯基（364）和 360 Total Security（410）进入中间梯队。Dr.Web（441）和 G DATA（463）略高。Malwarebytes（544）和小红伞（570）因多个场景中的高开销而被拉高。Emsisoft（690）和 Sophos（737）的注册表、COM 等场景中的极端开销使其总分显著攀升。趋势科技（918）和比特梵德（933）位居末位——二者在文件系统相关场景中几乎全线高开销，多个场景触及本项最高（64 分惩罚），使得总分远超其他产品。

分级排名

参照 AV-Comparatives 的分级方式，基于综合评分将 16 款产品划分为四个等级。需要强调的是，本测试仅衡量性能开销，不涉及检出率、误报率等安全效能指标——安全产品的价值不能仅以性能论断。以下分级仅供参考：

等级	产品	分数区间
⭐⭐⭐ 影响较低	迈克菲、腾讯电脑管家、ESET、Avast	242–289
⭐⭐ 影响中等	Microsoft Defender、火绒、卡巴斯基、360 Total Security	337–410
⭐ 影响较高	Dr.Web、G DATA、Malwarebytes、小红伞	441–570
影响显著	Emsisoft、Sophos、趋势科技、比特梵德	690–933

第一梯队的四款产品在绝大多数场景中都将开销控制在较低水平，各自仅在少数场景中出现较高增幅。第二梯队整体表现良好但存在明确的单项弱点。第三梯队在多个场景中出现超过一倍的开销。第四梯队则在文件系统、注册表、COM 等核心路径上普遍产生数倍甚至数十倍的延迟。

与 AV-Comparatives 的对比

将上述排名与 AV-Comparatives 2026 年 4 月性能测试的结果并排对照，可以直观地看到工作负载差异如何逆转产品排名。两项测试的重叠产品中，部分排名高度一致：迈克菲在双方均位居第一（AVC Impact Score 3.3，本文 242），ESET 同列前三（AVC 4.2，本文 272），Avast 均处于低开销区间（AVC 5.5，本文 289），Sophos 在双方均靠近末位（AVC 33.4，本文 737）。然而，最引人注目的是两个方向相反的极端案例。

趋势科技在 AV-Comparatives 中排名第四（Impact Score 4.7），获得 ADVANCED+ 最高等级评价——文件复制、应用安装启动、网页浏览等子项几乎全线 Very Fast。但在本文的测试中，趋势科技以 918 分位居倒数第二：文件创建/删除 751%、目录枚举 649%、注册表 CRUD 2,137%、扩展名敏感度（.js）1,936%、文件写入 PE 内容 2,745%。比特梵德的反差同样显著：AVC 排名第九（Impact Score 9.6，ADVANCED+），本文却以 933 分垫底——文件创建/删除 324%、目录枚举 746%、扩展名敏感度（.ps1）4,071%、内存映射 231%。这两款产品在消费者日常操作中表现优异，但在编译与系统调用密集型场景下暴露出了截然不同的性能特征。

这一差异并不意味着任何一方的测试存在问题——当然，如果一款杀软在”复制文件”时快如闪电，却在每次 CreateFile 调用上多花 7 倍时间，那么它究竟是”对性能影响很小”，还是”只在特定考试中成绩优异”，就是一个值得玩味的问题了。

结语

本文通过 2 个编译工作负载和 20 个 API 级微基准，在 VM 快照还原的受控环境下对 16 款杀软的性能开销进行了系统性的量化。几点核心发现值得重申：

第一，没有全能冠军。迈克菲在文件系统微基准中几乎零开销，却在 DLL 加载和新 EXE 运行上被拉至数千百分比的增幅；火绒在进程创建和线程创建中表现最佳，却在 PE 内容写入上出现了 31,552% 的极端数据；Microsoft Defender 在进程创建路径上排名第一，但 MOTW 标记的新可执行文件触发了 SmartScreen 的深度检查使其增幅飙升至 3,342%。每款产品都有自己的优势路径和代价路径，选择时应当根据自身工作负载的特征来权衡。

第二，编译工作负载与微基准的结论可以存在显著差异。Malwarebytes 在 ripgrep 全量构建中仅增加 11.5%，但文件创建/删除微基准高达 253.9%——编译本身是 CPU 密集型工作且多核并行掩盖了 I/O 等待，同一绝对延迟在编译总耗时中占比被大幅压缩。这正是设计两条互补测试线的价值：编译工作负载给出端到端的真实体验，微基准则剥离 CPU 计算的掩盖效应，定位到具体的 API 路径瓶颈。

第三，杀软的性能代价集中在 I/O 密集型的安全敏感路径上。加密哈希校验（纯 CPU 计算）和线程创建（轻量内核通知）场景中，所有产品的增幅都在噪声水平以内；而文件写入 PE 内容、DLL 加载、注册表增删改查和新 EXE 运行序列则跨越了数个数量级的分化——这些恰恰是杀软必须执行内容扫描、映像检查或行为监控的核心路径。

最后需要说明本测试的局限性。首先，所有测量均在单一 VM 配置（24 vCPU/16 GB RAM/Windows 10 22H2）上完成，不同硬件、操作系统版本或杀软配置可能产生不同结果。其次，除1款产品外，测试使用的是各产品的默认配置，未调整任何扫描策略或排除规则——实际部署中管理员通常会为开发目录配置排除项，这可能显著降低开销。再次，杀软版本随时更新，厂商可能在后续版本中优化特定路径的性能。此外，本测试仅衡量性能开销，不涉及检出率、误报率、防护深度等安全效能指标——性能与安全之间往往存在权衡，开销更高的产品可能提供了更深层次的行为分析和内容检查。

就微基准的覆盖范围而言，当前 20 个场景远未覆盖到杀软可能介入的所有环节。网络方面，本测试仅覆盖了回环 TCP 连接和本地 DNS 解析，未涉及杀软对真实互联网流量的拦截——许多产品会安装根证书并以中间人代理的方式解密 HTTPS 流量，或在 WFP 层对出站连接执行信誉查询；对于频繁拉取远程依赖的包管理器（npm install、pip install、cargo fetch）来说，这部分开销可能占了大头。文件 I/O 方面，当前场景以小文件元数据操作为主，缺少大文件顺序/随机读写的基准测试——视频编辑、数据库、虚拟机磁盘镜像等任务的 I/O 模式与编译截然不同，杀软对大块连续读写的扫描策略（是否跳过、是否流式扫描）可能表现出截然不同的性能特征。此外，本测试未覆盖若干安全敏感的系统管理操作，包括服务创建与修改（SCManager）、计划任务注册（Task Scheduler）、WMI 事件订阅等——这些都是恶意软件常用的持久化驻留手段，杀软针对这些操作附加的行为监控可能带来额外延迟。文件重命名（构建系统和编辑器常用的”先写临时文件再原子重命名”模式）、NTFS 符号链接（与已测试的硬链接和 junction 经过不同的 reparse point 路径处理）、以及系统启动及用户登录阶段的延迟影响也均未纳入。最后，本测试衡量的是实时防护（on-access scanning）的开销，不涉及杀软定期执行的全盘扫描或后台智能扫描对系统资源的抢占——后者在特定时段内对磁盘 I/O 带宽和 CPU 时间的消耗可能远超实时防护本身。这些未覆盖的方面为后续工作指明了扩展方向。

完整的测试代码、原始数据和可交互的可视化图表均已开源：GitHub 仓库，可自行复现测试、提取关注的场景数据，或基于此框架扩展新的工作负载。

引用

1. AV-Comparatives. Performance Test. https://www.av-comparatives.org/tests/performance-test-april-2025/
2. AV-TEST. The best Windows antivirus software for home users. https://www.av-test.org/en/antivirus/home-windows/
3. UL Solutions. Procyon Benchmark. https://benchmarks.ul.com/procyon
4. Andrew Gallant. ripgrep. https://github.com/BurntSushi/ripgrep
5. .NET Foundation. Roslyn - The .NET Compiler Platform. https://github.com/dotnet/roslyn
6. Microsoft. File System Minifilter Drivers. https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/file-system-minifilter-drivers
7. Microsoft. Process Security and Access Rights. https://learn.microsoft.com/en-us/windows/win32/procthread/process-security-and-access-rights
8. Microsoft. Mark of the Web (MOTW). https://learn.microsoft.com/en-us/deployoffice/security/internet-macros-blocked
9. Mark Russinovich. Process Monitor. https://learn.microsoft.com/en-us/sysinternals/downloads/procmon