有几种不同的方式来调用 navto [ -full ] 命令：

1. 作用域到单个文件
2. 既不提供文件也不提供项目，就像 VS Code 对于 Go to symbol in workspace... 所做的那样
3. 提供项目，但不提供文件，就像 VS 对于 Go to Symbol 所做的那样
4. 只提供文件
5. 同时提供文件和项目
   (4) 和 (5) 的理解不够深入，因为主要的消费者都没有使用这种模式，而且行为也没有被记录。实际上，作用域似乎是包括给定文件的项目以及从那里下游的项目。就我个人而言，我认为如果请求不是文件范围的，我们应该忽略文件，然后回退到 (2) 或 (3)。
   (3) 似乎作用域仅限于单个项目，而不触发项目加载。这与 VS 的要求一致，因为 VS 会为每个项目发出单独的请求，复制下游搜索将是糟糕的。不幸的是，这确实意味着它永远不会触发项目加载，可能会导致令人困惑的不完整结果。
   (2) 似乎旨在搜索所有可发现的项目(它调用 combineProjectOutputFromEveryProject ),但据我所知，它并没有这样做。就我所理解的 loadAncestorProjectTree 而言，它将考虑所有已加载的项目以及任何下游项目(即使它们必须被加载)。
   举一个具体的例子，如果你在 VS Code 中打开 src/compiler/core.ts ,唯一已加载的项目将是 src/compiler ,尽管 src 以及它上游的所有内容都已被发现。如果你调用 navto ,依赖于 src/compiler 的项目如 src/tsc 和 src/services 将被加载，解决方案项目 src 也将被加载，但解决方案项目引用的无关项目不会被加载：

• src/cancellationToken
• src/debug
• src/instrumenter
• src/shims
• src/tsserverlibrary
• src/typescriptServices
• src/watchGuard

这似乎不正确，尽管我们可能有意地做出这个妥协以通过加载更少的项目来提高响应能力。