先说说模板方法模式在C#里的一个常见误区——很多人以为只要用了抽象类，就算实现模板方法了。其实不然，这个模式的核心在于用抽象类把骨架固定下来，然后通过虚方法（virtual）让子类在细节上做文章。一旦用错了访问修饰符，或者调用的时机不对，整个模式就失效了。
模板方法模式在 C# 中不是靠语言特性强制实现的，而是靠抽象类 + 虚方法（virtual）+ 模板流程控制来达成的——用错访问修饰符或调用时机，模式就失效了。
为什么 abstract 和 virtual 必须分清
模板方法的核心逻辑很清晰：骨架固定，细节可变。骨架方法（也就是模板方法）必须保证不能被子类随意重写，这在C#里要么用sealed，要么干脆不提供重写入口。而子步骤呢，要么强制实现（用abstract），要么允许选择性覆盖（用virtual）。
实践中常见的错误有两个：一是把模板方法本身设为virtual，结果子类一重写，整个流程就乱了；二是把钩子方法（hook）写成abstract，导致那些可选的逻辑无法留空。
- 模板方法本体应定义在抽象基类中，且不加
virtual或abstract（默认不可重写） - 子步骤若必须实现，用
abstract void StepA() - 子步骤若可选（比如日志、清理等钩子），用
virtual void OnBeforeExecute() { } - 子类中重写必须用
override，且不能调用base.模板方法名()——否则会递归调用
TemplateMethod() 内部调用顺序决定行为一致性
模板方法的可靠性，完全取决于它内部对子步骤的调用顺序和条件分支。一旦顺序错乱——比如在验证前就执行业务逻辑，或者在异常后没调用Cleanup()——那就不叫“模板”，只是普通的继承而已。
这种模式在数据库操作、HTTP请求封装、文件导入流水线等场景中非常常见。
- 标准四段式建议：
Validate()→Prepare()→ExecuteCore()→Cleanup() - 所有步骤都应在模板方法体内显式调用，不要依赖子类自行调用父类方法
- 如果某步可能抛异常，
Cleanup()应放在finally块里，或用using+IDisposable管理资源 - 避免在模板方法中做任何
new具体类型实例的操作——这会破坏可替换性
别让 protected 变成 “public” 的遮羞布
模板方法模式非常依赖封装边界：子类能访问、能扩展，但外部不能随意触发中间步骤。所有子步骤必须是protected，否则使用者绕过模板直接调用ExecuteCore()，整个模式就形同虚设了。
如果你看到InvalidOperationException提示“未按预期顺序调用步骤”，往往就是因为外部代码误调了某个public的子方法。
- 所有
abstract/virtual子步骤，一律用protected修饰 - 模板方法本身可以是
public（供外界调用），但绝不暴露子步骤给外部 - 如果需要对外提供“精简版”能力，应另写一个新模板方法，而不是开放原有子步骤
- 考虑用
internal配合[InternalsVisibleTo]测试项目，避免测试代码破坏封装
说到底，真正难的不是写对语法，而是判断哪些逻辑属于“不变骨架”、哪些该交给子类。比如连接字符串解析、重试策略、序列化方式，这些看着像细节，但在某些系统里恰恰是稳定部分；而看似核心的ExecuteCore()，反而可能是最常变的。
