呐，说血案其实夸张了，只是一个锅而已。上个月接回了一个垃圾项目：营销中心。交出去少说三年多了吧，依然没解决历史遗留的队列卡死的问题。
顺手在小版本的shell里加了几句代码，解决掉这个由来已久的历史问题。这回没有吐槽什么，毕竟既然项目到我手里了，那发现的问题就全部都解决掉即可。
回到题目《JavaScript indexOf引发的血案》，起因是驻地反馈，营销中心添加的活动，从A看吧跳转到B看吧，B看吧跳到活动页，之后返回，直接返回到了A看吧，驻地预期是返回到B看吧才对，遂怀疑是营销中心的Bug~然后从1月13日邮件报障，来回往复，持续了一天多，原营销中心的研发也给不出个所以然来。
实在看不下去了，通过驻地提供的封包数据取得入口，挂上Fiddler，替换L4地址（总部不通驻地L4）为具体Portal内网IP，人工浏览器复现问题。
思路很简单：这个模块已经很久没有变过了，如果这是营销中心的锅，那问题早该暴露了，而不是等到今天才发现，那么，问题肯定在更上层，既然不是我的问题，这锅必须稳准狠的甩出去，毕竟我组实力摆在这里。
果然，翻到B看吧跳转的代码时，发现了端倪：
bjf.focus.eventDefault.ok = function () {
var ele =this.data.ele;
var focustemp = bjf.focus.getHistory();
var url=bjf.getAttribute(ele,'url');
if(url.length > 0) {
var record=1;
if(url.indexOf('play/')!==-1 || url.indexOf('playproxy/')){
record=0;
}
bjf.storage.pageSet('focusCoordStr', focustemp);
document.forms[0].cur_trailer.value=cur_trailer;
vis_to_rewrite(url, focustemp, record);
}
};
红色位置的代码，就是问题所在。
盲猜，看吧的研发的逻辑预期是：只有url包含play或者playproxy的时候，才不记录历史（record=0;）。
但是呢，实际上这逻辑哪怕url没有包含play和playproxy，也不记录历史。
代码抽离后随便赋值举个例子：
var url = "http://127.0.0.1/id/123";
var record = 1;
console.log(record);
console.log("url.indexOf('play/'):", url.indexOf('play/'));
console.log("url.indexOf('play/')!==-1:", url.indexOf('play/')!==-1);
console.log("url.indexOf('playproxy/'):", url.indexOf('playproxy/'));
console.log("url.indexOf('play/')!==-1 || url.indexOf('playproxy/'):", (url.indexOf('play/')!==-1 || url.indexOf('playproxy/')));
if(url.indexOf('play/')!==-1 || url.indexOf('playproxy/')){
console.log("8:", record, "set record=0");
record = 0;
} else {
console.log("10:", record);
}
console.log("Fin:", record);
控制台运行结果：
1
url.indexOf('play/'): -1
url.indexOf('play/')!==-1: false
url.indexOf('playproxy/'): -1
url.indexOf('play/')!==-1 || url.indexOf('playproxy/'): -1
8: 1 set record=0
Fin: 0
走到if直接进去了。false和-1取或，是个啥？是-1，if中-1条件会判定啥？是ture。
锅至此就甩好了，研发js逻辑写的有问题。那么如何规避呢？事实上，indexOf这个方法，只有找不到的时候是-1，其他情况必然大于-1。所以但凡前端基础好一点，判定就应该写成url.indexOf('play/')>-1这样。
当然，为啥if(-1)是true这个问题，我发现的时候也有点迷糊，遂一边问群里前端的同学一边谷歌了一下。还是自己天真了，if的判定里只有0和false才会走到else😂。
回顾自己写过使用indexOf的方法，天然就用了>-1的判定~对方法返回值的敏感还是有的。
程序世界就是这样有趣，靠经验想当然是会碰壁的，实际解决问题、少写Bug才是真的实力，其他都是浮云。
如您从本文得到了有价值的信息或帮助，请考虑扫描文末二维码捐赠和鼓励。
如本文对您有用，捐赠和留言 将是对我最好的支持~（捐赠可转为站内积分）
如愿意，请向朋友推荐本站，谢谢。
尊重他人劳动成果。转载请务必附上原文链接，我将感激不尽。