如果選擇用一段話來概括這篇文章，那可能是這樣的。
有時候做一個東西的時候潛意識地覺得自己沒做過，不熟悉，然後就立馬打開 Chrome 去搜，然而不巧網上的這方面的答案都隨波逐流走偏了，看似完美的實現了，實際背後埋藏着很大的坑，但匆匆一看，這就是你想要的，這時候，你的思路也就潛移默化地被帶偏了。
但當你泡好了茶，認真測試的時候，才發現，我靠，怎麼會有個 Bug，一陣抓狂之後就開始想着怎麼填上這個坑，於是一套自己認爲可以完美修復並且對用戶友好的方案就出來了，但當你再次準備好一切，正想怎麼去實現它的時候，無意間隨手又試了試一個自己的想法，剎那間，什麼都不一樣了，就多想了那麼一一點點 才發現自己很容易就能解決那個問題，根本不用什麼自己覺得複雜而且對用戶友好的設計，最後就剩吐槽網上的答案了。
想如果你還感興趣，那就繼續滑吧。
想必你應該對這樣一個功能並不陌生。
可能你會想說這個問題不是很簡單嗎，沒錯，我當時也這樣想，實際做完後才發現，它是真的簡單。
大體的思路：對於自動 focus on 下一個輸入框，監聽 input 的事件，在用戶輸入滿足校驗條件以及限定的位數的時候，獲取下一個應該給聚焦的元素，然後調用 focus 方法。
然後對於這個需要監聽的 input 事件，想都沒想，就打開 Chrome了，連續看了四五六七八個解決方案，一致地推薦 onKayUp 是個完美的解決方案。
測試完畢，欣喜，提交。
然鵝，當我輸完第三個，我想直接回去修改上一個，才發現 Shift tab 根本回不去，如果想硬回，要不上鼠標，要不同時按個 Shift Tab Space 鍵。
像這樣：
然後第一反應是去網上試了五六七八個推薦用法的 Demo，原來都有這個問題，What？這些人都不修的嗎，終於找到一個Shift Tab 可以回去的，看了下描述，是用了一個 Toggle 來控制 自動跳轉的功能會不會被啓用。
仔細又測了一波，發現 Tab 的時候也有同樣道理的問題，如果我現在從第一個填到了最後一個，這時候發現都填的不對，但我就是想從第一個iput 開始修改，這時候 Shift Tab 是回不去的，無奈，用鼠標點擊了第一個input，修改完後，心想跳到第二個應該就可以再改了，然鵝，它直接給我跳轉到了第三個。
我在想，幸好，我這隻有三個 input需要實現自動跳轉，如果有七八九十個，那還不得給用戶表演個一系列跳轉動畫？
然後，就在這個坑裏掙扎，想着要怎麼跳出去呢，是不是需要監聽用戶使用了 Shift 還是 Shift Tab 還是鼠標呀，你根本不知道用戶是怎麼樣在你的頁面點點點一通的。
冷靜下，仔細思考下怎麼樣才能儘可能地讓用戶收益於這個自動跳轉功能，還不會被它帶來的副作用 block 呢。
於是，就有了這樣一張圖，還和其他同事討論了一下這方案，都覺得可行，雖然看着有點略複雜，但這個問題百分百是要修的。
當做好所有準備，開始按這樣實現的時候。
想了一個問題，onKeyUp纔是罪魁禍首呀，當Shift Tab 按下的時候，就是因爲觸發了 keyUp 事件，所有根本跳不回去。我爲什麼不用 onChange？
冷靜了1分鐘，我爲什麼不用 onChange，？竟半天想不出答案。
實錘了一波，簡直完美。這裏有 Demo，感興趣可以點一點，哈哈。
還想了想這樣用是不是有什麼別的坑，因爲百分之九十九的答案都是 onKeyUp。 但我想說，真的是不對的，要不是賬號有經驗限制，真想每個都評論一遍問下作者這個問題。
其實一開始真的覺得很浪費時間，自己幹嘛不多想那麼一下，如果一開始沒有去搜，直接用了 onChange，是不是就根本沒有這個問題，但換了個思路想，如果沒有搜，也不會知道網上的這些一模一樣所謂正確的答案原來都是有問題的，那也就不會有坐在這裏一字一句地把件事情記錄下來，讓更多的人意識到這個問題，也提醒自己以後不要犯類似的錯誤。
也許，這就是生活吧。
少走了彎路，也就錯過了風景。