Node.js 本身并没有提供直接复制文件的 API，如果想用 Node.js 复制文件或目录，需要借助其他的 API 来实现。复制单个的文件可以直接用 readFile、writeFile，这样比较简便。如果是复制一个目录下的所有文件，目录下可能还包含了子目录，那么此时就需要用到更高级点的 API 了。
流是 Node.js 移动数据的方式，Node.js 中的流是可读/可写的，HTTP 和文件系统模块都有用到流。在文件系统中，使用流来读取文件的时候，对于一个大文件可能并不会一次性读取完，而是会分好几次读取完，读取的时候会响应数据事件，在文件没读取完的时候就可以对读取的数据进行操作。同理，在写入流的时候也和读取时一样，大文件并不会一次性写入。这种移动数据的方式是非常高效的，尤其是对于大文件而言，使用流比等待将大文件全部读取完再来操作文件要快得多。
忙碌的一年过去了，马上又要迎来同样忙碌的新年。在北京，加入了新的团队，认识了新的人，接触到新的事物，工作节奏比在上海明显要快，挺怀念上海的。
1.
展望马上过去的2013年，专业技术上正如前几天开团队总结会说的那样，并没有什么突飞猛进，一直在忙于实际项目的开发和打磨，纯技术性的研究反倒少了。不过眼界确实更开阔了，能更多的去思考产品本身，而不是局限于技术，期间有段时间还逢人便说自己是啥都干的打杂的。
刚加入360搜索团队时，图片搜索还刚刚起步，项目还显得有点简陋和粗糙。经过一年的努力，360的图片搜索与主要的竞品–百度图片搜索在功能上已是处于同一个量级了，在体验上，有些地方超越百度毫无压力。从最开始我们向百度学习，到现在百度在有些方面要反过来向我们学习。这期间，有人离开，也有人加入，大部分时间内，只有我一个前端，而百度的图片搜索前端团队有十来号人，对比下来，还是略有点成就感的。但我心里清楚，这其实还远远不够的，虽说人往往会否定掉自己的努力，但也正因为不满于现状，才能有继续前进的动力。
虽然之前有写过模拟浏览器拖拽行为的组件，但这种拖拽仅限于改变 DOM 元素的位置，只是 UI 层面的交互效果。最近在做的拖拽上传文件，拖拽时需要和服务端进行数据层面的交互，此时就需要用到浏览器原生的拖拽事件。
在高级浏览器中，DOM 元素都有一个 draggable 属性，用于标记其是否可以在浏览器中拖拽，常见的 a 、img 元素的 draggable 默认值为 true，浏览器默认其是可以拖拽的，而其他的布局元素如 div、p 这些默认并不支持拖拽，所以值是 false，如果想让其可以拖动，需要先将其设置成 true。
再来看看原生的拖拽相关的事件类型：
很多 WEB 开发者可能都会碰到这种头痛的问题，就是当用户对页面进行缩小或放大时，原本好好的布局就被破坏了。如果让网页支持自适应的缩小和放大布局，对于开发者来说是一个不小的挑战。
在我看来如果用户有意识的去对网页进行缩放，那么就应该知道缩放会破坏布局。还有很多用户其实压根不知道自己是何时对网页进行了缩放，此时就需要提醒用户应该将浏览器的缩放级别重置成默认的比例。
说到浏览器的缩放检测，可能有好几种方法都可以实现，从检测 CSS 样式到检测 Flash 的尺寸，可以说是各显神通，但我都觉得有点麻烦。其实还有更简便的方法的，当然各个浏览器的检测方法又有不同，对于 IE6，就直接无视了，因为 IE6 只能对文本进行缩放。
先来说说浏览器提供的标准检测接口，window.devicePixelRatio 是设备上物理像素和设备独立像素的比例，该属性就可以用于检测网页是否被缩放了。在普通的 PC 浏览器上，在默认无缩放的情况下其默认值是 1。可惜这么方便的属性目前只有 Firefox 支持。
见某网站的输入框支持截屏粘贴的功能，觉得有点意思，于是将代码扒出来分享下。
可惜，目前仅有高版本的 Chrome 浏览器支持这样直接粘贴，其他浏览器目前为止还无法粘贴( IE11没测试过 )，当然这种增强型的用户体验功能有总比没有好。
输入框的结构代码：
<input type="text" id="testInput" />
为输入框绑定粘贴事件：
var input = document.getElementById( 'testInput' );
input.addEventListener( 'paste', function( event ){
// dosomething...
});