开发指南把架构约定落到可复制的实操步骤上。无论你是要为某个功能域接入一家新厂商、从零搭建一个全新域，还是只想在应用里消费一两家厂商，都能在这里找到对应的完整流程。
指南地图
四篇指南都建立在三层包模式之上：抽象层定义契约，厂商实现各自适配，聚合层提供一键注册。读任何一篇前，先确认你理解了这个分层。
四篇指南
| 指南 | 类型 | 适合谁 | 你将得到什么 |
|---|---|---|---|
| 新增厂商 Provider | 教程 | 贡献者 / 集成工程师 | 以 Payment 域接入 PayPal 为例，9 步走完一家新厂商的完整接入 |
| 创建全新的域 | 教程 | 架构师 / 贡献者 | 以 Captcha 域为例，从抽象包到聚合包搭起一个新功能域 |
| 单厂商消费指南 | 指南 | 应用开发者 | 只装一个厂商包，注入能力接口、处理 Result 的完整可运行示例 |
| 多厂商路由消费指南 | 指南 | 应用开发者 | 装聚合包，用 Resolver 按 Provider ID 路由的可运行示例 |
怎么选
我是贡献者，要给库加东西
按改动范围选：
- 只加一家厂商（如给 Payment 加 PayPal、给 FileStorage 加 OSS）→ 新增厂商 Provider
- 加一个全新的能力领域（如验签、即时通讯、推送）→ 创建全新的域
两条路线在「厂商实现包」这一步会汇合——新域建好后，往里加厂商的流程和给老域加厂商完全一样。
我是消费者，要在应用里用
按接入厂商数量选：
阅读约定
- 代码块里的
①②③是逐步骤的行内注释，对应正文里的操作要点。 - 所有示例都假设 .NET 8+ 与 Minimal API；项目实际支持 net5.0 / net8.0 / net10.0 三目标，写法完全一致。
- 金额、配额等数值字段在 Payment 域统一以「分」为单位（
long），避免浮点精度问题。 - 配置里的密钥不要进 Git，示例统一用
dotnet user-secrets或环境变量管理。
前置阅读
开始任意一篇前，建议先过一遍：
- 架构总览：建立全局观。
- 三层包模式：四篇指南的基石。
- Provider 目录与解析：多厂商路由的原理。
- 编码约定：命名、Options、错误处理的统一规则。
读完这些，下面的实操就不会有术语障碍。
下一步
挑一篇最贴近你任务的指南开始：
- 动手接入新厂商 → 新增厂商 Provider
- 设计一个新域 → 创建全新的域
- 马上跑通一次支付 → 单厂商消费指南