先记住这个答案
highWaterMark 参与决定流何时停止继续拉取或向写入方发出背压，通常是缓冲阈值，不是整个任务的严格内存上限。字节流与对象模式的计量不同，设置编码后还要核对字符串计量语义。增大阈值可能减少某些场景的调度或小块处理开销，也可能增加积压和尾延迟，尤其在多条并发链路中放大内存。应先定位实际瓶颈，再用固定负载比较吞吐、内存峰值和延迟，而不是使用一个适合所有流的数字。
- 阈值不等于总内存硬上限
- 对象模式按数量计量，单个对象大小仍重要
- 吞吐、内存和延迟需要一起比较
跨过阈值不等于数据被硬性拒绝
Writable 接收一块数据后可能返回 false，表示建议暂停后续写入，因此缓冲量可能达到或超过阈值。继续忽略背压写入会进一步积累数据，highWaterMark 本身不会替你建立整个系统的内存配额。
Readable 也可能因单次数据块大小或具体实现产生不同缓冲行为。除此之外，业务代码缓存的数组、解析对象和下游队列都占内存，不能只看一个流的阈值就估算整条处理链的峰值。
单位不同会让同一个数字含义完全不同
对象模式按对象数量管理相关阈值，但一个对象可以携带很大的字符串或缓冲。字节流通常按字节理解，调用 setEncoding 等操作后则要核对文档中的字符串计量差异，避免把所有长度都当成同一种单位。
Transform 的可读与可写侧还可能采用不同模式和阈值。例如输入为字节、输出为记录时，两个方向的数量不能直接比较；调优需要知道数据在哪一步膨胀，而不是只调整构造器里看到的第一个值。
用真实瓶颈决定是否增加缓冲
如果开销来自大量小块和频繁调度，适度缓冲可能提高批量处理效率；如果瓶颈是慢远端接口或昂贵计算，扩大队列通常只会让更多数据等待。应先记录消费者处理速度和队列增长位置。
对照实验应固定输入规模、并发和下游条件，同时记录吞吐、内存峰值与关键延迟，并检查错误和取消能否及时回收。只看到单条大文件传输变快，不能推断高并发交互请求也会受益。
容易答错的地方
- 把 highWaterMark 当作防止内存耗尽的总保险
- 阈值只参与流的背压机制，调用方仍可能忽略它或在流外累计数据。应限制任务并发、对象大小和额外队列，并确认消费者遵守背压，才能建立有意义的资源预算。
- 使用对象模式却按字节估算阈值
- 对象模式下阈值主要反映数量，少量大对象也可能占用大量内存。应测量实际对象规模和链路中的复制、转换成本，不能把阈值十六直接理解成十六字节或某个固定内存量。
面试官还会怎么问？
默认值是不是一直都是十六 KB？
不是，默认值会受 Node 版本和具体流实现影响，某些版本也调整过通用默认设置。应核对运行版本与实例属性，并说明可读、可写及对象模式，避免把一个历史数字当成所有流的永久契约。
减少阈值是不是总能降低延迟？
也不一定。更小缓冲可能增加调度和调用开销，吞吐下降后反而延长任务完成时间。应围绕目标交互和数据规模测试，区分首条结果延迟、稳态吞吐和整项任务耗时。
如何判断问题在流外的业务队列？
观察流自身缓冲长度、内存变化和业务待处理任务数量。如果流缓冲稳定而内存持续增长，可能是回调启动了无界异步工作或保存了全部结果，应检查生产节奏和对象持有关系。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。