不可否认，如果对一项技术理解透彻了，那么对于项目中 bug 的调试，有着难以想象的好处。但是，我想即便项目中的功能都是你写的，但是对于其中一些技术，可能是你应该掌握的，可能是引入的第三方库，你不可能面面具到，什么都会，那么在工作中就需要分清楚主次，我明白你对于每一项自己不会的技术的狂热，以及热切的求知心情，但是这一切都需要你自己抽出时间来去学习，工作中，“取巧”是不可或缺的一项技术活儿。
就拿最近的一个 bug 而言：项目中需要对视频进行最长 30s 剪辑和压缩，于是集成了 ffmepg，开始学习 ffmpeg 的部分命令，命令如下：
cmd = "-y -ss 0：0：30 -t 0：1：0 -i " + currentInputVideoPath + " -strict -2 -vcodec libx264 -preset ultrafast " + "-crf 28 -acodec aac -ar 44100 -ac 2 -b:a 96k -s 540x960 " + currentOutputVideoPath;最终结果，你发现，压缩是成功的，但是剪辑下来却发现时常是 60s，其实写到这里会发现很蠢，因为 -t 0：1：0 这个命令指的并不是截取到哪个时间，而是截取视频总共的时长，或许可以安慰自己说，这在学习命令的时候其实是知道的，但是第一次使用 ffmeg，总会被命令的形式迷惑，对命令不熟悉。
但是，其实如果你再仔细一点，譬如，在播放压缩下来的视频的时候，一看到总时长 60s 就下意识的认为这是从 0s 到 60s 的视屏，而是认真的把得到的视频和源视频对比一下，你很清晰的就能看到，压缩视频的第一帧和源文件的第一帧是不一样的，那样你就能很快吧问题定位到是 -t 命令出了问题。
实际上，当发现压缩视频不是想要的 30s 时长，基于对不熟悉技术ffmepg 的敬畏之心，在不认真比对结果的情况下，你就开始猜想：是不是因为 ffmepg 的命令剪辑和压缩不可以一起做；是不是 ffmepg 的命令和 lib264 的库冲突了；还是命令的顺序不对…..于是在地铁上各种 google。
最终虽然确实没有占用你工作的时间，只是利用乘坐地铁的时间就解决了，但是却也耗费了两天，如果可以再仔细一点，对现有的可以直接用来比对的结果仔细排查，那么我想这些时间，你就可以更加深入的学习 ffmepg，或者看一两部好看的电影，或者听歌，这些都是非常好的。
对于程序结果和预期的不一样，不管是你熟悉的技术还是陌生的只是用一下的技术，你的切入点应该都是从结果入手，熟悉的技术可能还好一点，毕竟你懂，不慌不忙，但是陌生而艰难的技术，你就需要用结果来反推，问题是出现在哪里，从而找准切入点，从而节约自己的时间。
