使用requests处理API的JSONL流：拼接不完整行失败求助

我完全懂你遇到的痛点——用iter_lines()延迟高，换成iter_content()又要手动处理断行，之前零散的if判断逻辑总是顾此失彼对吧？别慌，咱们用缓冲区+分块分割的思路就能完美解决，这是处理流式JSONL最可靠的方式之一。

核心思路 #

维护一个字节缓冲区，每次拿到新的Chunk时：

1. 把缓冲区里的剩余内容和当前Chunk拼接
2. 按换行符\n分割成多行
3. 把最后一行（大概率不完整）放回缓冲区，等待下一个Chunk补充
4. 对前面所有完整的行进行JSON解析和业务处理
5. 流结束后，别忘了处理缓冲区里剩下的最后一行内容

完整实现代码 #

import requests
import json

def process_jsonl_stream(api_url):
    # 初始化字节缓冲区，存储上一个chunk遗留的不完整行
    buffer = b""
    with requests.get(api_url, stream=True) as response:
        response.raise_for_status()  # 先确保请求成功
        
        for chunk in response.iter_content(chunk_size=1024*1024):
            if not chunk:
                continue  # 跳过空chunk
            
            # 合并缓冲区与当前chunk，处理跨chunk的行
            combined_data = buffer + chunk
            # 按换行符分割，得到所有候选行
            lines = combined_data.split(b"\n")
            
            # 最后一行可能是不完整的，放回缓冲区
            buffer = lines.pop()
            
            # 遍历处理每一行完整的JSON
            for line in lines:
                line = line.strip()
                if not line:
                    continue  # 跳过空行，避免解析错误
                
                try:
                    json_obj = json.loads(line)
                    # 这里替换成你的业务逻辑，比如存储、分析数据
                    print(f"成功解析JSON: {json_obj}")
                except json.JSONDecodeError as e:
                    # 捕获解析错误，方便排查问题
                    print(f"JSON解析失败，错误信息: {e}，行内容: {line.decode('utf-8')}")
        
        # 处理流结束后缓冲区剩余的最后一行（如果存在且非空）
        if buffer.strip():
            try:
                json_obj = json.loads(buffer)
                print(f"处理最后一行JSON: {json_obj}")
            except json.JSONDecodeError as e:
                print(f"最后一行解析失败，错误信息: {e}，内容: {buffer.decode('utf-8')}")

为什么这个方案比零散的if判断更可靠？ #

你之前用一系列if检测异常状态失败，大概率是因为没有系统性地维护缓冲区——比如换行符可能出现在Chunk的任意位置，或者连续多个Chunk都只包含行的一部分，零散的状态判断很容易遗漏边界情况。而这个方案通过合并-分割-缓存的流程，能覆盖所有跨Chunk的断行场景，逻辑清晰且不容易出错。

额外提示 #

• 如果API返回的是文本编码（比如utf-8），也可以把缓冲区换成字符串类型，但用字节处理更通用，避免编码转换的问题
• 可以根据API的实际返回调整chunk_size，1MB是比较均衡的选择，既不会太频繁处理Chunk，也不会占用过多内存

内容的提问来源于stack exchange，提问作者Keith Salmela