是否可将C#泛型方法的类型参数约束为仅支持record类型？

可行的替代实现方案 #

下面给出4种不同侵入程度、不同性能表现的实现方案，可以根据自身项目场景选择：

方案1：接口约定实现（侵入式，编译期安全，零运行时开销） #

直接在公共接口IFoo中定义更新Tag的约定方法，每个record只需要一行代码实现，是最稳妥的方案：

interface IFoo
{
    string Tag { get; }
    IFoo WithTag(string newTag);
}

// 所有实现IFoo的record补充对应实现即可
record Rec1(string Tag) : IFoo
{
    public IFoo WithTag(string newTag) => this with { Tag = newTag };
}

record Rec2(int Num, string Tag) : IFoo
{
    public IFoo WithTag(string newTag) => this with { Tag = newTag };
}

// 通用泛型方法实现
private TRec Update<TRec>(TRec rec, string tag) where TRec : IFoo
{
    return (TRec)rec.WithTag(tag);
}

该方案的缺点是需要每个record补充一行实现，适合record数量不多的场景。

方案2：反射调用合成方法（零侵入，适合低频调用场景） #

C#编译器会为所有record类型自动生成一个名为<Clone>$的公共无参方法，返回克隆后的新实例，配合反射给Tag的init属性赋值即可实现需求，可以加缓存减少反射开销：

using System.Reflection;
using System.Collections.Concurrent;

private static readonly ConcurrentDictionary<Type, (MethodInfo CloneMethod, PropertyInfo TagProp)> _cache = new();

private TRec Update<TRec>(TRec rec, string tag) where TRec : IFoo
{
    var type = typeof(TRec);
    var (cloneMethod, tagProp) = _cache.GetOrAdd(type, t =>
    {
        var clone = t.GetMethod("<Clone>$", BindingFlags.Public | BindingFlags.Instance);
        if (clone == null) throw new InvalidOperationException($"{t.Name}不是支持克隆的record类型");
        var prop = typeof(IFoo).GetProperty(nameof(IFoo.Tag))!;
        return (clone, prop);
    });

    var cloned = (TRec)cloneMethod.Invoke(rec, null);
    tagProp.SetValue(cloned, tag);
    return cloned;
}

该方案不需要修改现有record定义，但没有编译期检查，非record类型传入会抛出运行时异常，且有一定反射开销。

方案3：表达式树预编译（零侵入，高性能） #

将克隆和赋值逻辑用表达式树预编译为委托缓存，后续调用性能接近原生代码，适合高频调用场景：

using System.Linq.Expressions;
using System.Collections.Concurrent;

private static readonly ConcurrentDictionary<Type, Delegate> _updateDelegateCache = new();

private TRec Update<TRec>(TRec rec, string tag) where TRec : IFoo
{
    var updateFunc = (Func<TRec, string, TRec>)_updateDelegateCache.GetOrAdd(typeof(TRec), type =>
    {
        var recParam = Expression.Parameter(type, "rec");
        var tagParam = Expression.Parameter(typeof(string), "tag");
        // 调用克隆方法
        var cloneCall = Expression.Call(recParam, type.GetMethod("<Clone>$", BindingFlags.Public | BindingFlags.Instance)!);
        // 给克隆后的实例设置Tag属性
        var memberInit = Expression.MemberInit(cloneCall, 
            Expression.Bind(type.GetProperty(nameof(IFoo.Tag))!, tagParam));
        // 编译为委托
        return Expression.Lambda<Func<TRec, string, TRec>>(memberInit, recParam, tagParam).Compile();
    });
    return updateFunc(rec, tag);
}

该方案仅第一次调用时有表达式树编译开销，后续调用性能和原生手写with语句几乎一致。

方案4：源生成器（零侵入，编译期安全，高性能） #

如果项目中实现IFoo的record数量非常多，可以自定义源生成器，扫描所有实现IFoo的record类型，自动生成对应的WithTag接口实现或者Update方法重载，既可以在编译期做类型检查，也没有任何运行时开销，仅需要额外实现源生成器的逻辑。

关于record泛型约束的支持计划 #

目前C#语言团队已经有相关的提案，目标是支持对泛型参数使用with表达式，而非专门增加record类型约束——因为C# 10之后with表达式已经支持所有值类型，未来的约束语法会覆盖所有支持with操作的类型，目前提案还在讨论阶段，尚未确定落地的版本时间。

为什么没有给record生成特殊接口支持泛型with #

主要有三方面的原因：

1. 优先级问题：record特性刚推出时核心目标是简化不可变数据类型的定义，泛型场景的支持没有纳入第一期的开发范围
2. 兼容性问题：如果强制给所有record增加特殊标记接口，会影响record的类型兼容性，且后续with表达式扩展到值类型后，接口设计需要同时兼顾class和struct，复杂度大幅提升
3. 语义扩展性问题：with表达式的本质是克隆+属性赋值，不同类型的克隆逻辑可能存在自定义实现，通用接口很难覆盖所有场景，强行定义接口反而会限制未来的语法扩展。

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