实际上，这可能是错误的——工作台似乎有点小问题。这个方法只在我导入了引用的类型时有效。然而，如果禁用了编译器标志“不允许未使用的局部变量”，那么如果我在文件的其他地方没有使用该类型，就会产生警告。

解决这个问题的一个方法是将链接的类型标记为“已使用”。C#在他们的xml文档中就是这样做的。或者只是链接到所有导出的全局变量，但如果它们共享名称，这可能会导致指向错误的类型。

这是我在一个实际程序中看到它的链接——当生成typedoc时，它可以很好地解析https://github.com/connor4312/cosmonaut/blob/18a954f6184173fff999a4616b7cf8554addd966/src/baseModel.ts#L45

好的，我同意这个应该可以工作，并且应该浏览整个已知符号列表(这是我作为JS用户所期望的，我认为这与网页版本的工作方式相匹配)。
深入研究后发现，#41877从未对gotoDefinition服务进行过更改，这意味着它只能与当前范围内的标识符一起工作，并且不会搜索整个项目以查找标识符。
一个失败的四斜杠测试：

///<reference path="fourslash.ts" />

// @Filename: foo.ts
//// export interface [|/*def1*/Foo|] {
////     foo: string
//// }

// @Filename: importee.ts
//// /** {@link /*otherFile*/[|Foo|] } not explicitly linked */
//// const f = ""

goTo.marker("otherFile");
verify.goToDefinitionIs("def1");

关于是否将范围扩大到所有标识符的讨论，稍后我会等待@sandersn回来再讨论这个问题。
否则，如果未使用的导入在@link中，我们将其视为已使用。

在与@orta讨论后，我们改变了观点。现在我认为将范围扩大到所有标识符是正确的选择，而他不是。然而：很难确定精确的语义，也很难高效地实现，所以我认为现在不值得这样做。
应该起作用的是导入引用：import('./b').Model。我不认为@link甚至能正确解析这个引用。
编辑：@mjbvz比我先想到：#43950

我倾向于通过将 @link 中引用的导入项视为已使用的变量来解决这个问题，这样 @typescript-eslint/no-unused-vars 就不会再抱怨了。这样一来，开发者可以像正常导入变量一样导入链接所需的变量，因此他们只需要了解一种导入变量的机制。
此外，为了使 @link 和普通引用之间的体验更加一致：

• 对于无法解析的 @link 引用报告错误
• 支持快速修复自动导入类型/从 @link 引用的变量。例如，如果我有

/** {@link Foo} */

那么 Foo 有快速修复功能来导入 Foo。

• 支持下标自动补全，例如在 Foo. 之后的光标位置