用途：为不同规模的 HubSpot CRM 集成选择并落地架构方案，覆盖从嵌入式客户端到专用 API 网关的三种已验证模式。
主要能力：
- 变体 A 嵌入式客户端：适合 MVP、小团队、少于 1 万联系人、每日少于 5 万次 API 调用。在路由处理器中直接使用 @hubspot/api-client 单例，代码简单、一次部署；缺点是缺少故障隔离，HubSpot 延迟进入用户请求链路。
- 变体 B 服务层加异步队列：适合成长型团队、1 万至 10 万联系人、每日 5 万至 30 万次调用。通过服务层封装 HubSpot，加入 Redis 缓存与 Bull 队列，写操作入队异步处理，返回 jobId；优点是故障隔离、响应快、可缓存与后台处理，代价是复杂度上升、依赖 Redis、需运行两类进程。
- 变体 C 专用 HubSpot 网关：适合企业级、10 万以上联系人、多个服务需访问 CRM。网关独立部署，提供 gRPC 或 REST 接口，集中处理限流、缓存与熔断，多个服务共享缓存与速率配额；代价是网络跳转、运维复杂、需管理接口契约。
使用方式：先评估团队规模、每日 API 调用量、部署基础设施与同步需求（实时或批量），再按决策矩阵选型。迁移路径为：嵌入式到服务层，先抽取客户端到 services/hubspot/，加 Redis 缓存，再把写操作移入后台队列；服务层到网关，先抽为独立服务，定义 gRPC/REST 契约，加集中限流器，再逐个迁移服务。
适用场景与限制：资料给出决策矩阵，按团队人数（1-3、3-15、15+）、联系人数、使用 CRM 的服务数、同步模型、缓存方式、限流管理、故障隔离与构建时间区分。常见问题包括过度设计、多服务共享限流、缓存不一致与网关单点故障，对应建议为从嵌入式起步逐步演进、迁移到网关、按 webhook 事件失效缓存、运行多副本加 HPA。具体价格、平台支持与效果数据暂未提供。