密碼儲存是軟體領域裡少數幾個真正存在標準答案的題目之一。答案早就公開了，一直有人維護，而且免費。但它同時也是最常被做錯的題目之一，原因很單純：那些現在被視為錯誤的做法，在某個年代確實是正確的，而後來沒有人再回頭看過一眼。 失敗的樣子很少稀奇。通常就是一套 2016 年依照 2012 年的建議搭起來的系統，到今天還在跑，還在接受登入請求，而自從當初寫下那段雜湊程式碼的人離職之後，就再也沒有人打開過那個函式。它沒出過事故，也沒被稽核過，所以從來不在任何人的待辦清單上。 如果只帶走一句話：用 Argon2id，真的不行就用 bcrypt。 本文其餘部分都是細節。像 SHA-256 這樣的通用雜湊函式，無論你套用多少次，都不會變成密碼雜湊。...
後端開發
關於後端開發的文章、指南和教程，為開發者和企業提供實用知識與技巧。面向開發者與技術團隊。
技術文件的失敗方式非常具體，也非常好預測。有人在兩週清閒的時間裡寫下一大堆，接著系統變了，沒有人回頭更新，一年之內那份文件就開始信心十足地講著錯誤的內容。到了那個時候，它比什麼都沒有還要糟，因為相信它的讀者會依據早已不成立的資訊去動手。 常見的反應是號召大家多寫一些，而這只會讓同樣的失敗來得更快。有用的反應是少寫，並且認真挑選寫什麼，因為真正的瓶頸不是寫作的工夫，而是維護的工夫。文件從寫完那一刻起，就開始被現實甩在後面。 判斷一份文件該不該存在，唯一經得起時間的檢驗是： 當它變錯的時候，會不會有人察覺？部署指南天天有人用，錯誤立刻就會浮出來。一份二十頁的子系統說明只會被讀一次，它的錯誤要等到十八個月後，有人照著它動手時才浮出來。沒有...
可用性 SLA 看起來像一句承諾，實際運作起來卻更像一份退款政策。供應商很清楚這一點。客戶往往並不清楚，於是在簽下服務等級協議時以為自己買到了可用性，而真正買到的，只是萬一沒拿到時的一點折扣。 這不一定是筆糟糕的交易。它只是與大多數人以為自己在簽的那筆交易不同，而這個差別恰恰在系統停擺、有人追問合約究竟怎麼寫的那一刻顯現出來。 三個九聽起來接近完美，卻允許每月 43 分鐘的停機。 四個九允許四分鐘。如果你的業務吸收得了平日下午 43 分鐘的中斷，99.9% 就足夠了，不必為更高的數字付費。如果吸收不了，再多的九也幫不上忙，因為協議給你的是一筆抵用金，而不是阻止這次中斷。 可用性 SLA 用分鐘兌現的承諾百分比把一個非常大的區間壓縮成...
在小團隊裡，災難復原通常只剩下一份從來沒人打開過的文件裡的一行字：備份已經開啟。這句話本身沒有錯，卻算不上任何問題的答案，因為它既沒有說明真正出事時救回來的資料會有多舊，也沒有說明還原一次要花多久，更沒有說明到今天為止究竟有沒有人完整地做過一次還原。 擁有備份和真的能復原之間存在一段明顯的距離，多數的服務中斷正是在這段距離裡升級成事故。一份存在、內容也夠新、卻從來沒有被還原過的備份，本質上仍然只是一個假設；而你第一次驗證這個假設的時刻，剛好是發現它其實是錯的最糟糕的時刻。 兩個數字能把意見變成計畫。 你承受得起丟多少資料，又承受得起停多久？這就是你的復原點目標與復原時間目標。只要營運那一側沒有人把這兩個數字說出口，關於備份頻率的一切...
關於 API 版本管理的爭論，幾乎總是從錯誤的一端開始：版本號到底要放在哪裡。事實上，那是整個主題裡後果最輕微的一個決定。真正要緊的是究竟哪些變更才需要一個新版本，而多數團隊恰好在這裡判斷失準，而且是往掉以輕心的方向失準。他們發布了自認為純屬新增的東西，然後某個用戶端就壞了。 好用的思考模型是這樣：你的 API 是一份承諾，界定了呼叫端可以倚賴什麼。如果一次變更讓一個講理的呼叫端原本倚賴的東西失效，那它就是破壞性的。而呼叫端倚賴的東西，遠遠多過你的文件明確允許他們倚賴的範圍。 讓所有人都踩到的那種變更： 在回應裡多加一個欄位。它只是新增，照理說弄不壞一個寫得規矩的用戶端，可它偏偏經常弄壞真實世界的用戶端，因為其中有些會嚴格驗證回應，...
資料庫效能的排查工作，通常從有人提議換一台更大的執行個體開始，又通常以這樣一個發現收場：每次載入頁面時，有一條查詢都在對 400 萬列做循序掃描。瓶頸從來就不是硬體，瓶頸是執行計畫。 這個模式重複得夠穩定，值得當成預設假設寫下來。當應用很慢而資料庫又很忙時，原因幾乎都是少數幾條特定的查詢，而不是整體容量不足；把機器換大，只能把問題掩蓋到資料表再次長大的那一刻為止。 動手改之前，先量。 憑猜測去最佳化一條查詢，正是團隊花掉整整一週新增索引、結果寫入變慢而讀取一點也沒變快的原因。任何資料庫都能告訴你哪些語句消耗的總時間最多。從那裡開始，修掉排在最前面的那一條，然後再量一次。這樣反覆兩三輪，事故通常就結束了。 資料庫效能始於找出那條查詢總...
Cloudflare Queues 解決的是每個無伺服器應用遲早都會撞上的那個問題：一個請求抵達，觸發了一段使用者本來不該等待的工作。寄出確認郵件、把上傳的圖片改尺寸、把記錄同步到第三方服務。這些工作的共同點是：它們必須發生，但並不需要在使用者按下按鈕的那一刻發生。在傳統伺服器上，你把這類工作交給一個背景工作行程就好。可是在 Workers 上，請求處理完就結束，根本沒有可以交出去的常駐行程。 常見的幾種繞道做法，比看起來更糟。把工作放在請求裡同步做完，等於讓使用者去等一家郵件服務商的回應。向另一個 Worker 丟出請求卻不等待它，只要發起方的呼叫先結束，這個工作就丟了。這兩種做法都撐不過服務商的一次故障。 佇列真正給你的是什麼：...
Cloudflare Hyperdrive 之所以存在，是為了處理一個非常具體、也一點都不炫目的問題：一個在 200 座城市裡執行的 Worker，去跟某一座城市裡的那一個 Postgres 資料庫對話，會比同一道查詢從緊鄰這台資料庫的伺服器發出來得慢。不是慢一點點，而往往是慢上好幾倍，而且原因跟查詢本身怎麼寫完全無關。 當一個無伺服器應用顯得遲鈍時，多數人的第一直覺是怪查詢規劃器，或是再加一個索引。但在跟某個區域資料庫溝通的 Workers 上，查詢本身通常沒有毛病。真正出問題的是連線。 Hyperdrive 真正修好的東西： 建立一次資料庫連線的代價，而且這筆代價要在每一個請求上重新付一遍。一條 Postgres 連線在第一列資...
Cloudflare Workers 與 AWS Lambda 都是無伺服器運算平台，但兩者的起點不同。Lambda 是龐大 AWS 生態系中確立的無伺服器標準；Workers 則是邊緣原生的，為低延遲與全球分發而生。2026 年，兩者都很出色，正確的選擇取決於你的工作負載與現有技術棧。本指南從真正重要的面向比較 Cloudflare Workers vs AWS Lambda。 重點摘要（TL;DR） Workers 在輕量的 V8 isolates 上於 edge 執行，cold start 幾乎為零，並預設全球分發 Lambda 在 AWS 區域中以 microVM 模型執行，支援眾多語言執行環境，並與 AWS...
Cloudflare Workers 讓你無需管理伺服器，就能在靠近使用者的邊緣執行後端程式碼。對 API 而言，近乎為零的冷啟動、全球分佈與緊密整合的儲存三者結合，使 Workers 在 2026 年成為極具吸引力的平台。本指南說明 Cloudflare Workers API 的結構，以及它與傳統後端有何不同。 重點摘要 Cloudflare Workers 在邊緣的 Cloudflare 全球網路上執行你的程式碼，因此請求可在靠近使用者處以近乎為零的冷啟動被處理 Worker 透過 fetch 處理常式處理傳入請求；你依方法與路徑進行路由，並回傳標準的 Response 物件 Workers 直接綁定至儲...