百度API限流响应为429，Symfony2需手动实现请求监控、降级判断与本地兜底三层机制；识别时须同时校验状态码、响应体关键词及X-RateLimit-Remaining头；降级逻辑应置于service层，基于context参数控制，兜底数据建议用APCu互斥缓存并按ak隔离配额计数。
直接说结论：百度 API 的限流响应是 429 Too Many Requests，但 Symfony2 本身不内置限流感知与降级调度能力，必须手动注入「请求频次监控 + 降级分支判断 + 本地兜底逻辑」三层机制，否则所有重试都会原地打转甚至触发雪崩。
怎么识别百度 API 的限流响应
百度系接口（如翻译、OCR、地址解析）在超限时统一返回 429 Too Many Requests，且响应体中常带 X-RateLimit-Remaining 和 X-RateLimit-Reset 头。别依赖状态码就判定失败——有些百度接口在配额耗尽时会静默返回空数据或 500，实际需同时检查：
-
response->getStatusCode() === 429或response->getStatusCode() >= 500且response->getContent()包含"quota"、"limit"、"exceeded"等关键词 - 响应头是否存在
X-RateLimit-Remaining: 0 - 调用后立即查百度控制台配额使用率，确认是否真触达阈值（避免误判网络超时）
Symfony2 中 service 层如何写降级逻辑
降级不能塞在 controller 里——Symfony2 的 controller 生命周期短、无状态、难复用，一旦加了缓存或重试就会失控。正确做法是在 service 方法内基于 context 判断，并强制走纯内存兜底：
百度文档解析vlm-parser
下载
调用百度PaddleOCR‑VL大模型API，支持PDF、Word、PPT、图片等多格式文档解析，精准识别印刷体、手写体、表格、公式、图表、印章等复杂元素，支持100+语言，可处理不规则布局和跨页长文档。触发词：文档解析、VLM解析、大模型OCR、PaddleOCR、多模态文档、手写识别、公式识别、复杂版面。
- service 方法接收
$context = ['force_fallback' => false]参数（或从RequestStack提取），避免全局开关污染 - 主调用失败后，只对网络类错误降级：
strpos($e->getMessage(), 'cURL error') !== false或$e instanceof RequestException，参数错误（如400 Bad Request）绝不兜底 - 兜底函数必须无副作用：禁止调用
time()、rand()、file_get_contents()；推荐用预加载的静态数组或 APCu 缓存 - 示例结构：
public function getGeoLocation($address, array $context = []) { try { $response = $this->httpClient->request('GET', 'https://api.map.baidu.com/geocoding/v3', [ 'query' => ['address' => $address, 'ak' => $this->apiKey] ]); if ($response->getStatusCode() === 200) { return json_decode($response->getContent(), true); } // 检查是否限流 if ($response->getStatusCode() === 429 || (isset($response->getHeaders()['X-RateLimit-Remaining'][0]) && $response->getHeaders()['X-RateLimit-Remaining'][0] == '0')) { throw new RateLimitException(); } } catch (RateLimitException | TransportException $e) { if (!empty($context['force_fallback'])) { return $this->getFallbackGeoData($address); } } throw $e; }
APCu 缓存失效时怎么防击穿
百度接口返回的数据（如行政区划树、POI 分类）更新频率低，适合用 APCu 做本地缓存，但要注意过期瞬间的并发穿透：
- 不要用
apcu_fetch($key) === false就直接回源——高并发下多个请求会同时击穿 - 改用「互斥重建」：先尝试
apcu_add($key . '_lock', 1, 3)，成功者才去调用 API 并写入主 key；失败者 sleep(50ms) 后重试 fetch - 兜底数据也缓存：
apcu_store($key . '_fallback', $fallbackData, 3600)，确保降级路径本身不成为瓶颈 - 禁用
apcu_clear_cache()全局清空——只删指定 key，否则所有降级分支瞬间失效
最易被忽略的一点：百度 API 的限流是按 ak 统计，不是按 IP 或用户。如果你在 Symfony2 里用了多 ak 轮询，必须在 service 层维护每个 ak 的剩余配额计数器（存在 APCu 里），否则看似轮询，实则总有一个 ak 被打爆，其他 ak 还在闲置。
