xsv真正低内存的流式命令包括：xsv count和headers（几乎零内存）、select和search（恒定内存流式过滤）、slice（无索引时跳行不加载全表，有索引可直接定位）；而sort和table属高内存命令，需慎用。
为什么直接 cat large.csv | head -n 1000 不算流式处理？
它只是截断输出，没做任何解析或转换。真正流式处理的关键是：数据从磁盘读出后，**边解析边传递，不缓存整份结构化结果**。一旦你用 awk、sed 或 xsv 做字段提取或过滤，就进入了流式处理范畴；但若后续接了 sort 或 jq 全量消费输入，就可能打破流式链——尤其 jq 默认会把整个 JSON 数组加载进内存。
xsv 流式命令选哪几个才真低内存？
xsv 是少数真正为超大 CSV 设计的命令行工具，它的内存表现取决于具体子命令：
-
xsv count和xsv headers：几乎零内存，只扫文件头或逐行计数 -
xsv select和xsv search：流式过滤，内存恒定（仅当前行+匹配缓冲） -
xsv slice：无索引时仍需跳过前 N 行，但不加载整表；有索引后可直接定位，更快更省 -
xsv sort和xsv table：高内存命令，sort必须全量读入才能排序，慎用
实战建议：先 xsv index data.csv，再用 xsv slice data.csv -s 500000 -l 10000 提取中间段，比 tail -n +500000 | head -n 10000 更准（后者会错行，尤其含换行符的字段）。
用 csvsql 或 q 时怎么避免 OOM？
csvsql（来自 csvkit）和 q 都是 SQL 接口查 CSV 的工具，但行为差异很大：
QuickBooks Mileage CSV
下载
使用 qbo-mileage CLI 及用户凭证，从 Airtable、Outlook 或 Google Calendar 记录生成 QuickBooks Online 里程 CSV 文件。
-
q默认流式执行，SELECT * FROM data.csv LIMIT 10只读前 10 行，内存可控 -
csvsql --query "SELECT * FROM stdin LIMIT 10" data.csv看似一样，但底层会先把整个 CSV 加载为 SQLite 表，百万行就可能吃掉 1GB+ 内存 - 如果必须用
csvsql，加--no-inference跳过类型推断，并配合--max-column-size限制字段长度，能缓解部分压力
注意：q 不支持嵌套查询或 JOIN 多文件，复杂逻辑仍得靠分步 select + 临时文件。
Python 脚本里调用命令行工具，如何防止管道阻塞？
用 subprocess.Popen 管道组合多个流式命令时，常见卡死不是因为数据大，而是子进程缓冲区满后挂起等待读取——尤其当上游快、下游慢时：
- 永远给
stdout=subprocess.PIPE配合stderr=subprocess.STDOUT，避免 stderr 占满缓冲区导致阻塞 - 不要用
.communicate()一次性收全部输出；改用iter(proc.stdout.readline, b'')逐行读取 - 对
xsv select这类快速命令，可在 Python 中用os.set_blocking(fd, False)防止 read() 阻塞，但更稳妥的是用select.select()监控可读性
最易被忽略的一点：Windows 下默认管道缓冲区只有 4KB，Linux 是 64KB，跨平台脚本务必显式设置 bufsize=1 或使用 text=True 触发行缓冲。
