为何显式接口实现的大小写差异会导致类不符合CLS规范？

C#示例代码 #

[assembly:CLSCompliant(true)]

public interface I
{
    void FrobnicateSQL();
}

public class C : I
{
    public void FrobnicateSql() { }  // *
    void I.FrobnicateSQL() { }
}

触发的编译器警告 #

CS3005: Identifier 'C.FrobnicateSql()' differing only in case is not CLS-compliant

我理解对其他程序集可见的成员不应仅存在大小写差异，因为VB.NET这类大小写不敏感的语言无法区分调用目标。但从技术上看，这两个成员不会同时可见：显式实现的FrobnicateSQL只有在变量静态类型为I时才可见，比如下面的VB代码调用完全无歧义，能正常编译：

Dim c As New C()
Dim i As I = c

c.FrobnicateSql()
i.FrobnicateSQL()

那为什么C#编译器还是判定这是CLS违规？是为了简化规范或检测算法才把这种边缘场景纳入，还是这个示例确实会给大小写不敏感的.NET语言带来问题？

解答 #

这本质上是CLS规范的设计原则问题，而非实际调用的歧义问题，核心原因有三点：

• CLS规范的核心要求：公共成员集的全局无歧义性
  CLS要求的是，一个类型对外暴露的所有公共可见成员集合（包括通过接口继承而来的成员）中，不能存在仅大小写差异的标识符。这里的"可见"是指外部程序集能访问到的成员整体，而非针对某个变量静态类型的可见性。
  虽然调用时可以通过静态类型区分，但从C类的公共成员整体来看，同时存在FrobnicateSql（类自身公共方法）和FrobnicateSQL（通过接口I暴露的方法）——这两个标识符在大小写不敏感语言中会被视为同一个，直接违反了CLS"公共标识符必须在不区分大小写的前提下唯一"的核心规则。

• 简化编译器检测逻辑
  如果要区分"接口显式实现的成员"和"类自身公共成员"的可见性差异，编译器需要处理大量复杂场景，比如接口的多层继承、显式实现成员是否被其他接口继承等。为了避免检测逻辑过于复杂，CLS规范直接做了一刀切的规定：只要两个公共可见标识符仅大小写不同，无论调用场景是否有歧义，都判定为违规。

• 提前规避潜在的跨语言交互风险
  你测试的VB代码确实能正常运行，但部分大小写不敏感的.NET语言在处理类型成员时，可能会将接口成员与类自身成员合并到同一命名空间/成员集合中。这种情况下，就可能出现编译错误或调用逻辑混乱的问题。CLS规范提前把这种边缘场景纳入违规范围，就是为了规避这类潜在风险。

内容的提问来源于stack exchange，提问作者Heinzi