核心是通过请求头（如X-Platform）驱动平台选择，用Protocol/ABC定义统一接口契约PlatformApi，各平台实现类遵循该协议；顶层依赖函数根据请求头返回对应实例，由FastAPI依赖注入系统自动完成路由与注入，业务代码仅面向协议编程，结合策略模式封装各平台差异逻辑，提升可维护性与可测试性。
核心思路是把“选哪家平台”这件事从接口逻辑里抽出来，变成由请求头（比如 X-Platform）驱动的依赖决策，而不是硬编码在业务函数里。
定义平台无关的统一接口契约
先抽象出所有外卖平台共用的操作能力，比如下单、查单、取消。不写具体实现，只定义协议：
- 用 Python 的 Protocol 或抽象基类（ABC）声明
PlatformApi，含place_order()、get_order_status()等方法 - 所有美团、饿了么、抖音本地生活等实现类都必须继承/实现该协议，确保调用方无需关心底层是谁
- 这样后续加新平台，只要补一个实现类 + 注册进选择逻辑，主流程完全不动
编写带 Header 路由的顶层依赖函数
这个函数是动态切换的开关，它不干活，只做判断和转发：
- 接收
Request对象或显式声明的X-Platform: str = Header(...) - 根据值（如
"meituan"、"eleme"）返回对应平台的实例，例如：return MeituanApiService() - 注意：每个平台服务本身也应是依赖注入项（比如自动注入自己的 SDK 客户端、配置、重试策略），保持层级清晰
在路由中声明依赖，而非手动 new 实例
把平台选择逻辑彻底交给 FastAPI 的 DI 系统，让框架在每次请求时自动执行判断：
- 路径函数签名写成：
def create_order(api: PlatformApi = Depends(get_platform_api)) - 框架会先运行
get_platform_api，拿到具体平台实例，再注入给api - 业务代码全程只跟
PlatformApi协议交互，干净、可测、无 if-else 分支
配合策略模式增强可维护性
依赖注入负责“选谁”，策略模式负责“怎么干”，两者天然契合：
- 每个平台实现类内部封装签名规则、字段映射、错误码转换、限流逻辑等差异点
- 例如美团需生成
sign和ts，饿了么用 JWT，抖音走 OpenID；这些细节全藏在各自实现里 - 测试时可轻松用 Mock 替换任一平台实现，验证主流程是否正确分发
