使用[System.IO.Path]::GetFileName()获取目录名称是否存在潜在问题？

首先明确结论：这个用法不属于可长期依赖的合法特性，也不属于漏洞，只是当前.NET版本的字符串处理逻辑碰巧匹配取目录名的需求，存在明确的潜在风险，不推荐在生产环境或需要长期维护的脚本中使用。

底层逻辑说明 #

[System.IO.Path]下的所有字符串处理方法，默认都不会校验路径对应的实体是文件还是目录，也不会校验路径是否真实存在，仅基于路径分隔符做纯文本切割。GetFileName()的设计逻辑就是截取路径中最后一个分隔符之后的所有内容，因此不管传入的路径指向文件还是目录，只要路径末尾不带分隔符，返回结果就刚好和Split-Path -leaf的结果一致。

明确的潜在问题 #

• 处理带末尾分隔符的目录路径时会直接返回空值。比如传入C:\Users\Test\（末尾带反斜杠），GetFileName()返回空字符串，但Split-Path -leaf会正常返回Test，这是最容易踩的坑
• 无官方兼容性保障。官方文档未承诺该方法对目录场景的返回值符合预期，后续.NET版本如果调整路径字符串的处理规则（比如增加特殊目录标记的识别逻辑），该用法随时可能失效，且这种调整不属于官方需要兼容的破坏性变更范畴
• 代码可读性差。其他维护人员看到GetFileName()会默认认为你在处理文件路径，增加代码理解成本

替代方案建议 #

如果确实想使用.NET方法提升处理速度，可以先对路径做末尾分隔符裁剪：[System.IO.Path]::GetFileName([System.IO.Path]::TrimEndingDirectorySeparator($路径))，但更稳妥的方案还是直接使用原生的Split-Path -Leaf，原生命令已经兼容了不同场景下的目录、文件路径处理逻辑，完全符合官方兼容性承诺。

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