本文來自微博差評君　　

　　你想想，你吃著泡面、哼著歌、還在網上沖著浪，突然就發現瀏覽器用不了了，這可多難受啊。當然啦，這可不是差評君在瞎帶節奏啊，因為這事還真有那么點可能會發生。

　　因為全世界最流行瀏覽器之一的 Chrome，馬上就要發布第100個版本了。而這次更新，很可能會引發一些 BUG，導致網頁直接打不開。

　　沖浪板要是壞了，這可讓咱們怎么沖浪啊？

　　Chrome 大伙們可再熟悉不過了，這款有內存吞噬者之稱的瀏覽器，在這顆行星上有超過 20 億的裝機量。

　　至少在編輯部，除了少數幾個 Safari 用戶外，Chrome 的覆蓋率沒有 9 成也有 8 成。而剩下的也大都是在用各種 chromium “套殼”瀏覽器。

　　那么問題就來了，別人的軟件更新不是內置個虛幻引擎，加些新功能，就是修復一些 BUG，讓產品更加穩定。

　　Chrome 你這個坐擁數十億的大咖咋一更新，反而修復了 “ BUG 過少的 BUG ” 呢？

　　這不是把用戶做寶搞嗎？

　　其實啊，這鍋還真怪不到谷歌的工程師身上，引發這一場 BUG 的，是一個名叫版本號的東西。

　　因為在某些網站的眼里，版本號 100 竟然小于 40。

　　接下來就請準備好薯片和可樂，差評君這就和大伙們講講，這道火鍋都能做對的比大小題目背后、這個讓大伙們可能上不了網的 BUG 背后，究竟發生了什么。

　　簡單地說，當你訪問某某小網站時，網站是需要知道你用的是啥瀏覽器和啥版本的。

　　一方面，網站就能向那些用最新版瀏覽器的用戶展示新功能、新交互，反過來對那些“古董”瀏覽器提供適合它們的內容。

　　就像 IE9 之前的 IE 瀏覽器不裝插件的話，是不支持 SVG 功能的。而對如今的各大瀏覽器來說，SVG 早已經算是個平平無奇的玩意兒了。

　　在另一方呢，出于網絡安全的考慮，網站還能根據版本號，直接拒絕那些早就不更新的瀏覽器訪問網站。

　　總得來說，網站要知道 “來者是何人”，然后再決定就接不接客，并在接客之后看碟下菜。

　　而這次 Chrome 瀏覽器即將帶來的版本號為 100 的更新，就很可能讓一部分網站認錯客人，然后直接把用戶拒之門外。

　　就拿能差評君所用的 Chrome 瀏覽器為例，網站會通過檢查以下的瀏覽器 UA（ 用戶代理字符串 ）來查一波戶口：

　　Mozilla/5.0（ Windows NT 10.0； Win64； x64 ） AppleWebKit/537.36 （ KHTML ， like Gecko ） Chrome/97.0.4692.99 Safari/537.36 

　　這里面的東西很多，我們要找的是 Chrome/97.0.4692.99 這一段。

　　對于大部分的網站開發者來說，他們只需要關注緊接著Chrome/后的字符 “ 97 ”，其實就足夠網站辨別瀏覽器身份，并根據版本看碟下菜了。

　　而巧就巧在，一個國外小有名氣，名叫 Duda 的網頁設計工具包它更懶。

　　因為它只讀取 Chrome/背后的兩個數字。。。

　　所以在 Chrome 瀏覽器的版本號升到 100 之后，在訪問那些用 Duda 開發的網站時，認字只認一半的它們會以為你的版本號是 10。

　　更搞人心態的是，Duda 還會自動屏蔽版本號低于 40 的 Chrome 瀏覽器訪問。。。

　　所以說在它們的眼里 100 = 10 < 40，你的瀏覽器就這樣被禁止訪問了。

　　雖然這一波無疑是 Duda 程序員的鍋，但是在某種程度上，Chrome 的程序員們其實也還是有那么一捏捏責任的。

