用途：优化 Figma REST API 的调用性能。大型 Figma 文件可能返回数 MB 的 JSON，核心策略是只取所需数据、积极缓存并批量请求。
主要能力：
- 减小响应体积：用 depth 参数限制文件树深度（如 depth=1 只返回页面节点），或用 /files/{fileKey}/nodes 端点只取指定节点；仅在需要时使用 plugin_data、branch_data 参数。
- 响应缓存：用 lru-cache 缓存文件元数据（TTL 约 5 分钟）；图片 URL 30 天过期，缓存 TTL 建议设为 1 天以内。
- Webhook 驱动缓存失效：用 webhook 替代轮询，文件更新时删除缓存并主动重新拉取。
- 批量节点获取：/nodes 端点支持多个 ID，建议每批约 50 个。
- 连接复用：用 undici 的 Agent 复用与 api.figma.com 的 HTTP 连接，配合 Node.js 18+ 内置 fetch。
使用方式：需已有可用的 Figma API 集成，并了解自身访问模式（调用哪些端点、频率）。按步骤先减小载荷，再引入缓存、webhook 失效、批量获取与连接复用。示例命令：curl -s -o /dev/null -w "%{size_download}B %{time_total}s ${url}\n" -H "X-Figma-Token: ${FIGMA_PAT}" "https://api.figma.com/v1/${url}"。
适用场景：API 响应慢、大文件带宽占用高、需要降低请求数量的 Figma 集成。
限制与错误处理：缓存无失效会变陈旧，需用 webhook；缓存完整文件 JSON 可能内存溢出，应改用 depth=1 或 nodes 端点；图片导出慢可降低 scale 并按 50 个分批；缓存图片 URL 超过 30 天会失效，TTL 应小于 24 小时。具体收费、价格与平台支持情况暂未提供。