样你都不能保证全对……
那么不仅大小写敏感、而且逻辑更为曲折复杂、容不得半点含糊的计算机程序呢？
因此，有bug漏洞那真的是无可避免。
当然还有一种情况，你的程序本身是无bug的；但支持环境比较坑……
这种正常来说不算程序bug，当然实践中，你可能没办法坐等os或者浏览器等厂商修改——所以结果就是你只好积极行动起来，在自己的程序里为别人的错误擦屁股……
这在业界被称为orkaround：orkaround-ikipedia。
正常来说，orkaround是临时的，并且，如果不是诸如0day之类特别关键、刻不容缓的问题，搞orkaround往往是出力不讨好的——因为它包含了丑陋，易错，含糊，难以理解；而且等os或者浏览器等的原始厂商修了它自己的bug，你原本好好运行的orkaround往往反而会引起问题。
尤其是，有时候os或者浏览器厂商修复速度比较慢、致使某种orkaround反倒成为“主流技术”；那么当“正统”修复方案和orkaround冲突时，os或者浏览器厂商往往不得不将错就错，以免捣毁那些用了orkaround的实现……
这类复杂情况暂不讨论，提它主要是为了说明，搞清楚bug的真正发生点是极为重要的。
修不到bug的根源、滥用orkaround，度过的是眼前的难关，牺牲的却是整个项目的稳固性。
类似的，尽量把程序写的“大众化”一点，没有必要不碰新特性，也可以在很大程度上避免
第四十二章 修复bug(2/4)