关于NodeJS在File System上的一些坑

有一个多月没写博客了，这段时间挺忙的，也不知道写点什么分享，本来打算分享写的mapbox经验，但都是一些api调用，所以就算了。

今天突然想起了一些关于NodeJS的坑，主要是File System上的。在不久前，我写了一个基于Nodejs的图片采集程序，其中难免会用到NodeJS的FS组件。

第一个坑，文件内容读取的异步和同步：

其实对于NodeJS的FS组件来说，读取文件是相对简单的。

对于什么时候用异步，什么时候用同步，我的理解比较直接。

既然NodeJS的优势就是异步，那么除了必须得到文件信息以后，才能执行的地方，能用异步就用异步了。

第二个坑，文本文件内容的新增：

在FS组件中，最大的一个坑就在这里了。这操作涉及新建、保存、删除，还要区分文本操作和图片操作。

文本操作，在刚开始的时候，坑点在新增内容上。存在文件的方法有很多种，我把用的方法内容放出

if (type=='new') {
    type = 'a';
} else {
    type = 'w';
}
fs.writeFile(savepath,content,{flag:type},function(err){
    if (err) {
        console.log(err);
        callback(false);
    } else {
        callback(true);
    }
});

新增内容中比较大的坑点，文件存储的频率越高（或者文件存储的大小越大），存储的速度越慢。而且，如果上一次还没保存成功，第二次保存的请求又来了，会导致严重报错。

所以，必须要在上一次的存储完成后，第二次的存储才能继续进行。至于如何设计存储逻辑，就看存储的提交方式了。按照我的思路来，我会把提交的存储请求放到数组中。按照顺序执行存储任务，存储任务打开后，设置状态status=pending。如果有pending状态的任务，那么就不执行第二次存储请求。如果有同一个文件的存储任务提交多次，保留pending和最后一次提交。如此，就能保证文件存储成功。

第三个坑，图片文件的保存：

图片存储相对于文本文件来说，较为麻烦的是编码方式。网上能提供一堆的辅助组件，所以转换编码的方式我就不额外说了。

主要解决保存远程图片的坑，用的是superagent直接访问图片文件，然后这个组件会自动转码，将返回的res.body保存即可。

fs.writeFile(savefile,res.body,function(err){
    if (err) {
        console.log(err);
        callback(false);
    } else {
        callback(savefile);
    }
});