第三个是@JacksonKearl

@bpasero 在外部主机中没有IUriIdentityService吗？NativeExtHostSearch depends on UNKNOWN service IUriIdentityService.

可能不会，@jrieken可能知道。我认为该服务仅存在于工作台中，因为它依赖于已注册的文件系统提供程序。尽管扩展注册的提供程序实际上应该在扩展主机中可用。

已移除搜索工作线程文件中的使用。必须从外部传递路径敏感性，并在工作线程中从其中创建一个新的extUri。

在扩展主机中，您可以使用 ExtHostFileSystemInfo#extUri ,但有一个更大的“但是”。通常情况下，您不应该被要求使用 IURIIdentityService.extUri ,因为在99%的情况下，默认的 extUri-util 就足够了。
这就是为什么：所有将URI输入系统的地方，如从扩展接收诊断信息、打开文件和(也许？)搜索结果，都必须使用 IUriIdentityService#asCanonicalUri 。这个功能保证只使用一个有效的URI形式，因此可以默认使用更简单/更快的 extUri -util。
那么，我们能详细看看我们正在处理哪种类型的URI吗？扩展主机是否将URI输入系统，还是它属于某种 mainThreadSearch 类型(应该使用 asCanonicalUri )?这些用户输入的URI是否也应该规范化？

在我的情况下，我正在从 URI.file 中形成 URI,同时在本地文件搜索工作器(ripgrep的网页版本)中遍历 FileSystemDirectoryHandle。
vscode/src/vs/workbench/services/search/worker/localFileSearch.ts
第 193 行 in 236a716
| | if(!pathIncludedInQuery(queryProps,URI.file(path),extUri)){returnfalse;} |

这个操作是将搜索结果输入到vscode中，还是内部的一个东西，用于知道在哪些文件夹中进行搜索？此外，这个操作是在完全不同的上下文中完成的，就像一个单独的web worker一样，对吗？

是的，这都是在Web Worker的上下文中进行的，这是用于根据包含/排除过滤我们遍历的目录。我们像这样创建URI,然后将它们发送到主线程进行实际渲染。