Windows命令行dir命令不同通配符写法匹配CSV文件的行为差异咨询

核心触发逻辑 #

该异常是Windows命令行从MS-DOS继承的遗留文件匹配设计导致的，不存在命令输入错误或文件损坏的问题：

• 当执行的通配符完全符合*.[固定扩展名]的标准格式（包括加引号包裹的"*.csv"写法）时，dir命令会触发内置的快速检索优化分支。该分支为了提升大目录下的检索速度，仅会比对文件的8.3格式短文件名的扩展名段，完全跳过对长文件名的通配符校验。
• 匹配失效的前提：当前目录存在8.3短文件名的历史冲突，最常见的场景是同主名前缀的文件数量过多、或之前有文件删除/重写的操作，导致部分长文件名后缀为.csv的文件，对应的8.3短文件名的扩展名段并非csv（比如原本应该生成DATA~1.CSV，实际生成的短名为DATA~1.CS1）。此时快速检索分支因为查不到短文件名的匹配项，就会返回无匹配结果的报错。
• 其他通配符写法的匹配逻辑差异：只要通配符写法打破了*.[扩展名]的标准结构，比如增加前置通配符位（**.csv、?*.csv）、在扩展名后补充通配符（*.csv*），命令就会自动跳出快速检索分支，走完整的长文件名+短文件名逐字通配校验流程，自然可以正确检索到目标csv文件。

相关特性补充 #

• 给通配符加双引号不会改变匹配逻辑：双引号只是向命令行传递无转义的字符串，不会改变命令对通配符结构的判断，因此dir "*.csv"和dir *.csv的表现完全一致。
• 临时规避方式：直接使用可触发完整匹配逻辑的通配符写法，即可正常检索目标文件。
• 永久修复方式：通过fsutil 8dot3name命令关闭对应磁盘卷的8.3短文件名生成规则，后续新创建的文件不会生成存在扩展名冲突的短文件名，从根源上避免该问题触发。

内容的提问来源于stack exchange，提问作者yxw158