北京
给一个两GB大小的CSV文件做一次过滤求和，听着像是十分钟就能写完的事情。先读文件，按行切开，循环取值，累加。代码不过四五行，跑个五兆样本丝般顺滑。可当直接把同样逻辑套到真实数据上时，Node直接抛出一句JavaScript堆内存溢出，哪怕顺手把--max-old-space-size改成八吉，也不过是让它多撑几秒再倒。这时候才顾得上去看，那几行代码到底在让机器干什么。
这件事里藏着一个很容易被忽视的真相：数据体量大，不等于内存占用就得跟着水涨船高。完全可以在物理内存远小于文件本身的情况下处理它。关键只有一个——永远不要让整个文件同时出现在内存里，而JavaScript原生的生成器函数恰好给了一条干净的实现路径，不必把代码写成回调地狱，也不需要手动维护状态机。
先把那个会爆炸的初版摊开来看。核心无非是先同步读文件fs.readFileSync，接着按换行符split切出一个大数组，再遍历每一行，取出指定列转为数字做累加。在小文件上这套逻辑无懈可击，可问题就出在第一行，而且是两个问题叠在一起。readFileSync会把整个文件不加保留地装进一个巨大的缓冲区，两GB的文件就是至少两GB的分配。紧接着的split再把这个缓冲区拆成一整个行字符串数组。如果数据有数百万行，等于在内存里同时驻留了几百万个字符串对象，每个对象都自带堆内开销，而且所有对象同时存活。一边是原始文件缓冲区，一边是完全展开的行数组，内存代价几乎翻倍。本身已经大到快要装不下的东西，又被加倍了一次。
为了看清这种膨胀有多离谱，可以做一个简化实验。拿一个结构为id、name、amount的CSV文件，填充两百万行，文件实际大小约四十五兆，离两GB远得很。用上面那套“全量加载”方案跑一遍，峰值常驻内存达到了238兆，处理一个45兆的文件就吃掉了超过五倍的内存。把这个比例等比放大，同样结构的2GB文件当场就要向系统要超过10GB的内存，而绝大多数容器的上限根本到不了这个量级。最初那个崩溃，其实在实验里就已经把结局写死了。
跳出代码本身重新想一下：做一次列求和，真的有哪一刻是需要把所有行同时捏在手里的吗？不需要。读一行，把数字抽出来，加到当前汇总值上，然后这行数据就可以立刻扔掉，不再回头。在整个计算过程里，第1行和第1400行永远不需要知道彼此的存在。内存的职责只是暂时抱住当前正在处理的那一小截字节，而不是替整个文件兜底。把这个逻辑翻译成代码，就是一边读一边算一边释放，而生成器函数正好让这种“每次只吐一行”的流式处理变得跟写同步循环一样自然。
这场内存爆雷说到底，是思维惯性把“读取文件”直接等价成了“把文件全部抓进内存”，紧接着又把“按行处理”等价成了“把所有行展开成数组”。一旦打破这两个条件反射，哪怕再大的文件也不过是一串可以边走边消费的字节流。Node生态里的流、迭代器、生成器，其实早就给好了这种消费方式的拼图，所缺的，往往只是在动手写代码之前多问一句：我到底需要同时看见多少数据。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
