你想想，你吃着泡麵、哼着歌、還在網上衝著浪，突然就發現瀏覽器用不了了，這可多難受啊。當然啦，這可不是差評君在瞎帶節奏啊，因為這事還真有那麼點可能會發生。因為全世界最流行瀏覽器之一的 Chrome，馬上就要發布第 100 個版本了。而這次更新，很可能會引發一些 BUG，導致網頁直接打不開。
衝浪板要是壞了，這可讓咱們怎麼衝浪啊？
Chrome 大夥們可再熟悉不過了，這款有內存吞噬者之稱的瀏覽器，在這顆行星上有超過 20 億的裝機量。
至少在編輯部，除了少數幾個 Safari 用戶外，Chrome 的覆蓋率沒有 9 成也有 8 成。而剩下的也大都是在用各種 chromium “ 套殼 ” 瀏覽器。
那麼問題就來了，別人的軟件更新不是內置個虛幻引擎，加些新功能，就是修復一些 BUG，讓產品更加穩定。
Chrome 你這個坐擁數十億的大咖咋一更新，反而修復了 “ BUG 過少的 BUG ” 呢？
這不是把用戶做寶搞嗎？
其實啊，這鍋還真怪不到Google的工程師身上，引發這一場 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 的Google，在去年就提供了個測試 flag。
大夥們只要在瀏覽器中輸入 chrome : //flags 然後輸入並打開 #force-major-version-to-100 就能讓網站打破兩位數的魔咒，強制顯示版本號為 100 了。
而老外的性情似乎也是調和折中的，因為還有網友提出了另外中庸的解決辦法。
那就是讓Google的版本永遠停在 99，之後的更新變後面的小數點就可以了。
只不過，這些人再怎麼出謀劃策也都是 “ 皇上不急太監急 ”，要知道古話說的好：解鈴還須繫鈴人啊！
好在真正的罪魁禍首 Duda 在不久發布了公告，表示已經更新了代碼，並解決了這個問題。
而在Google反饋 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 位的設備存在了吧，或許，沒了吧。