当然，也可以通过设置option的属性值，使用不同的配置来监听对应的文件，这里关于配置新的示例，就不再占用篇幅了，有兴趣的可以自己测试一下。
watchFile的源码实现
看完了示例，接下来就是源码了，只有了解了最根本的源码实现，才能更好更高效的使用对应的API，请认真看源码中的注释：
// Stat Change Watchers
// StatWatcher构造函数定义
function StatWatcher() {
//把EventEmitter内部的实例化属性添加到this对象上去。
//而EventEmitter的原型链属性和方法，不会被添加到this对象
//所以，基本上，也就是把EventEmitter实例中的domain,_events,_maxListeners这三个属性
//添加到了this对象上去了。
EventEmitter.call(this); //把this缓存到self变量中，便于下面的闭包回调使用该创建闭包时的this对象
var self = this;
//调用C++实现的StatWatcher构造函数，并把返回的对象，赋值到this对象的_handle属性上
this._handle = new binding.StatWatcher();
// uv_fs_poll is a little more powerful than ev_stat but we curb it for
// the sake of backwards compatibility
var oldStatus = -1;
//当C++中实现的StatWatcher实例化后的对象，定义它的onchange事件。
// 我测试过new binding.StatWatcher();实例化之后，是没有onchange属性的
// 所以，这里应该是属于直接定义改属性的，那么定义之后，在nodejs的C++代码实现中
// 是如何判断这个属性存在，然后在符合一定的条件下，又去执行这个属性的呢？
// 这是我疑惑的地方，这个需要当学习到更多这方面的知识后，再去了解一下。
// 经过我的测试，这个属性，是在实例的start执行时需要的，如果没有定义该属性
// 那么，在使用start方法，开始监听事件时，会被抛出异常的
// 抛出异常，是因为你监听的文件，当前不存在～～
// 如果监听的文件，当前已经存在，则不会执行onchange的回调
this._handle.onchange = function(current, previous, newStatus) {
// 当实例被话之后，当被监听的文件，被更改时，都会触发该属性的回调函数
// 并且传入三个参数
// 这里的三个判断，当前不知道为什么会在这个时候，不执行～～
if (oldStatus === -1 &&
newStatus === -1 &&
current.nlink === previous.nlink) return;
oldStatus = newStatus;
// 触发self对象的中的change事件，并且把current和previous对象，
// 传入到change事件的回调函数
// 在本构造函数内部，是没有继承EventEmitter构造函数原型链中的方法的
// 但是这里，却使用了原型链中的emit方法。why？
self.emit('change', current, previous);
