呐,说血案其实夸张了,只是一个锅而已。上个月接回了一个垃圾项目:营销中心。交出去少说三年多了吧,依然没解决历史遗留的队列卡死的问题。

顺手在小版本的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    = "https://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才是真的实力,其他都是浮云。


如您从本文得到了有价值的信息或帮助,请考虑扫描文末二维码捐赠和鼓励。

尊重他人劳动成果。转载请务必附上原文链接,我将感激不尽。


与《JavaScript indexOf引发的血案》相关的博文:


4
留言

avatar
😀
😀😁😂😅😭🤭😋😘🤔😰😱🤪💪👍👎🤝🌹👌
leevare
leevare
【🚶访客】

比起indexOf我更喜欢用includesincludes更符合直觉😂

加斯特
加斯特
【🚶访客】

請問究極之月的解壓密碼有換嗎?
我複製貼上了密碼還是不對