很多人第一次接触 Defender 的排除项，都是因为一个让人抓狂的场景：编译器在生成代码，Defender 实时保护把中间文件当恶意软件删了；或者某个老旧的内部工具每次启动都被拦截，业务部门直接打电话投诉；又或者全盘扫描时，Defender 把一个几百 GB 的数据库文件翻来覆去地查，服务器卡到没法用。这时候给 Microsoft Defender 添加排除项就成了最直接的解决办法。
排除项本质上就是给防病毒软件划一块“免检区”，告诉它某些文件、文件夹、进程或者扩展名不需要扫描。这个机制既能解决误报，也能缓解性能压力，但同时它也是在削弱安全防护——所以怎么加、加什么、加多大范围，都需要讲究。这篇文章我会从 Defender 的工作机制说起，把添加排除项的所有方式、适用场景、坑点和经验都梳理一遍，适合刚从别的杀软切过来的人、被编译产物误报折磨的开发者，以及需要批量给终端配置的 IT 管理员参考。
1. 整体设计思路：为什么需要排除项，它到底解决了什么问题
1.1 Defender 的扫描模型决定了必然存在误伤
Microsoft Defender 的防护能力来自几个层面：实时保护监控所有文件操作、云提供的威胁情报、行为分析引擎，以及定期或手动触发的全盘扫描。这套模型在拦截恶意软件时非常有效，但它有一个天然缺陷——判断一个文件是否危险，依赖的是特征库和行为特征，而不是文件本身的业务价值。
于是就会出现一个尴尬的局面：你的 Node.js 项目里有几万个文件在 node_modules 里频繁读写，Defender 实时保护每开一个文件都要过一遍检测逻辑，I/O 路径变得极慢；一个用 UPX 壳压缩过的内部工具，因为特征和行为都“像”恶意软件，被直接删了；一个合法的安装包因为数字签名异常或从未被收录过信誉库，弹出了威胁提醒。这些都不是 Defender 在“乱来”，而是它的检测机制的正常表现，只是在真实业务场景里，这种“过度防护”反而制造了新的麻烦。
所以排除项的意义不是“关掉杀毒软件”，而是给 Defender 一套更精细的信任列表。你明确告诉它：这条路径下的内容是我自己管的，出问题我自己负责，不需要你一遍遍查。这样既保留了系统其余部分的防护能力，又解决了特定场景下的误报和性能问题。
1.2 排除项不是简单的开/关，而是信任模型的补充
Windows 安全中心里其实有“关闭实时保护”这样的按钮，但你真的在开发机或者生产服务器上把实时保护整个关掉，代价非常大——整个系统暴露在所有已知和未知威胁面前，这相当于把房子大门敞开了只留下了卧室的锁。
排除项的思路则完全不同：房子的大门依然锁着，保安依然在每个入口巡逻，只是你给了几个特定员工“绿色通道”权限，他们进出的随身物品不经过安检。这种操作的本质是信任模型的重构。实现层面对应的就是 Defender 的四个排除维度：文件、文件夹、文件类型、进程。
这四个维度的设计是有讲究的。前三个维度针对的是“扫描目标”——被检测的对象本身；第四个维度针对的是“扫描来源”——某个进程发起的所有文件读写操作。采用这种分层设计，是因为不同业务场景下，你能明确告诉 Defender 的“信任边界”不一样：有时候你信任一个文件，有时候你信任一个目录，有时候你信任一类扩展名，有时候你信任一个应用程序的所有行为。
1.3 为什么商用端点管理也需要排除项
在个人电脑上添加排除项很简单，点点鼠标就行。但在企业环境里，终端通常被 Intune 或组策略接管，Defender 配置由管理员统一下发，本地 UI 部分选项是灰色不可点的。即便如此，排除项依然是企业运维的刚需。
常见的例子：ERP 客户端的安装目录会被行为分析误报；财务系统的报表导出模块每次生成 CSV 都要经历一次完整扫描导致导出超时；测试部门的自动化套件每秒钟创建上千个临时文件，Defender 的实时保护成了性能瓶颈……这些场景下，管理员需要在安全与业务连续性之间做取舍，而排除项就是这个取舍的落地工具。
关键区别在于，企业环境的排除项必须通过 GPO 或 Intune 配置，而不是让用户在本地自行添加。原因在于企业必须保留对这些终端上排除项的可见性和可撤销能力，否则一台被攻陷的机器上，攻击者完全可以自己加个排除项来掩盖恶意软件——这就是不得不说的安全底线。个人场景例外，但也要时刻记住：你添加的每个排除项，都是在亲手给安全软件划出盲区。
2. 核心细节与实操要点：四种排除项类型逐个拆解
2.1 文件、文件夹、文件类型、进程的真实区别
很多资料会把排除项简单归类为“排除路径”，好像只要把路径填进去就完事了。实际上，Defender 提供的四个排除维度，面向的是完全不同的检测场景。
文件排除：最精确，只对指定文件本身生效。适合处理明确知道是误报的某个特定文件。缺点是粒度太细，一旦文件更新到新版本，如果路径变了还得重新加。
文件夹排除：最常用。对整个目录生效，目录下的所有文件、子目录都会被排除。适合编译输出目录、缓存目录、虚拟环境目录等。
文件类型排除：按扩展名排除。比如填.txt，那么所有路径下的 txt 文件就都不扫描了。这个维度看起来很省事，但实际上风险最高，因为恶意软件完全可以把 payload 改成你排除的那个扩展名来逃避检测。我不建议轻易用扩展名排除，除非你确定某个扩展名只对应一种绝对安全的业务文件。
进程排除：按进程名或完整路径排除。它的机制和前三个不一样——前三个是“扫描目标”的豁免，进程排除是“运行来源”的豁免：当你排除某个进程后，这个进程打开或创建的任何文件，实时保护都不会再拦截。如果你的业务系统因为某个老旧的第三方 exe 每次运行都触发大量误报，进程排除是最有效的解法。
2.2 通过 Windows 安全中心图形界面添加排除项
对于日常使用，图形界面是最直接的方式：
- 打开 Windows 安全中心（Windows 11 在“Windows 安全中心”，Windows 10 路径相同，可以从设置中搜索进入）。
- 点击“病毒和威胁防护”，找到“病毒和威胁防护设置”，点击“管理设置”。
- 在“排除项”区域点击“添加或删除排除项”，然后点击“添加排除项”。
此时会弹出四个选项：文件、文件夹、文件类型、进程。选择对应类型后，进入文件选择器选择目标路径。注意界面路径在不同 Windows 版本上略有差异，但核心入口基本都是这套逻辑。
有一个细节容易被忽略：UI 里添加文件夹时，你只能通过浏览按钮选择一个已在文件系统中存在的目录，不能直接输入路径。所以如果你想排除一个尚未创建的目录（比如持续集成里稍后才生成的构建目录），你得先在磁盘上手动建一个空目录，再通过 UI 添加，否则就得用 PowerShell。
2.3 用 PowerShell 批量管理排除项：更灵活也更好用
在需要批量配置或者排除目标还不存在时，PowerShell 是首选方案。管理排除项的 cmdlet 很短，但参数语义需要理解清楚。
先看最常用的添加排除项命令：
# 添加文件夹排除项 Add-MpPreference -ExclusionPath "D:\BuildOutput" # 添加文件排除项（直接指定文件完整路径） Add-MpPreference -ExclusionPath "C:\Program Files\LegacyApp\tools\legacy.exe" # 添加扩展名排除项 Add-MpPreference -ExclusionExtension ".tmp" # 添加进程排除项 Add-MpPreference -ExclusionProcess "legacyApp.exe"查看当前已生效的所有排除项：
Get-MpPreference | Format-List ExclusionPath, ExclusionExtension, ExclusionProcess移除某项排除：
Remove-MpPreference -ExclusionPath "D:\BuildOutput" Remove-MpPreference -ExclusionExtension ".tmp" Remove-MpPreference -ExclusionProcess "legacyApp.exe"注意Add-MpPreference是追加语义，不会覆盖已有值，所以当你向同一台机器重复添加多个排除项时，它们是叠加的；而Remove-MpPreference会移除匹配的指定条目。换句话说，同一个排除项你添加三次，最后删除一次也就删掉了，不会有一条隐藏的重复记录。
这里还有一个容易被忽略的点：ExclusionPath参数对文件和文件夹是共用同一个数组的，你可以用同一条命令既排除文件又排除文件夹，它们不会冲突。
2.4 通配符的语法与限制
通过 PowerShell 添加排除项时，路径里可以使用通配符。规则不算复杂，但容易踩坑。
*匹配零个或多个字符。?匹配单个字符。
举例说明：
# 排除所有以 .log 结尾的、位于 D:\logs 下的文件 Add-MpPreference -ExclusionPath "D:\logs\*.log" # 匹配 C:\Cache 目录下的所有一级子目录 Add-MpPreference -ExclusionPath "C:\Cache\*"但通配符不是万能的。它遵循 Windows 路径匹配的常见限制，比如*不会跨目录级联匹配，D:\logs\*.log无法匹配D:\logs\sub\log1.log。如果你要排除整个目录树，最省事的做法是直接排除父文件夹，而不是试图用通配符去覆盖所有深层路径。
有个细节非常反直觉：UI 中添加排除项时其实并不支持直接输入通配符路径，你只能在图形选择器里选择实际存在的文件夹。但 PowerShell 可以直接写通配符路径，所以如果你的目标是排除一类分布在多个目录下的同名文件，PowerShell 几乎是唯一可行的入口。
另一个坑是：路径结尾不要多带一个反斜杠。C:\Cache\和C:\Cache在大部分情况下能正常工作，但在某些版本里，尾部多出的反斜杠会导致匹配失效。稳妥起见，路径不要以\结尾。
2.5 环境变量别直接用：先展开再添加
有朋友喜欢图省事，直接加一条这样的命令：
Add-MpPreference -ExclusionPath "%USERPROFILE%\AppData\Local\Temp"这条命令执行后，Defender 也不会报错，但你回头一看会发现它原样把%USERPROFILE%当作路径存进去了，压根不会展开成C:\Users\你的用户名。这种排除项基本不会生效。
正确做法是在 PowerShell 里先展开：
$tempPath = Join-Path $env:USERPROFILE "AppData\Local\Temp" Add-MpPreference -ExclusionPath $tempPath或者直接用固定路径也挺好。企业批量配置时，注意不同用户名的机器上路径不一致，最好用组策略里的环境变量占位来处理，而不是在 PowerShell 里硬编码某一个人的路径。
3. 实操过程与核心环节实现：从开发机到服务器的完整演练
3.1 典型场景一：排除 .NET / Java / Node.js 构建产物
这类场景是开发者遇到最多的。以 .NET 项目为例，你会频繁编译到bin和obj目录，Defender 实时保护每次扫描这些目录都会拖慢构建速度，严重时还会因为编译中间文件被锁定导致生成失败。
建议排除的路径：
Add-MpPreference -ExclusionPath "C:\dev\MyProject\bin" Add-MpPreference -ExclusionPath "C:\dev\MyProject\obj"Java 用户对应的就是 target 目录：
Add-MpPreference -ExclusionPath "D:\workspace\order-service\target"Node.js 项目里node_modules动辄几万个文件，Maven 构建时的本地仓库~/.m2/repository也可能非常大，这些都可以作为排除对象。一个相对稳妥的通用做法是只排除本地开发目录下的依赖产出，而不是直接把整个用户目录排除掉——后者会把风险范围扩得太大。
3.2 典型场景二：排除编译器和打包工具进程
有些时候你并不知道具体是哪个文件被扫描了，只观察到编译进程或打包工具的性能严重下降，或者工具运行时生成的临时文件总是被隔离。这种情况可以考虑进程排除。
比如排除常见构建工具的进程（以实际进程名为准）：
Add-MpPreference -ExclusionProcess "msbuild.exe" Add-MpPreference -ExclusionProcess "java.exe" Add-MpPreference -ExclusionProcess "node.exe"但要谨慎：直接从进程维度排除意味着这个进程发起的读文件行为都不会被扫描，一旦这个进程被劫持或者你在里面跑了一段带漏洞的依赖，那相当于给恶意代码开了一道专列。所以我更建议先精确定位是哪些文件被误报，用路径排除替代进程排除；只有确认了某个进程的整个行为链路都是可信且无法用路径界定时，才考虑进程排除。
3.3 典型场景三：大型数据文件与只读仓库
如果你在企业环境里管过文件服务器，一定懂这种痛：Defender 定期扫描一个 500 GB 以上的共享目录，I/O 被打满，所有人都在喊卡。这种场景下你需要排除的不是某个应用，而是整个高频访问的数据仓库。
Add-MpPreference -ExclusionPath "D:\SharedData\Archive"同时可以配合 Windows 任务计划，为这台数据服务器设置自定义扫描计划，避开业务高峰：
Set-MpPreference -ScanScheduleDay 6 -ScanScheduleQuickScanTime "02:00"另一个常见的是 Outlook 的离线数据文件.ost，它体积大且高频读写，很容易拖慢 Outlook 的启动。有些企业会建议排除.ost扩展名，但按扩展名排除的口子在前面已经说过——风险太大。更好的办法是只排除当前用户的.ost文件路径，而不是把所有.ost文件都纳入免检。
3.4 如何验证排除项是否真的生效
添加完排除项后，你不能马上就认为万事大吉了。验证排除项是否生效有一个比较简单的方法：通过 PowerShell 确认配置项已经存在。
Get-MpPreference | Select-Object -Property ExclusionPath, ExclusionExtension, ExclusionProcess如果你的排除项出现在列表中，说明 Defender 已经接收到这条策略。但“策略接收”不等于“实际生效”，因为 Defender 的实时保护模块会缓存部分配置，刚添加完的排除项可能要等几秒到几分钟才会完全落地。你可以在添加之后手动发起一次扫描来确认没有报错，或者直接观察之前误报/卡顿的场景是否消失。
有更极客一点的验证方式：把一个已知是“防御者不会扫描”的测试样本放入排除目录，然后手动扫描该目录，观察是否还会报毒。但这种做法需要用正规测试样本文件（如 EICAR 测试文件）来测，不要随便从网上下载真实恶意软件来做测试，否则一旦搞错路径，你的机器就是真的中毒了。
3.5 检查当前机器由谁管理：避免“改了不生效”的尴尬
执行上面的命令之前，先确认这台机器的 Defender 是否被组策略或 Intune 托管。跑一下这条命令：
Get-MpComputerStatus | Select-Object AMRunningMode如果返回的结果是AMRunningMode: Passive或者看到了非Active的字样，说明 Defender 可能是在终端管理平台下以被动模式运行，本地的排除项配置不一定能直接生效。这种情况去找终端管理团队，通过 GPO 或 Intune 的安全策略下发排除项，而不是在终端上白费力气。
4. 常见问题与排查技巧实录
4.1 添加了排除项，文件还是被删了
这是最让人崩溃的问题，排查时务必先确认几个事实：
第一，有没有添加错维度。如果你排除了.bin文件扩展名，但实际被删的是一个setup.exe，那当然不会生效。第二，路径匹配是否准确。Defender 的排除路径匹配是对大小写不敏感的，但对路径结构敏感，如果你添加的是C:\Program Files\App\data，而实际程序读写的是C:\Program Files\App\data\sub\file.dat，文件夹排除会覆盖子目录，这是没问题的；但如果你是精确到文件的排除，就不会覆盖到目录的其他文件。第三，确认是否真的已经保存。用Get-MpPreference重新检查一遍列表。
另一个常见的因素是“云保护”和“自动提交样本”的干扰。Defender 的云保护模块会把一些文件送到云端信誉分析，即使本地实时保护已经把这个文件排除了，云端的判定结果依然可能触发隔离。为了彻底解决误报，除了加排除项之外，有些场景还需要在“病毒和威胁防护设置”里临时关闭“自动提交样本”，或者把文件主动提交给微软分析去修正指纹。彻底解决之后再把云保护打开，这才是正确的操作顺序。
4.2 UI 按钮是灰色不可点的
前面提到过这可能是被企业策略管控的结果。Get-MpComputerStatus里如果显示AMRunningMode: Passive，或者你用管理员权限打开设置时依然看到灰度按钮，多半是 Intune/组策略覆盖了本地编辑能力。
还有一个不太明显的坑：如果你的 Windows 账号本身不是管理员，或者即使你用的是管理员账号但没有“以管理员身份”打开安全中心相关设置，部分选项也会显示为不可用。试试用管理员权限重新打开设置，或者干脆直接用管理员权限运行 PowerShell 添加排除项。
4.3 通配符排除不生效的排查要点
通配符匹配不是你想当然的那样。Defender 的通配符语义中，*无法跨目录匹配。如果你排除的是C:\Cache\*，那它能匹配C:\Cache\a.txt，但不能匹配C:\Cache\sub\b.txt。而且通配符功能主要面向路径末尾的文件名匹配，放在路径中段能否生效取决于 Windows 的匹配实现。
更隐蔽的是：UI 添加的路径里如果包含*会被当作普通字符存储，而不是通配符解析。因此涉及通配符的排除务必使用 PowerShell，并且在添加后立刻用Get-MpPreference看存储值是否符合预期。
4.4 32 位 / 64 位路径重定向导致的失效
这是老司机都容易踩的坑。64 位 Windows 上，32 位程序读写“Program Files”目录时，会经过 WOW64 重定向，把C:\Program Files\App变成C:\Program Files (x86)\App，或者在System32与SysWOW64之间切换。如果你的排除项写的是C:\Windows\System32\legacy.dll，而实际触发扫描的是 SysWOW64 目录下的同名文件，排除自然不生效。
解决办法是在添加排除项时把两个路径都加上：
Add-MpPreference -ExclusionPath "C:\Windows\System32\legacy.dll" Add-MpPreference -ExclusionPath "C:\Windows\SysWOW64\legacy.dll"或者干脆排除上一级文件夹，避免路径重定向带来的差异。
4.5 排除项已经配置了，但全盘扫描还是卡顿
如果你确认排除项生效了，但全盘扫描时系统依然卡顿，往往是因为云端提交的“文件信誉检查”阶段还是会读文件。排除项能绕过本地的特征匹配，但没办法完全阻止所有 I/O 行为——Defender 还是会枚举目录、读取文件元数据。最直观的验证办法是把排除目录临时改名为一个扫描程序不认识的名字，对比之下你会发现扫描时间并没有变化，这就说明 Defender 对该目录的“枚举”行为仍然存在。
这种情况下与其执着于排除项，不如调整整体扫描策略：用Set-MpPreference -ScanParameters设置快速扫描为主，或者把完整扫描安排到低峰期（前面提到的ScanScheduleDay等参数），减少实时扫描对业务的影响。
5. 避坑心得与安全平衡建议
5.1 排除项不要“贪大”，能精确就别宽泛
我在实际运维里见过很夸张的配置：有人为了省事，直接把整个C:\盘排除掉了，理由是“反正公司电脑有网络准入控制，不怕中毒”。这种操作等于把 Defender 变成了摆设。正确的排除项设计思路是：先解决具体问题，再考虑性能优化。
举个例子，一个上报误报的软件装在C:\Program Files\FinanceSoft，如果只是它的某个ocr.dll被误报，那就只排除这个 DLL；如果整个软件运行都卡，再考虑排除它的整个安装目录。不要一上来就排除C:\Program Files (x86)或者整个用户目录，否则你就是在给恶意软件自动划免检区。
5.2 保留审计意识：定期盘点机器上的排除项
很多人添加了排除项之后，过几个月就忘了自己加过什么。建议每季度做一次盘点，直接在 PowerShel1 里导出：
Get-MpPreference | Select-Object -ExpandProperty ExclusionPath | Out-File "C:\audit\defender_exclusions.txt"企业环境下，管理员可以通过 GPO 或 Intune 集中查看和回收不必要的排除项。个人使用的话，我也建议你把这个习惯当作一种简单的自我保护——浏览器插件、开发工具、奇怪的破解软件都可能会悄悄变更 Defender 配置，定期检查至少能发现自己机器上有没有新增你不认识的排除项。
5.3 能用“提交误报”就别只依赖排除项
排除项解决的是“表象”，真正解决误报的方式是把文件提交给微软分析。你可以访问微软的恶意软件提交站点，上传被误报的文件和样本，等待分析师处理。处理成功后，后续更新里 Defender 就会把它从黑名单中移出，其他同事或你自己的另一台电脑都不会再误报。
这条路比加排除项慢得多，但它才是根治方案。排除了误报文件后，可以再通过提交报告让它从检测名单里移除，这样既能维持防护完整性，也避免将来系统重装后又要重复配置排除项。
5.4 进程排除是最后的手段，不要轻易用
如果你真要添加进程排除项，建议遵守几条底线：只对被隔离/误报过、并且有数字签名的可信进程使用；不要把cmd.exe、powershell.exe、python.exe这类脚本解释器直接加入排除——它们本来就是攻击者最喜欢利用的宿主进程；进程排除路径尽量用完整路径，不要只写进程名。
让我再强调一次：进程排除的语义是“这个进程做的一切文件操作都不实时扫描”，它比文件夹排除的范围更大、风险更高。文件夹排除至少还有一个明确的位置边界，进程排除则没有了位置边界——进程跑到哪里，哪里就是豁免区。这个道理和“你可以给同事单独用一间办公室，但不代表他可以随意进入所有楼层”是一样的。
5.5 企业环境下，务必通过受管渠道配置
如果你负责的公司电脑超过十台，请走组策略或 Intune 来统一下发排除项，不要在每台终端上手工添加。原因有两个：一是在终端本地添加的排除项可能被使用者误删或滥用；二是统一配置方便审计、变更和回收，出了问题也能快速定位。
组策略的配置路径是：计算机配置 → 管理模板 → Windows 组件 → Microsoft Defender 防病毒 → 排除项。在这里可以添加排除的路径、扩展名和进程。Intune 的路径类似，在安全基准或 Endpoint Security 策略的“防病毒”配置文件中管理排除项。
5.6 添加完排除项后顺手做一次“配置回读”
我会在日常操作里固定一个收尾动作：添加完任何排除项，立刻用Get-MpPreference回读一次，确认路径没有路径拼接错误、环境变量没有被原样存储、通配符是否符合预期。这一步花不了十秒钟，却能帮你避免大部分“排除不生效”的返工。
另外，如果你的机器上装了第三方安全软件并且接管了 Defender，你会发现Get-MpPreference可能仍然能读到排除项配置，但实际系统上生效的是第三方的扫描策略。遇到这种情况，先确认到底是谁在真正负责实时保护，再去对应的安全控制台里做排除配置，方向对了才是效率最高的。
说到底，Defender 排除项是一个“用最小豁免换最大可用性”的工具。它在误报与性能之间提供了一个缓冲地带，但同时也要求使用者有足够的判断力——哪些内容值得信任，哪些豁免范围可以收缩到最小，哪些原则不能让步。把这些想清楚，再动手配置，才能既不被安全软件误伤，也不给恶意程序留门。
