模板方法模式在C#中需用抽象类定义骨架，模板方法本身不加virtual/abstract（默认不可重写），强制步骤用abstract，可选钩子用virtual；所有子步骤必须protected，调用顺序须严格固定于模板方法体内。
模板方法模式在 C# 中不是靠语言特性强制实现的，而是靠抽象类 + 虚方法（virtual）+ 模板流程控制来达成的——用错访问修饰符或调用时机，模式就失效了。
为什么 abstract 和 virtual 必须分清
模板方法的核心是“骨架固定、细节可变”。骨架方法（即模板方法）必须是 final 语义（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()，反而可能是最常变的。
