
关于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); } });