访问者模式适合哪些业务场景？

简化版

访问者模式适合对象结构稳定、操作经常变化的场景，例如编译器 AST 遍历、文件系统资源处理、组织架构统计、报表导出、规则校验、复杂对象树遍历等。它尤其适合对一组不同类型对象执行多种外部操作。

详细版

典型场景：

编译器 AST：语法树节点稳定，但分析、优化、生成代码等操作很多。
文件系统：文件类型相对固定，但压缩、扫描、导出、统计操作多。
组织架构：员工、部门、项目结构稳定，但统计、审计、报表操作多。
UI 组件树：节点类型稳定，但渲染、布局、导出、检查操作多。
规则校验：不同节点需要不同校验逻辑。

不适合场景：

元素类型经常新增。
操作很少且稳定。
对象封装要求很强，不适合暴露内部数据。
简单业务用普通多态或策略模式就够。

完整版教学

一、AST 是最经典场景

编译器或解释器中，代码会被解析成抽象语法树。节点类型包括变量、函数调用、条件语句、循环语句、字面量等。

这些节点类型通常相对稳定，但对 AST 的操作很多：类型检查、语义分析、代码生成、格式化、优化、解释执行。

访问者模式非常适合这种结构，因为每一种操作都可以成为一个访问者。

二、文件系统资源处理

文件系统里可能有 PDF、Word、图片、视频等资源。系统可能要做压缩、扫描、提取元数据、生成索引、转换格式。

如果把这些操作都写进文件类，文件类会膨胀。访问者模式可以把不同操作拆成不同访问者，让文件类保持相对稳定。

三、报表和审计场景

企业系统里经常有固定对象结构，如员工、部门、岗位、项目。业务上却经常新增统计维度：成本统计、绩效统计、权限审计、合规检查。

这些操作和对象本身不是同一个职责，用访问者抽出来会更清晰。

四、常见误区与工程判断

很多场景看起来像访问者，其实策略模式就够了。如果只有一种元素类型，只是算法不同，用策略模式更简单。

如果只是遍历集合做处理，也不一定需要访问者。访问者更强调“不同元素类型 + 多种操作”的组合。

工程中要警惕过度设计。访问者模式类比较多，简单业务硬套会让代码更绕。

五、如何判断一个场景真的适合访问者

判断访问者场景时，可以先问三个问题。第一，对象集合是不是相对固定，比如 AST 节点、组织结构节点、报表元素、文件系统节点。第二，围绕这批对象的操作是不是经常增加，比如校验、导出、统计、格式化、权限检查。第三，这些操作是不是不应该放进元素类本身，否则会污染领域对象。

拿编译器 AST 举例，节点类型如变量、函数、表达式、语句通常比较稳定，但对 AST 的操作很多：语法检查、类型推导、代码生成、格式化、静态分析。把这些操作都写进节点类，节点会变得非常臃肿；用访问者则可以每个操作一个 visitor。

如果场景里的对象类型今天加一种、明天删一种，例如快速变化的业务表单模型，就要谨慎。访问者不是看到“遍历对象集合”就用，而是看到“稳定结构上有多种外部操作”才用。

六、用工程约束检验答案

编译器 AST、固定单据类型的财务系统、文件资源分析都可能适用，但前提相同：节点类型相对稳定，格式化、校验、统计等操作持续增加。若一年新增 12 种节点却只新增 1 种操作，访问者通常不是好选择。

检查项	核心判断	工程含义
AST	节点类型稳定	类型检查、打印、生成代码
单据结构	单据种类受规范约束	审计、导出、汇总
资源树	节点集合固定	统计大小、权限检查

把关键关系压缩成一条可复述的路径：

先列元素类型变化记录
再列横向操作变化记录
比较两条变化轴与封装要求
最后决定访问者或普通多态

“对象很多”不是适用理由，“元素稳定而操作多变”才是可验证的判断标准。

落地前可以再按下面 3 步复核：

先说明“AST”的核心机制：节点类型稳定；再交代边界：类型检查、打印、生成代码。
接着分析“单据结构”：单据种类受规范约束；不能遗漏对应代价或结果：审计、导出、汇总。
最后用“资源树”检查方案：节点集合固定；验收时确认统计大小、权限检查。

这三项构成完整判断链：先讲清AST，再说明单据结构，最后用资源树检验实现是否越界。

面试中若能给出违反“统计大小、权限检查”的反例，再说明修正办法，答案就从模式定义落到了可验证的工程决策。

七、常见误区与追问

误区：只看到“AST”就认为方案成立。 必须同时说明核心机制“节点类型稳定”和工程边界“类型检查、打印、生成代码”。
误区：把“单据结构”当成无条件结论。 只有在“单据种类受规范约束”成立时，才能据此讨论“审计、导出、汇总”。
追问：DOM 一定适合访问者吗？ 不一定，要看节点类型是否稳定及已有遍历 API 是否已经满足需求。
追问：数据库实体适合吗？ 实体结构频繁演进时通常不理想，简单查询也没必要引入访问者。
追问：报表场景为什么常见？ 同一批稳定业务对象往往需要多种统计和输出操作。
追问：微服务跨网络能用吗？ 访问者是进程内对象协作模式，不能直接解决远程类型演化。
追问：何时应果断不用？ 元素类型高频增加、操作很少或访问者必须侵入大量私有状态时。

八、加强记忆

记忆时抓住这条主线：AST、文件树、组织结构是典型场景；元素结构稳定、外部操作多时适合；只有算法变化时，策略模式可能更简单；简单遍历不等于必须用访问者模式。面试回答先给出模式意图，再用调用链或数据流说明角色协作，最后主动交代适用边界与工程代价。

简化版

详细版