看起来是由于Go项目中的一个伪GoPATH目录结构最终被相对父目录中的go.mod符号链接回自己的xyz导致的。

ls -l ...
xyz -> ../../../..
我认为这是在Go模块广泛使用之前的事情。

在这里，可以对scandir代码进行建模，参考Go的filepath.EvalSymlinks https://pkg.go.dev/path/filepath#EvalSymlinks
@google写道，它可以工作。这段代码遍历任何内容，避免了循环路径的递归。它没有包括最新的学习成果，但不会崩溃。我不知道其他人是否也在这样做。比如@facebook并不这样做。
https://pkg.go.dev/github.com/haraldrudell/parl@v0.4.184/pfs#Traverser
遍历符号链接是一个巨大的问题空间。这段代码可以很容易地转换为ECMAScript,并且每次都可以正常工作。

我能够在沙箱中重现这个问题：

1. 从 .gitignore 中移除 /sandbox
2. 运行沙箱并搜索 button => 它会返回一堆结果
3. 链接一个父目录 ln -s ../../.. boom
4. 运行沙箱并搜索 button => 它会卡住 -- 我觉得它是无限遍历符号链接
   我尝试在 globby 中添加以下选项，但它没有解决问题：

followSymbolicLinks: false,
    onlyFiles: true,

当我从选项中移除 gitignore: true 时：

1. 它确实解决了问题( followSymLinks 被尊重)
2. glob 运行速度提高了一倍(500ms vs 1000+ms with gitignore)
   因此，似乎 globby gitignore 是有问题且引入了性能退化。我在想我们能否在 globby 中得到修复？

在我看来，设置 followSymbolicLinks: false 不是一个选项。符号链接很常见，而且在正确设置的情况下，它们通常不会引起循环。
既然 globby 尊重用户的 .gitignore 文件，那么在 .gitignore 文件中添加一个进一步的条目是否可以解决这个问题，从而排除符号链接的文件夹？
@shilman 另外，你能尝试一下 deep 选项吗？默认情况下，它被设置为 Infinity.。也许我们应该将文件夹深度限制在例如 100 以内。

@haraldrudell 为了让你知道背景：我们没有自己实现glob搜索，而是依赖于globby库。如果你认为循环符号链接应该以不同的方式处理，那么我认为在那里打开一个bug报告是有意义的，除非globby本身无法配置它。

@valentinpalkovic ,我认为 deep 不是一个好的解决方案。deep: 50 仍然会崩溃，而 deep: 20 可以工作，但每次搜索需要10秒才能完成。

这个bug对我来说很重要，因为我想将 fileSearch 作为遥测的一部分使用，我需要它具有高性能。它可以在每天启动时运行一次(我会缓存结果)。我想我可以只为遥测情况传递 followSymbolicLinks: false ,然后我们可以将其留给 true 进行搜索 UI。但是遗憾的是，gitignore 与 followSymLinks 不兼容。