　　而錯就錯在 Chrome 的程序員們太能爆肝了，從而導致 Chrome 的更新實在太勤快了。

　　這么說吧，今年已經 13 歲的 Chrome 在早期可是 12 周才更新一次，后來加快到了 6 周一次，到后面更是到了 4 周更新一次。

　　就這樣，Chrome 的版本號便迅速瘋漲，到今年的三月份也即將迎來第 100 個版本。

　　所以說 Chrome 的工程師要是多摸點魚，多擺點爛，這個 BUG 就不會這么早出現。

　　分完鍋，但問題總要解決吧。

　　早就發現可能會出現 BUG 的谷歌，在去年就提供了個測試 flag。

　　大伙們只要在瀏覽器中輸入 chrome ： //flags 然后輸入并打開 #force-major-version-to-100 就能讓網站打破兩位數的魔咒，強制顯示版本號為 100 了。

　　而老外的性情似乎也是調和折中的，因為還有網友提出了另外中庸的解決辦法。

　　那就是讓谷歌的版本永遠停在 99，之后的更新變后面的小數點就可以了。

　　只不過，這些人再怎么出謀劃策也都是 “皇上不急太監急”，要知道古話說的好：解鈴還須系鈴人啊！

　　好在真正的罪魁禍首 Duda 在不久發布了公告，表示已經更新了代碼，并解決了這個問題。

　　而在谷歌反饋 BUG 的網站上，這個問題也已經被標注為已修復（ Fixed ）。

　　而在 Chrome、FireFox 這些瀏覽器的版本號真正到達 100 之后，還有多少的類似 Duda 的 BUG 沒被發現，咱們就不得而知了。

　　只能說這個瀏覽器界的“千年蟲”問題，只是暫時得到了解決。

　　另外，記性比較好的差友應該還記得在今年年初，微軟公司也出過類似的千年蟲問題。

　　它讓微軟員工們的年都沒跨好。

　　這個 BUG 的大概劇情是在今年的 1 月 1 日當天，不少使用微軟 Exchange 的公司發現郵箱居然發不出去了。

　　背后的原因其實也相當簡單，那就是微軟用了一種名叫 “ yymmddhhmm ” （年年月月日日時時分分）的符號變量（ int32 ）來存儲時間。

　　而有符號的 int32 只能存儲 -2147483648 到 2147483648 的數據，也就是 2 的 32 次方那么多個。

　　原本在上世紀是為了節省存儲空間的設定，在如今卻成為了 BUG。因為 2022 年的后兩位 22 帶入到 “ yymmddhhmm ” 中，直接就超過 int32 的取值范圍。。。

　　好在微軟攻城獅的加班加點之下，相關的問題已經得到了解決，連夜捉蟲或許就是他們的新年禮物吧。

　　總得來說呢，在科技互聯網領域其實一直都存在類似的祖傳代碼存在，或是為了兼容，或許是為了節省時間不重復造輪子，那些具有時代局限性的代碼，還有代碼中那些千年萬年的 BUG，也就一代又一代地傳了下來。

　　而大伙們也把這些又臭 BUG 又多的代碼稱為 “ 屎山 ”。

　　所以啊，類似于瀏覽器版本號、日期存儲的 BUG 并不是第一次出現，也肯定不會是最后一次。

　　最后呢，大伙們可以再等待一波即將到來的 2038 年問題。

　　因為那些使用 POSIX 時間的 32 位程序，它們的計時方式是用秒來表示的。其中格林尼治時間 1970 年的 1 月 1 日 0 時 0 分 0 秒為起點，第 2147483648 秒為上限。

　　而第 2147483648 秒的時間正好是 2038 年 1 月 19 日的凌晨 3 點 14 分 07 秒，而到過了這那一秒，應該有又不少的設備會有 BUG 了。

　　當然，到時候應該不會還有 32 位的設備存在了吧，或許，沒了吧。