访问者模式在c#中的核心约束是被访问元素必须预先实现accept方法并调用visitor.visit(this)，否则无法支持标准双分派；若元素不可修改，则需采用dynamic或expression tree等变通方式。
访问者模式在 C# 中的核心约束是什么
访问者模式不是“想加就加”的设计，它要求被访问的对象结构（元素）必须预先声明对访问者的支持——也就是每个元素类型都要实现 Accept(IVisitor visitor) 方法，并在内部调用 visitor.Visit(this)。如果已有类层次无法修改（比如第三方库类型），直接套用标准访问者模式会失败。
方式一：标准双分派实现（需修改元素类）
这是 GoF 原始定义的写法，依赖 C# 的虚方法 + 重载联合实现运行时双分派。关键点在于：Visit 方法重载按具体元素类型区分，而 Accept 调用触发第二次分派。
-
IVisitor接口要为每种具体元素（如Book、Video）声明对应Visit(Book book)、Visit(Video video)方法 - 每个元素类（如
Book）必须实现Accept(IVisitor v)，且内部写死v.Visit(this)—— 不能用v.Visit((dynamic)this)替代，否则失去编译期类型检查 - 新增元素类型时，要同步修改
IVisitor和所有已存在访问者实现，违反开闭原则；这是该方式最常被吐槽的硬伤
public interface IVisitor
{
void Visit(Book book);
void Visit(Video video);
}
<p>public class Book { public void Accept(IVisitor v) => v.Visit(this); }</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill2795" title="C#"><img
src="https://img.php.cn/upload/skill/000/000/081/178936933912641.jpg" alt="C#" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill2795" title="C#" class="overflowclass">C#</a>
<p class="overflowclass">"避开 C# 常见错误——空陷阱、异步陷阱、LINQ 陷阱及资源泄漏。"</p>
</div>
<a rel="nofollow" href="/xiazai/skill2795" title="C#" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
方式二：使用 dynamic 绕过接口爆炸（不改元素类但牺牲类型安全）
当无法修改元素类，或元素类型太多导致 IVisitor 接口膨胀严重时，可用 dynamic 把分派逻辑移到访问者内部。此时元素只需统一提供 Accept(dynamic visitor) 或直接暴露给外部调用。
- 元素类无需实现多个
Visit重载，只要有一个通用入口，例如public void Accept(IVisitor v) => v.Visit((dynamic)this) - 访问者中
Visit方法用dynamic参数接收，再靠运行时绑定调用具体处理逻辑，例如public void Visit(dynamic item) => item switch { Book => HandleBook(item), Video => HandleVideo(item), _ => throw new NotSupportedException() }; - 丢失编译期类型检查，拼错类名或属性名会在运行时报
RuntimeBinderException，CI 阶段难捕获 - 性能比虚方法调用低约 3–5 倍，高频遍历场景需实测
方式三：Expression Tree 或反射模拟双分派（延迟绑定，可控性强）
适用于需要动态注册新元素类型、又不愿用 dynamic 的场景。本质是把 “方法重载匹配” 这件事从编译期搬到运行期，用 Expression.Call 或 MethodInfo.Invoke 构建调用链。
- 维护一个
Dictionary<type action object>></type>映射表，键为元素类型，值为该类型对应的visitor.Visit(xxx)调用委托 - 首次遇到某类型时，用反射获取其
Visit方法并编译成委托缓存；后续直接调用委托，避免重复反射开销 - 新增元素类型只需注册一次委托，不用动接口或基类，比方式一更符合开闭原则
- 首次调用有轻微冷启动成本，但后续性能接近虚方法调用
真正难的是权衡：方式一最“规范”但僵化，方式二最快上手却埋雷，方式三灵活但代码量翻倍。实际项目里，如果元素结构稳定且可控，选方式一；如果集成大量外部模型，方式二+单元测试兜底更现实；只有在插件化、热加载等明确需要运行时扩展的场景，才值得投入方式三。
