banner

关于NodeJS在File System上的一些坑

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

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

nodejs

第一个坑,文件内容读取的异步和同步:

其实对于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);
    }
});


阅读: 9533
在同意共创许可协议(CC BY-NC-SA-4.0)的前提下,您可以转载本文。
橙色阳光
https://oss.so/article/69

相关阅读

留言评论

2条留言
李洋博客
博主发现一个问题。评论之后没显示,刷新之后才有啊。
李洋博客
我又来了。。。哈哈