You’re Bob, a bootstrapped founder who can’t afford to hire a software engineer. In this era of “Vibe Coding,” you believe you can build a Minimum Viable Product (MVP) just by relying on AI. 🤖 Today, you finally figured out how to set up an API, handle frontend rendering, and connect a SQL database. You actually built an e-commerce app! The tests passed, and it’s finally time for the soft launch. 🚀 ...
你是 Bob，一個請不起軟體工程師的創業者。在 Vibe Coding 的時代，你相信自己靠 AI 寫 MVP 沒問題的。 今天你學會架 API、做前端渲染、連接 SQL 資料庫，總算是做出了個電商 App，測試沒問題，終於可以試用期上線啦！ 哇！結果一上線辦活動，你好不容易吸引來的用戶開始哀哀叫啦！ 「Bob！我明明看到還有庫存，為什麼扣款了卻不出貨？！」 你去後台一看，庫存只有 10 個，卻賣出了 12 個！？你要去哪裡生出另外兩雙喬丹限量鞋？ 你汗流浹背了。你可不想讓人發現你只是個摳門的創業者，這牌子剛打磨好就要砸啦！ 你趕快跑來問後端工程師 Aaron。 「Aaron Aaron，這是甚麼情形？難道天要亡我，電腦就這麼故意多算兩筆數據嗎？」 Aaron 拍拍你的背，「這不是運氣不好，這是典型的 Race Condition (競態條件)。」 「Race Condition？」 🛑 為什麼你的程式碼會說謊？ Bob，你寫的邏輯大概是長這樣吧？ 讀取：看資料庫，還有貨嗎？ (Select count...) 判斷：如果 > 0，就賣給他。 寫入：把庫存 -1，寫回資料庫。 (Update...) 這邏輯在只有你一個人測試時，完美無缺。 但當 User A 和 User B 在「同一毫秒」按下購買鍵時，悲劇發生了： A 看到庫存是 1。 B 同時也看到庫存是 1 (因為 A 還沒來得及扣掉)。 A 買到了，庫存變 0。 B 也以為自己買到了，庫存變 -1。 這就是 Race Condition。 ...