@
zjp 实际上 VS 和 JB 之类比较成熟的 IDE 当然都支持配置诊断提示，但这里真正的问题是，不管实现质量问题，开发者有必要认识到，这种 IDE 提供的诊断先天就是低人一等的。
而分配资源优先级解决不同的问题是工程人员的基本素质。
这里，最上等的诊断消息是语言实现给出的错误和警告，无视这些问题原则上（不排除编译器和语言自身 bug 之类的极端情形的例外）会导致得到的程序根本就不是想要的东西，不中断构建基本就是写 bug 浪费时间（编译错误的话编译器自己就终止了）。这种诊断当然是最优先考虑的（要想无视编译错误就别编译了）。
次一等的是 lint 类工具，历史上就是为了缩减编译器实现的难度和编译性能开销而从编译器分离出去的次要的诊断，这是来自语言设计者的判断。现代语言实现的性能宽松得多，如果检查发现的问题足够重要到对语义有普遍影响，把 lint 的分析加回编译器变成警告也是很正常的。如果仍然保留在 lint ，在一定程度上说明这本来就没那么重要，这个区别一直是 by design 。（当然，对一些都未必有编译器的动态语言来说，核心语言实现和 lint 诊断的差距可能相对不那么大。）
而 IDE 自己提供的补充诊断，是重要程度相对最低的。并且，假阴性（漏报）完全没有 spec 参照而无上限，假阳性（误报）的情形也极度宽松。还有很多时候和代码风格约定强相关。追溯这些诊断来源的性价比远远不如上面的，以至于把这些和上面的来源相提并论差不多就是碰瓷。
次要的问题是，因为 IDE 的实现标准比较宽松，所以就算是最有必要给出诊断的提示（甚至就是编译器警告），比单独运行的编译器之类核心工具的分析准确性普遍差很多，特别是 C++这样分析难度离谱的语言。像 VS 用的 EDG frontend 那个红线经常是只能整个关掉的程度，眼不见为净（主要是复杂性离谱，而不一定是实现水平烂，EDG 曾经是唯一实现过 C++03 export 的厂商）。即便没红线 IntelliSense 崩溃至今仍然是家常便饭，我天天遇到。其它 IDE 用 clangd 之类能基本解决比编译器死得离谱的问题，但是想万无一失还差得远了（这年头没遇到过常见编译器 ICE 的都不太好自认为熟练用户了……）。
再者，光是编译器能给出的问题其实已经非常多了。像 VC++的 cl 默认开全警告会因为假阳性（指用户有意的，不算 bug ）太多烦死，所以正常警告都不可能调最高（已经排除了就是 note 的部分）。（ g++这种诊断没编号的反而策略现实很多，加几个选项会警告的基本全是需要改的问题。）这样的问题，正常开发者（包括写编译器的）都不可能完全摸得清楚，基本是遇到坑了去长记性。本来已经够不太平了，还要照顾 IDE 的一堆莫须有问题是不是工作量不饱和？
其它语言经常没那么极端所以 IDE 体验较好，但没什么 IDE 厂商保证这里不存在差距，踩坑了就是自讨没趣了。
所以实际情况是，不分析很具体的问题，笼统相信 IDE 并多启用功能是很外行和幼稚的想法。作为专业人员，不要试图和有限的资源过不去，这类想法一开始就不要有。