吞噬新一代vs吞噬改变
他们之间有什么不同？
更新 ：
gulp.src(imgSrc) .pipe(newer(imgDest)) .pipe(imagemin()) .pipe(gulp.dest(imgDest)); 吞噬改变 ：
gulp.src(SRC) .pipe(changed(DEST)) // ngmin will only get the files that // changed since the last time it was run .pipe(ngmin()) .pipe(gulp.dest(DEST));
似乎吞噬变化更强大，因为它提供了一个选项
hasChanged: changed.compareLastModifiedTime
我希望现在回答这个问题还为时不晚。 我不得不在最近一个项目的源代码级别上对它们进行评估，这里是我的看法。
一饮而尽，更新
这个插件的核心是比较源文件和目标文件的修改时间（参见节点API ），以确定源文件是否比dest文件更新，或者根本没有dest文件。 这是插件中的相关代码：
var newer = !destFileStats || srcFile.stat.mtime > destFileStats.mtime;
吞掉改变的
这个插件在默认情况下也使用文件的修改时间来决定哪个stream通过
function compareLastModifiedTime(stream, cb, sourceFile, targetPath) {}
但通过提供一个选项来比较文件的内容SHA1哈希更进一步：
function compareSha1Digest(stream, cb, sourceFile, targetPath) {}
这些信息很好地logging在案 。
结论
所以从理论上讲，如果使用gulp-changed的默认值hasChanged: changed.compareLastModifiedTime ，那么每个插件的速度都相当快。 如果使用gulp-changed的hasChanged: changed.compareSha1Digest ，那么期望gulp-changed有点慢，因为它创build了文件内容的SHA1散列。 我没有基准，但我也有兴趣看到一些数字。
select哪一个
完全是因为它背后的开发者（sindresorhus）。 如果有一天这个可怕的人决定停止支持他的一大堆插件，我想我会停止使用吞咽。
不过，开玩笑说，gulp-change的源代码是咕嘟咕嘟的，而gulp-newer的源代码读起来就像是另外一个有很多承诺的节点模块的源代码。 所以另外一个吞咽改变的:)
巨大的编辑
Gulp-changed仅适用于1：1源：dest映射。 如果你需要很多：1，例如在使用gulp concat时，selectgulp-newer。
我可以build议gulp-newy ，你可以在你自己的函数中操作path和文件名。 然后，使用该函数作为newy()的callback函数。 这使您可以完全控制要比较的文件。
这将允许1：1或多比1。
newy(function(projectDir, srcFile, absSrcFile) { // do whatever you want to here. // construct your absolute path, change filename suffix, etc. // then return /foo/bar/filename.suffix as the file to compare against }
为了回答这个问题，你将不得不比较两个插件的源代码。
看起来，改变吞咽方式有更多的select，如你所说，更多的使用（下载更多的时间）和更多的贡献者，因此，它可以更多更新和重构，因为它被用得更多。
由于他们的文档，可以有所作为的东西。
在这个例子中，为了更新，它的用法如下：
gulp.task('default', function() { gulp.watch(imgSrc, ['images']); });
因此，似乎一旦这个任务正在运行，它只会注意到你使用这个插件时正在改变的文件。
他们改口说：“只会得到自上次运行以来发生变化的文件”。 所以，我没有尝试这个工作的例子，吞噬改变了进程的所有文件，然后只有那些自上次执行以来已经改变，所以似乎总是“看”所有文件和内部（md5哈希？否线索，没有检查源）决定而文件已经改变，自上次执行。 不需要一个观察者。
所有这一切，只是阅读他们的官方文件。
一个“野外testing”将非常受欢迎！
