C#泛型如何实现排除指定类型的约束、解决FiFoDictionary的int键访问歧义

一、泛型类排除指定类型的实现路径 #

C# 语言规范从未支持反向排除的泛型约束写法，所有where子句仅支持正向的准入规则定义，你尝试编写的where T : !System.Int32语法本身不符合编译规范，不存在能直接让这段代码通过编译的配置。

针对“排除int、uint但允许DateTime类型”这类需求，可通过两个可落地的方案实现：

• 编译期拦截方案（最佳使用体验）
  核心逻辑是利用泛型重载的优先级，为所有需要排除的类型单独定义专用的泛型特殊重载，让用户传入被排除类型时直接触发编译错误，无需等待运行时校验。
  参考实现代码：

  // 对外暴露的主泛型类，不提供无约束的公开构造函数
  public class SomeWhereTest2<T>
  {
      internal SomeWhereTest2(AllowedTypeMarker<T> marker) { }
  }
  
  // 类型校验标记类，仅合法泛型参数可获取实例
  public class AllowedTypeMarker<T>
  {
      internal AllowedTypeMarker() { }
  }
  
  // 为被排除的int、uint类型定制特殊重载，强制触发编译错误
  public class AllowedTypeMarker<int>
  {
      // 构造函数私有无法实例化，同时引用不存在的类型直接触发编译报错
      private AllowedTypeMarker() => throw new InvalidOperationException("int is not allowed as generic parameter");
      public NonExistentType CompileError => null!;
  }
  public class AllowedTypeMarker<uint>
  {
      private AllowedTypeMarker() => throw new InvalidOperationException("uint is not allowed as generic parameter");
      public NonExistentType CompileError => null!;
  }
  
  // 静态工厂方法提供统一的实例创建入口
  public static class SomeWhereTest2Factory
  {
      public static SomeWhereTest2<T> Create<T>()
      {
          // 被排除的T会在这一步因为上面的特殊重载触发编译错误
          return new SomeWhereTest2<T>(new AllowedTypeMarker<T>());
      }
  }
  

  这种方式的本质是给被禁用的类型设置了永远过不了编译的“硬门槛”，和运行时校验相比，能在编码阶段就给出错误提示，大幅减少联调阶段的排查成本。实际效果为：调用SomeWhereTest2Factory.Create<int>()时，编译器会因为特殊重载里引用了不存在的NonExistentType直接报语法错误；调用SomeWhereTest2Factory.Create<DateTime>()时无特殊重载匹配，可正常完成实例创建，完全满足排除指定类型、保留其他合法类型的需求。

• 运行时兜底校验方案（实现简单）
  如果对编译期提示没有强需求，可直接在泛型类的静态构造函数中加入校验逻辑：

  public class SomeWhereTest2<T>
  {
      static SomeWhereTest2()
      {
          // 维护需要排除的类型集合
          var bannedTypes = new HashSet<Type> { typeof(int), typeof(uint) };
          if (bannedTypes.Contains(typeof(T)))
          {
              throw new NotSupportedException($"Generic parameter {typeof(T)} is not allowed, banned types include int, uint");
          }
      }
  }
  

  这种方式实现成本极低，但校验时机在程序启动后，适合内部使用的工具类，不适合对外暴露的公共组件。需要特别注意：不要为了排除int、uint采用“排除所有基元值类型”的写法，这种方式会误杀同样属于基元值类型的DateTime，和需求直接冲突。

二、FiFoDictionary的int键访问歧义解决 #

首先明确歧义的根源：
你在类中同时定义了两类索引器，一类是IDictionary<K,V>接口要求的V this[K key]按键访问入口，另一类是你自己添加的V this[int index]按位置访问入口。当键类型K为int时，两个索引器的参数类型完全重合，编译器会默认匹配参数类型更精准的重载，无法按照你预期的“索引优先”逻辑分流访问。

这里需要明确：没有任何参数能强制OrderedDictionary在int键场景下优先按索引访问，因为所有方法/索引器的重载匹配都是编译器在编译期根据参数类型静态决定的，运行时无法干预匹配优先级。可落地的解决方案有三个：

• 拆分访问入口，彻底消除参数类型重合
  不要把按位置访问的逻辑绑定在int参数的索引器上，而是将这部分逻辑改成显式命名的普通方法，比如：

  // 保留IDictionary要求的按键访问索引器
  public V this[K key] { get; set; }
  
  // 按位置访问的逻辑单独用方法暴露，不做索引器
  public V GetElementByPosition(int positionIndex)
  {
      // 调用内部OrderedDictionary的int索引器实现位置访问
      return (V)innerOrderedDictionary[positionIndex];
  }
  public void SetElementByPosition(int positionIndex, V value)
  {
      innerOrderedDictionary[positionIndex] = value;
  }
  

  这种方式下，不管K是什么类型，都不会出现两个索引器参数类型重合的问题：用户要按键取值就直接调用索引器传K类型参数，要按位置取值就显式调用方法传int参数，从设计上彻底消除歧义。

• 保留索引器体验，用独立参数类型做分流
  如果你一定要保留索引器的使用体验，也可以把按位置访问的索引器参数类型换成C# 8之后引入的System.Index类型——这个类型和int是完全独立的类型，就算K是int，两个索引器的参数类型也不会重合。用户可以用dic[0]（int参数）走键访问，用dic[new Index(0)]走位置访问，同样能实现无歧义分流。

• 替换存储结构，从根源规避非泛型类型的重载问题
  非泛型的OrderedDictionary本身就存在键为值类型时的匹配歧义问题，更稳妥的做法是自己实现泛型的有序字典结构：用Dictionary<K,V>存储键值映射，用双向链表维护元素的插入顺序，所有的访问逻辑都完全由你自己控制，既可以保证FiFo的顺序特性，也不会出现非泛型类型带来的重载匹配问题。

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