因为错误消息经常会转到stderr not stdout.
将调用更改为：
taskkill /im "test.exe" /f >nul 2>&1
一切都会变得更好。
这有效是因为stdout是文件描述符 1，并且stderr按照惯例，是文件描述符 2。 （0 是stdin，顺便说一下。）2>&1从刚刚重定向到空设备的新值 1 复制输出文件描述符 2。
此语法（松散地）借用自许多 Unix shell，但您必须小心，因为 shell 语法和 CMD.EXE 之间存在细微差别。
Update:我知道OP了解名为“文件”的特殊性质NUL我正在写信到这里，但评论者没有写，所以让我离题，在这方面提供更多细节。
一直追溯到 MS DOS 的最早版本，某些文件名由文件系统内核提示并用于引用设备。最早包含这些名字的列表NUL, PRN, CON, AUX and COM1通过COM4. NUL是空设备。它始终可以打开以进行读取或写入，可以在其上写入任何数量，并且读取总是成功但不返回任何数据。其他端口包括并行打印机端口、控制台和最多四个串行端口。从 MSDOS 5 开始，还有几个保留名称，但基本约定已经非常完善。
当 Windows 创建时，它最初是作为 MSDOS 内核之上的一个相当薄的应用程序交换层，因此具有相同的文件名限制。当 Windows NT 被创建为一个真正的操作系统时，其名称如下：NUL and COM1被广泛认为无法发挥作用而无法消除它们。然而，新设备总会获得会阻止未来用户使用这些名称来获取实际文件的名称，这种想法显然是不合理的。
Windows NT 和后续的所有版本（2K、XP、7 和现在的 8）都使用更精细的NT命名空间 http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#nt_namespaces从内核代码到精心构造且高度不可移植的用户空间代码。在该名称空间中，设备驱动程序通过\Device文件夹。为了支持所需的向后兼容性，有一种特殊的机制使用\DosDevices实现任何文件系统文件夹中保留文件名列表的文件夹。用户代码可以使用通常的 Win32 API 下面的 API 层来浏览这个内部名称空间；探索内核命名空间的一个好工具是WinObj http://technet.microsoft.com/en-us/sysinternals/bb896657.aspx来自 Microsoft 的 SysInternals 小组。
有关 Windows 中文件（和设备）合法名称的规则的完整说明，MSDN 上的此页面 http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx既会提供丰富的信息，又会令人畏惧。规则是一个lot比应有的更复杂，并且实际上不可能回答一些简单的问题，例如“最长的合法完全限定路径名有多长？”。
