partial类是C#编译期代码组织机制，要求所有部分均用partial声明、访问修饰符一致、泛型约束等仅限一处定义，跨程序集无效，不提供运行时能力。
partial 类不是“可选技巧”，而是 C# 项目里天天在用的基础设施——你只要用过 WinForms、WPF、Razor Pages 或 EF Core，就已经在和它打交道了。它不解决运行时问题，只解决代码组织和协作问题；用错不会报红，但会悄悄引入命名冲突、字段重复、逻辑丢失等静默故障。
partial 类声明必须每个文件都写 partial
编译器不认“同名类自动合并”。public class MyClass 和 public partial class MyClass 是两个完全独立的类型，哪怕它们在同一命名空间、同一程序集里。
- 所有文件中该类的声明都必须带
partial关键字，缺一个就编译失败：'MyClass' already defines a member called 'DoWork' with the same parameter types - 访问修饰符（
public/internal）必须一致；如果某一部分是public partial class A，另一部分写成internal partial class A，编译直接报错 - 泛型约束（
where T : class）、基类（: BaseClass）、接口实现（: ICloneable）只能出现在一个部分里（通常是主逻辑文件），其他部分再写会触发重复继承错误
partial 方法没实现=彻底不存在
partial 方法不是“可选重写”，而是“有实现才存在”。编译器会在 IL 阶段直接擦除未实现的 partial 方法签名和所有调用点。
- 声明：在 A.cs 中写
partial void OnSaving(); - 没实现：B.cs 里没写对应方法体 → 调用
OnSaving()的那行代码会被整个删掉，不报错、不警告、不执行 - 签名必须一字不差：返回值、参数类型、
ref/out、参数名（C# 12+ 要求）全得对上；加个public或virtual就算非法 - 常见用途是框架扩展点，比如 EF Core 的
OnModelCreatingPartial(ModelBuilder builder)，你没实现它，EF 就当它不存在，不会影响建模流程
生成代码和手写代码必须分开放
Visual Studio 设计器（WinForms/WPF/Razor Pages）和源码生成器（如 Source Generators）产出的 .Designer.cs 或 .g.cs 文件，本质就是靠 partial 和你写的 .cs 文件拼起来的。但它们是“只读区”。
- 永远不要在
Form1.Designer.cs里改控件事件处理逻辑或加字段——下次拖控件或保存设计器，整块内容被重刷覆盖 - 所有业务逻辑、自定义初始化、事件订阅，必须写在
Form1.cs这类非生成文件里 - 想在窗体加载后操作控件？别在构造函数开头写，要等
InitializeComponent()执行完；控件实例只有这时才真正创建 - 两个部分里都声明了
private string _cache;？编译通过，但实际是两个独立字段，读写互不影响——这是最隐蔽的 bug 来源之一
跨程序集无法扩展 partial 类
partial 只在单个程序集（.dll 或 .exe）内生效。A.dll 定义了 public partial class DataProcessor，B.dll 试图用另一个 partial class DataProcessor 去追加方法？编译器完全无视，当成全新类处理。
- 想让外部库扩展你的类型？用接口 + 扩展方法，或抽象基类 + virtual 方法，而不是依赖
partial - 源码生成器（Source Generator）可以跨项目注入
partial成员，但前提是生成的代码和目标类在**同一个编译单元**（即同一csc调用中），不是运行时动态加载 - 如果你看到某个 NuGet 包声称“支持 partial 扩展”，它大概率是靠 Source Generator 在构建时生成代码，而非让你手动写另一个 partial 文件
最容易被忽略的点是：partial 不提供任何运行时能力，它的全部价值都在编译期完成。一旦编译结束，它就和普通类毫无区别——这也意味着，调试时看不到“哪部分来自哪个文件”，反编译出来的也是完整类。所以别指望用它做运行时热插拔或条件编译，那是设计误用。
