你能分享一个自包含的最小示例代码，展示这个问题吗？

你好，我在Stackblitz上成功复现了这个问题。希望这能帮到你。

只需在effects.ts中注解掉指定的这一行即可。

如果你不熟悉Angular/ngrx,这里有一点解释：
默认情况下，createEffect接受一个返回类型为Action的函数参数，这就是这个例子中的map所做的。
所以，当导入被注解掉(比如map)时，整个类型流就会中断并从上到下出现波浪线。同时，代码本身是没有问题的，只是缺少了必要的导入。不幸的是，很难判断哪些导入是缺失的，因为波浪线并没有指示它们。所以你需要一个一个地检查。
总之，如果有些导入缺失，只需将波浪线放在那些缺失的导入上 - 如果没有这些导入，就无法判断整个代码是否出错，因此整个代码不应该被标记为全部错误。

感谢@moniuch
这里有一个简单的问题仓库：

export function foo(x: string) { }

foo({ x: noSuchSymbol })

TS团队的某人也可以发表意见，但我会补充我的想法
我们已经在这里发现了两个错误：一个是缺失的符号，另一个是错误的类型。我对这个问题的改进建议如下：

• 找出在VS Code侧边栏上显示重叠错误跨度的更好用户体验(之前在Hard to read overlapping diagnostics vscode#88514中讨论过)
• 保留两个错误，但使外部错误更清晰，表明它涉及到未解决的符号，修复该符号可能会解决问题(可能使用相关的错误跨度)

作为附注，当我的光标在缺失的符号名称上时，我确实看到了添加缺失导入的快速修复(map):

然而，您无法在外部错误上触发此修复。

@mjbvz ,我绝不是TS方面的Maven，但我认为：
一个是因为缺少符号，另一个是因为类型错误。在所有导入都到位之前，无法评估类型是否正确或错误。因此我的工单标题是：仅标记缺少导入的代码单元，标记没有缺少导入的这些代码单元。我认为这非常合理且简洁。
您的备注还指出了另一个生产力问题——修复导入所需的光标位置过于严格。我相信，在幕后，语言服务很清楚地知道还有一些未解决的导入，在这种情况下，Add all missing imports 修复应该在光标位置无关紧要的情况下可用。如果我的假设有误，请纠正我。尽可能放宽位置可以避免开发人员在代码中进行不必要的导航/鼠标操作。

在给定的具体示例中：

export function foo(x: string) { }

foo({ x: noSuchSymbol })

这里的输入类型是已知的错误的，无论 noSuchSymbol 的类型如何，因为函数需要一个 string 。因此，这里的类型错误仍然是有用的(可以认为比未解决的符号错误更有用，甚至，如果仍然会有类型错误，那么修复后者是没有意义的，例如，通过添加导入)。如果调用被更改为 foo(noSuchSymbol) ,那么类型错误就会消失(未解决的符号被视为 any )。

@fatcerberus 因为我并没有编写你引用的简化代码片段，所以我并不认为它是正确的或有决定性的。我的信念是，OP中的代码不应该在其中的某些导入仍然缺失时被缩进。