内存溢出主因是未流式处理百度API大响应体、循环中滥用HTTP客户端及Doctrine实体管理器。应启用stream参数分块读取、及时flush/clear、精简API字段并优先校验status。
不是 Symfony2 本身调用百度 API 导致内存溢出，而是你在循环中反复创建 HTTP 客户端、未释放响应体、或一次性读取超大响应体（比如地图瓦片、OCR 全图结果、大批量地址解析返回），触发了 PHP 内存耗尽。Symfony2 已于 2015 年停止维护，但问题本质和现代 Symfony 一致——关键在资源生命周期管理，不在框架版本。
为什么 file_get_contents 或 curl_exec 会爆内存
直接调用底层函数发请求时，PHP 默认把整个响应体加载进内存。百度 API 返回的 JSON 若含 Base64 图片、长文本或批量结果（如 1000 条地理编码），单次响应就可能超 50MB。
- 不设
max_execution_time和memory_limit，脚本卡死前先 OOM - 用
file_get_contents('https://api.map.baidu.com/...')无流式处理，等于强制全量加载 - 没检查
$http_response_header就解析 body，错误响应（如 500+）体内容杂乱，JSON 解析失败后变量残留
用 GuzzleHttp\Client 但没配流式响应
Symfony2 可通过 Bundles 引入 Guzzle 5/6，但默认 request() 仍把 body 当字符串返回。你得主动启用流式处理，尤其对大响应。
百度热榜监控 | Baidu Hot Topics Monitor. 获取百度热搜榜、搜索趋势、关键词热度 | Get Baidu trending searches, trends, keyword popularity. 触发词：百度、热搜、baidu.
- 加
['stream' => true]参数，返回StreamInterface对象而非字符串 - 用
$response->getBody()->read(8192)分块读，配合fwrite()直接落盘或逐段解析 - 别写
json_decode($response->getBody()->getContents())——getContents()会把整个流读进内存
$em->persist() 在循环里没 clear() 和 flush()
如果你调用百度 API 后把结果存进 Doctrine 实体（比如批量插入 POI），在 for 循环里反复 persist() 却不清理上下文，实体管理器会持续持有全部对象引用，内存只增不减。
- 每处理 100 条，执行
$em->flush(); $em->clear(); - 避免在循环内调用
$em->getRepository()->find()—— 这会额外加载实体并加入管理器 - 改用原生 SQL 插入（
$conn->executeStatement()）绕过 ORM 开销，适合纯写入场景
百度 API 响应体过大？先砍字段再请求
百度多数 API 支持 output=json 和精简字段参数。不查坐标就别要 precise，不要详情就关掉 extensions=all。
- 地址解析接口加
&ret_coordtype=wgs84ll&callback=none避免 JSONP 包裹 - IP 定位接口用
&coor=bd09ll替代默认的 GCJ02，减少坐标转换开销 - 用
curl -I测响应头：若Content-Length: 12456789，说明服务端已预计算大小，必须流式处理
最易被忽略的是：百度 API 的错误响应（如 status=302 或 message="QUOTA_EXCEEDED"）体内容往往比正常响应还大，且结构不一致。不先检查 status 字段就硬解析，会导致无效内存占用和静默失败。
