1樓：
我這個bug也不知道算不算bug，當俺在X軟工作時，因為客戶遲遲不驗收不給回款，所以領導說，給我把軟體所有功能都調慢，所以直接在程式中寫入了sleep
然後年輕的我多次問領導這行嗎。後續事情好像是使用者寧願卡著也沒有回款。這是俺在職業生涯中最合法寫的bug。然後我希望有更多這樣的機會。
2樓：Java研磨架構師
銀行系統，給客戶轉賬是轉兩份
就是你轉100萬，對方收到200萬
為什麼會金額這麼大，因為是企業賬戶，系統也是企業系統但是，不怕，銀行可以追回的，責任是領導的，技術也就是被領導批評而已
3樓：
（曾經的程式猿）老透明不請自來強答一波
現供職國內某老牌ERP公司（目前在該公司的職業生涯按小時倒數了）。
月頭某天半夜給乙個大型企業的專案打補丁，更新補丁的指令碼中有一項是清理快取和日誌目錄，結果手滑，把上傳的業務附件目錄也列到清理清單裡去了。。。然後專案炸了，客戶炸了，公司炸了。我在公司的職業生涯也完了。
這輩子也算體驗到了啥叫刪庫跑路。。。果然話不能說太滿，牛beer吹太足了也是會爆的。。當初在該公司下某專業行業分公司時也算技術骨幹了，10多年金融軟體行業的訓練，把安全穩定看的比啥都重，誰知道當時抱著技術扶貧的心態來目前的分公司，最終還是自己翻了車，小丑竟是我自己
4樓：風遲御
魅族手機的系統bug。
解決辦法也簡單，先把系統語言改成英文，然後就能重新設定sim卡資訊了，想出這解決辦法的，屬實是人類智商巔峰了。
5樓：
文章審核系統，從測試環境phpmyadmin匯出文章表勾選了清除重新建表的選項，匯入正式環境沒注意把文章表清空了，恢復用了一下午，並且丟了一天的資料
6樓：孤狐無悔
我參與的乙個專案，乙個機械人，懸吊在5公尺高左右的軌道上，在地下80公尺深處的隧道中進行一維運動，運動範圍大約是3.7千公尺長。
因為隧道中工作需要各方協調，所以軌道的遠端還未封閉，我們就開始測試。所以機械人是有可能跑出軌道掉落的。順便說下，機械人造價大約百萬左右，不算高。
但是掉落砸到人就是大問題了，沒砸到人那也是嚴重事故，損失會遠超百萬。
我們測試的時候，暫時只在1千公尺以內的範圍跑。
在一次測試的時候，出問題了。在機械人跑到1000公尺處時，本應停下來然後返回，但是卻忽然失去控制，開始以0.42公尺每秒的速度繼續前進，且不接受任何指令。
於是我的兩個同事趕快辦手續下隧道，手持5公尺長棍在隧道疾走，最終在2.7千公尺左右的地方追上了機械人。然後用那根長棍把機械人拖回來。我則在控制室負責監控機械人的位置並定時告知他們。
一開始沒找到Bug所在，只好在測試時總有人得在隧道裡跟著機械人。同樣的現象發生了數次之後，終於確定了問題：電機驅動板上的乙個電容，用錯了型號，導致在某種特定情況下訊號錯誤。
接下來我們就開始檢討軟體和韌體方面是否有可以改進的地方，最終結論是，使用者介面發出的緊急停止指令的優先順序不夠高，沒有超控那個訊號錯誤。最後決定，把手動緊急停止的指令優先順序提高到最高，和障礙物停止乙個級別。
7樓：陳東文
要說影響最大的，那個bug比較複雜。主路是A服務，百萬QPS，我寫了個B服務，接主路大概10%的流量。因為我的服務處理邏輯簡單，所以用的機器就少了一點，結果週末在家高高興興打英雄聯盟的時候，我的服務掛了，cpu飆到100%，所有請求都timeout；檢視入口流量qps翻了好多倍，是因為本身我的服務timeout後，rpc框架底層會直接在集群內向其他機器發3個請求，所以我有一點timeout後，流量就被複製了3次，然後再複製。
我的機器本來就少，處理不過來，所有cpu都在處理io，就掛在這了。然後我的服務本身無關緊要，但我的上游是極其核心的服務，我上游呼叫我的時候有timeout，雖然主幹邏輯不再等待，但執行緒池卻少了乙個可以處理其他任務的執行緒，時間長了堆起來，就把執行緒池資源耗盡了，然後主流程就gg了。
要說最nt的，就在今天上午，我把learning_rate=learning_rate，寫成了learning_rate==learning_rate，learning_rate直接乾到1，怎麼訓練auc都是0.5，查了半個小時，人麻了。
8樓：平教經
沒什麼特大的，有個情節比較惡劣，就是沒用斷點前端 alert出了caonima+id 大領導看見了。我打的不是拼音，是漢字。
9樓：繁星若塵
不是我寫的，是我見過的。
登入功能，把使用者表的所有使用者資訊整個傳到前端，for迴圈遍歷核對有沒有正確的賬號密碼。。。。。
測試環境就幾十個使用者資料跑的還挺快。。。。
還好叫我給攔住了，沒給上生產。
這寫法直接震驚我一百年。
10樓：窮叉叉苦哈哈
今天運營找到我，說有個客戶又續費了，但是資料一條都找不到了。我去確認了一下
郵件是11.26號傳送的
程式執行邏輯是，從當前時間往前倒三個月，比如12.2號執行，三個月前就是9.2號，也就是這個賬戶的資料只保留9.2 - 12.2之間的
但運營理解的是三個月時間，應該以賬戶最後活躍時間為起點往前倒三個月暫時沒有被定義為Bug，真是被認定為Bug，可不是程式的Bug了，是團隊溝通的Bug。
11樓：
springboot有個@Scheduled註解是設定執行job的間隔時間，這個你知道了，咱接著往下說。
有個在執行的專案發放獎勵的時間寫錯了，每隔四分鐘發放一次，好在備份sql了，客戶也好說話，要不賠錢不說，工作也得丟。以上
12樓：大為
鄙人當年查出過乙個驚天大bug，其實bug並不高階，是乙個unsigned 32位計數器溢位，每秒1000個ticks，所以系統每49天崩潰一次。電信級裝置，500萬使用者，哈哈，當時那個酸爽啊。由於在極大的壓力下找出這個bug，挽回數千萬損失的原因，當年被連公升兩個職級，同時被評為優秀員工。
13樓：會局摧毀火布偶
不是我寫的，同事幹的，不算大，但是很無語。
可憐負責這個專案後端的同事，還有兩天就正式離職連續兩個通宵把伺服器裡所有資料一一對了一遍修改，然後一攤死魚一般的離職跑路了。
14樓：
( `boss掉裝備機率寫錯了某個服的極品裝備滿天飛
開盒子隨機部件少放了一件真不是故意的。。。 開不出來被玩家罵了一晚上
15樓：歪少
我印象最深的就是關於變數起名引起的bug：' l ' 和 ' I ' 以及 ' 1 '
最後乙個其實還好，你們都能看出來是數字一，但是前兩個.....兄弟們，我不說，你們也分不清哪個是字母' i ',哪個是字母' L '吧！
現在說起來其實挺蠢的，但是當時因為這個問題我們團隊生產搞了一天才發現......事情是這個樣子：我們的業務需要每天統計使用者產生的報表，在報表的生成流水號裡，生成規則裡存在字母 ' l '，但是後來因為業務需要，流水號中的 ' l '變成了' I '（當然這都是之前的事情，我們屬於後接的老專案）。
然後某一天有客戶反應自己的流水有問題，我和同事就開始被這 ' l ' 和 ' I '戲耍了，我們蠢蠢的去排查後台問題（結果肯定是白費了....），那麼問題來了：我們是怎麼發現的？....
害，同事手機打字的時候突然靈光一閃......害，都是眼淚。之後我們就禁止用這兩個字母了，太坑！！
兄弟們引以為戒啊，我只能幫你們到這裡了。
16樓：
一不崩潰，二不報錯，但是卻可能被殺拿去祭天。
這個bug一直到上線乙個禮拜才被發現。
我心裡咯吱一下，有點慌了，因為我想起了某些不好的回憶。
然後就確認說，你這不會是測試包吧。
產品確認說是線上包，已經上線了，我又本地確認了一下。
完蛋。才想起，之前測試完後，後面為了測試，就改了個入口，然後忘記改回來了。
接著就剛好上線了。
很奇異，可能因為使用者量不大，所以暫時也沒有線上反饋。
趕緊改了一下，順便加了點需求，當天就更新回去了。
否則，後果不堪設想。
那，我就GG了。
17樓：村長誠不欺我
最大bug不好說，直接造成損失嚴重的還沒有。最坑人的可以說說。
主要做資料處理這塊的工作，有些字元處理能弄到發狂。
交易上因為各自有不同定義，有「賬戶」和「帳戶」這兩個詞，這是我遇到的第乙個字元問題，我還想著明明有資料啊？怎麼還老是報錯？高讚中「券」和「劵」的問題表示非常能理解。
爬蟲上有各種稀奇古怪的資料，空格就有好幾種，當時做正則匹配老是去不掉空格，\u3000、\xa0啥啥啥的，還有好幾種，太久遠記不清了，光眼睛看可看不出空格有啥區別，最後轉unicode才發現。
全形和半形字元的問題，這也算是坑慘了，當時做的固定精確匹配，英文本母和數字都死活匹配不上，轉unicode一看好傢伙藏著掖著坑我，說的就是那些個券商坑爹資料！
全形半形：ABCDEFGHIJKLMNOPQRSTUVWXYZ
18樓：不想說的豬
刪了ga網某張業務表整表資料。
於是當業務資料有問題，到了這個流程傳了乙個空值過來，delete where 1=1 in()語句變成了delete where 1=1.於是整張表被清空了。
熬了個通宵，dump日誌恢復了
19樓：程式設計師指北
當時在網際網路金融公司工作，每天有點給使用者派息的操作。就是把本金+利息返給使用者，當時的轉賬介面不穩定，於是有這樣乙個判斷。
當第乙個轉賬交易失敗的時候，觸發第二個轉賬交易進行派息。
有一天第乙個轉賬介面全部超時，程式自然認為轉賬失敗，觸發了第二次第二種轉賬；後來發現哪些超時的交易，也都轉賬成功了！
給使用者多發了幾千萬...，想想我心中的陰影面積有多大！
20樓：紙之上
據說滴滴以前有乙個「BUG」，創業初期，司機提現的時候顯示「公司賬戶餘額不足」，直接引起滴滴司機的恐慌性擠兌，差點把滴滴扼殺在搖籃之中。
21樓：風飛星閃
簡訊計費，寫的判斷條件忘關除錯就打包了，直接變成了While（true）。
導致使用者一跑我們的遊戲，幾毛錢一條的計費，玩兒不了十幾分鐘就能把話費扣完...
結果直接被投訴在中國移動下架...限時整改之後也再也沒給上架...
不過後來這個bug引出了一些列故事...
甚至還有人專門找到我來求教怎麼做「無限扣費」......
22樓：
這個得匿名！我看你們就沒有乙個實際發生大額資金損失的。
那個BUG不是我寫的，但是作為那個組的核心骨幹，我也是有責任的。畢竟技術方案評審的時候是得我這些點頭的。
有10年了，這個BUG是沒有守住在極端異常的情況下的重複出金的問題。這個導致的270萬的資損！（其實這也不完全是我們的鍋，銀行至少得承擔80%的責任。
但是誰讓我們求著銀行吃飯呢？銀行返回的狀態不靠譜。他們在那段時間出了些問題，導致其介面返回了乙個文件中沒有出現過的故障碼，我們程式就認為是失敗——「只要不是成功或處理中，全部是失敗」。
然而，該故障碼的含義是內部故障，訂單掛起，這個需要後續使用查詢介面來閉環交易。都怪我們都是半吊子來做支付系統的呀，哪曉得有這些坑啊！銀行還有這麼不靠譜的啊！
就因為這個事情，公司所有的提現介面全部改成了非同步介面，不再信任銀行返回什麼，只認從銀行訂單系統查詢回來的交易狀態。也就是為啥提現總是要等個好幾分鐘了，至少在那家公司是這樣的。）
然而就算這樣，我們的大老闆沒有開除我們！並且認為這是學費。這導致整個開發組在後面的程式設計極端保守，並一直在傳承下去。
有多保守？只要是跟資金相關的操作，都需要進行至少兩種方案的設計，並在最終決策的時候做比對。一致後才進行下一步操作。
比如對賬，我們是使用了三種不同的對賬方法進行對賬，並在最後對這三種方案輸出的結果再進行核對，如果發現不一致，則全部暫停，等待人工干預。
相應的，由於這麼幹了以後，整個開發組的產出低了很多，加班也多了很多。畢竟為了將錯誤減低到0.1%以下，得付出更多的工作量成本。當然，後面我們這邊已經很難再出這樣的資損故障了。
程式設計師職業生涯真的很短嗎
扣丁 如今許多的年輕程式設計師太浮燥了，才會說30歲是程式設計師的頂峰。對於學習的時候也不想下笨功夫，都想一步登天。現實只會告訴你，你是痴心妄想 在程式設計師這個行業，對於大多數人來說，如果還沒有程式設計到30歲，還不能成為乙個 合格 的程式設計師。所以，並不是程式設計編到30歲就玩完了，而是程式設...
程式設計師會在開發過程中忘記自己寫過的細節麼？
馬健 太會忘了，過上一兩個周，回頭看自己寫過的稍為複雜一些的，和業務掛鉤的，都費勁。很複雜的更是會懷疑是不是自己寫的。所以要寫注釋，不僅是給接手的人看的，也是給自己看的。 山海皆可平z 有句話叫做好記性不如爛筆頭，就是再好的記性也是會忘記的。程式設計師都是人，肯定也會忘記自己寫過的細節咯，這個是很正...
如果不創業，程式設計師職業生涯最遠能走多遠？
璟璟 技術永遠都是工具不是目的。能走多遠取決於市場需求和你所在公司的市場定位。技術也不是越強越好，老闆永遠考慮的都是利潤。如果只是為了玩鬥地主，誰需要那麼高配置的電腦？效能過剩代表了成本偏高，尤其在中國，劣幣驅逐良幣的市場比比皆是。結論 乙個蘿蔔乙個坑。 問這種問題一般都是患有焦慮症的小碼農。程式設...