說實話看到“SHA加密算法”這個標題我第一反應(yīng)是這又是一個被寫爛的入門Demo。但實際在項目里接手過幾個跟數(shù)據(jù)校驗、安全存儲相關(guān)的模塊之后我覺得“SHA”這一塊值得聊的東西其實非常多——很多人止步于會用MessageDigest.getInstance(SHA-256)算個哈希但真正到了生產(chǎn)環(huán)境選哪個變體、怎么處理編碼、文件流要怎么讀、加了鹽之后為什么還是不夠這些問題如果不提前想清楚后面返工的成本會很高。這篇文章我不打算堆疊官方文檔那套說法而是從實際開發(fā)的角度把這幾年做Java后端時跟SHA打交道踩過的坑、沉淀下來的經(jīng)驗一次講透。內(nèi)容包括SHA家族的整體選型思路、MessageDigest的核心機制、字符串與文件場景的完整代碼實現(xiàn)、加鹽和HMAC的實際用法以及一張可以直接收藏的常見問題排查表。不管你是剛接觸摘要算法的新手還是已經(jīng)寫過幾版工具類但想確認有沒有寫錯的老手這篇文章應(yīng)該都能幫你省下一點試錯時間。1. 先想清楚算法選型再寫第一行代碼很多人一上來就寫SHA-256這本身沒錯但你要知道自己為什么選它。SHA這個家族里頭SHA-1、SHA-256、SHA-512是三種完全不同的安全水位選錯了場景輕則被安全評審打回重則給線上系統(tǒng)埋雷。1.1 為什么默認方案通常是SHA-256SHA-1輸出160位20字節(jié)的哈希值在2005年就已經(jīng)被理論碰撞攻擊攻破2017年谷歌和一家安全機構(gòu)聯(lián)合制造了真實的SHA-1碰撞實例。所以只要你的系統(tǒng)跟“對抗惡意輸入”沾邊就不該再用SHA-1。SHA-256輸出256位32字節(jié)目前沒有實際可行的碰撞攻擊而且計算性能相當好無論是純軟件實現(xiàn)還是硬件加速它都是性價比最高的選擇。SHA-512雖然更長但在64位處理器上它的計算速度甚至可能比SHA-256更快因為SHA-512使用64位字長、更大的消息塊和輪數(shù)結(jié)構(gòu)。不過SHA-512的摘要長度是64字節(jié)比SHA-256長一倍存儲和傳輸開銷也隨之變大。這里給大家一個實際表格把SHA家族里的主流變體擺在一起平時選型對照著看就行。算法輸出長度位/字節(jié)內(nèi)部結(jié)構(gòu)安全狀態(tài)典型場景SHA-1160 / 20Merkle-Damg?rd已實際碰撞不可用于安全場景僅兼容舊系統(tǒng)、數(shù)據(jù)去重SHA-224224 / 28Merkle-Damg?rd安全但較少使用需要更短摘要時折中SHA-256256 / 32Merkle-Damg?rd安全主流默認文件校驗、消息摘要、數(shù)字簽名SHA-384384 / 48Merkle-Damg?rd安全階數(shù)更高兼容性要求較高的協(xié)議SHA-512512 / 64Merkle-Damg?rd安全64位平臺性能好高安全要求的存儲SHA-3可變Keccak海綿結(jié)構(gòu)安全結(jié)構(gòu)與SHA-2完全不同新型系統(tǒng)、需要算法多樣化時1.2 JDK自帶的摘要算法全家桶Java的java.security.MessageDigest從JDK 1.1開始就是標準API了你在生產(chǎn)環(huán)境里幾乎不需要額外引第三方庫就能完成99%的SHA需求。JDK根據(jù)運行平臺的不同底層會通過SPI機制選擇一個可用的安全提供者大多數(shù)情況下是SUN或SunJCE這些提供者原生支持SHA-1、SHA-224、SHA-256、SHA-384、SHA-512、SHA3-224、SHA3-256、SHA3-384、SHA3-512。有個容易忽略的點是算法名稱字符串是大小寫不敏感的但推薦嚴格寫成標準的連字符大寫形式比如SHA-256因為某些第三方安全提供者比如一些硬件加密模塊對算法名的解析可能比較嚴格。注意MessageDigest不是線程安全的。同一個實例在多線程環(huán)境下調(diào)用digest()方法會導致結(jié)果錯亂甚至拋出異常。正確的做法是每個線程單獨創(chuàng)建實例或者用ThreadLocalMessageDigest去做線程級緩存。1.3 選型時容易踩的認知誤區(qū)第一個誤區(qū)是覺得SHA-512一定比SHA-256安全一倍。哈希安全性取決于抗碰撞能力的位長256位和512位的差距確實存在但SHA-512的膨脹也帶來了兩倍存儲開銷而SHA-256在當前算力下的安全性對絕大多數(shù)業(yè)務(wù)場景已經(jīng)綽綽有余。除非是安全等級要求極高的政務(wù)、金融核心鏈路或者需要通過算法套件多樣化來滿足合規(guī)要求否則沒必要為了“看起來更安全”去選SHA-512。第二個誤區(qū)是把SHA加密掛在嘴邊。嚴格來說SHA是摘要算法不是加密算法。加密是可逆的摘要不可逆。這個概念要是跟產(chǎn)品經(jīng)理或安全評審解釋不清楚后面往往會被要求“把哈希解開”你沒法解這就是需求理解層面的問題。你可以在團隊內(nèi)部文檔里統(tǒng)一把它叫“哈希/摘要算法”避免歧義。2. 動手之前先吃透MessageDigest核心機制我見過不少同事寫哈希工具類時代碼能跑但總有一種“臨時拼湊”感比如每次循環(huán)都重新getInstance一次或者干脆把digest(byte[])和toString()混在一起用。想要寫出穩(wěn)、快、不出問題的代碼得先理解MessageDigest的生命周期和使用機制。2.1 初始化、更新與一次性結(jié)算MessageDigest使用起來是個三段式流程getInstance創(chuàng)建實例update喂數(shù)據(jù)digest結(jié)算結(jié)果。核心設(shè)計意圖是支持流式數(shù)據(jù)的增量哈?！悴恍枰淮涡园阉袛?shù)據(jù)加載進內(nèi)存可以分批把數(shù)據(jù)塊通過update(byte[], int, int)喂進去最后統(tǒng)一digest()得到完整摘要。MessageDigest digest MessageDigest.getInstance(SHA-256); digest.update(Hello, .getBytes(StandardCharsets.UTF_8)); digest.update(World!.getBytes(StandardCharsets.UTF_8)); byte[] hash digest.digest();這個例子看起來簡單但注意digest()在執(zhí)行時做兩件事一是把已經(jīng)喂進來的所有數(shù)據(jù)做最終填充和摘要計算二是同時重置內(nèi)部狀態(tài)。也就是說digest()之后這個實例不需要重新創(chuàng)建就能再次使用但如果你在digest()之后繼續(xù)update()那是在一個重置后的新上下文中追加數(shù)據(jù)結(jié)果跟連續(xù)一次性輸入是不等價的。所以實踐上我建議一個實例結(jié)算完之后尤其是單線程場景下最保險的做法是直接重新getInstance避免狀態(tài)心智負擔。2.2 為什么JDK有現(xiàn)成的摘要計算方法還要自己處理Hex編碼digest()返回的是byte[]也就是原始二進制摘要。很多初學者直接對這個字節(jié)數(shù)組做toString()得到一個類似[B1b6d3586的對象地址然后一臉懵。這是因為Java字節(jié)數(shù)組沒有重寫toString()你要的是可讀的十六進制字符串JDK標準庫并沒有直接提供byte[] - Hex的便捷方法直到較新的JDK版本也仍然沒有但HexFormat在JDK 17之后出現(xiàn)了。所以實際開發(fā)里需要自己寫一個Hex轉(zhuǎn)換或者用現(xiàn)成的庫。我推薦在項目里統(tǒng)一封裝下面這段是穩(wěn)定高效的寫法用了查表法比逐字節(jié)拼接String.format(%02x)快得多private static final char[] HEX_ARRAY 0123456789abcdef.toCharArray(); public static String bytesToHex(byte[] bytes) { char[] hexChars new char[bytes.length * 2]; for (int i 0; i bytes.length; i) { int v bytes[i] 0xFF; hexChars[i * 2] HEX_ARRAY[v 4]; hexChars[i * 2 1] HEX_ARRAY[v 0x0F]; } return new String(hexChars); }這里有一個要點bytes[i] 0xFF這一操作目的是把有符號的byte轉(zhuǎn)成無符號的0到255范圍因為Java的byte是帶符號的負數(shù)的二進制表示在轉(zhuǎn)十六進制時如果不做掩碼處理會得到ffffffff這樣的錯誤結(jié)果。這個細節(jié)是哈希工具類最常見的Bug點之一。2.3 開發(fā)中必須明確的三個編碼細節(jié)第一個細節(jié)是字符串編碼。同一個字符串用getBytes()平臺默認字符集和getBytes(StandardCharsets.UTF_8)去計算哈希結(jié)果可能是不同的。在中文Windows環(huán)境下默認字符集是GBK在Linux服務(wù)器上默認字符集通常是UTF-8。你本地算出來的哈希到了服務(wù)器上對不上先查這里。// 推薦顯式指定字符集 byte[] input text.getBytes(StandardCharsets.UTF_8);第二個細節(jié)是大小寫。十六進制字符串輸出時用大寫還是小寫本身不影響哈希的“值”但會影響對比的一致性。如果你跟外部系統(tǒng)對接必須先確認對方用的是大寫還是小寫。建議項目內(nèi)部統(tǒng)一用小寫因為小寫十六進制在URL、文件名、數(shù)據(jù)庫索引中更常見也避免了很多不必要的大小寫轉(zhuǎn)換。第三個細節(jié)是Base64與Hex的選擇。同樣的32字節(jié)摘要Base64表達為43個字符左右Hex表達為64個字符。如果你要存數(shù)據(jù)庫或傳輸Base64更省空間但可讀性差如果要給人看、打日志、做文件名Hex更好。我在做文件完整性校驗時習慣用Hex在把哈希值塞進消息頭或Token里時則用Base64。沒有絕對標準但一定要統(tǒng)一。3. 完整實操從字符串哈希擴展到文件校驗與批量計算理論說再多不如直接把能用的代碼貼出來。這一節(jié)我會從最常用的字符串哈希工具類寫起然后處理大文件校驗時的內(nèi)存優(yōu)化問題再補上批量計算和HMAC的進階寫法。3.1 單字符串SHA-256工具類五段代碼寫完下面的工具類封裝了最核心的流程獲取實例、喂入字節(jié)、轉(zhuǎn)Hex、輸出。生產(chǎn)環(huán)境里我一般還會增加一個靜態(tài)工廠方法允許調(diào)用方傳入算法名這樣想從SHA-256切換到SHA-512時不用改調(diào)用方代碼。import java.nio.charset.StandardCharsets; import java.security.MessageDigest; import java.security.NoSuchAlgorithmException; public final class ShaUtils { private ShaUtils() {} public static String sha256Hex(String text) { return hashHex(SHA-256, text.getBytes(StandardCharsets.UTF_8)); } public static String hashHex(String algorithm, byte[] data) { try { MessageDigest digest MessageDigest.getInstance(algorithm); byte[] hash digest.digest(data); return bytesToHex(hash); } catch (NoSuchAlgorithmException e) { throw new IllegalArgumentException(Unsupported algorithm: algorithm, e); } } private static final char[] HEX_ARRAY 0123456789abcdef.toCharArray(); public static String bytesToHex(byte[] bytes) { char[] hexChars new char[bytes.length * 2]; for (int i 0; i bytes.length; i) { int v bytes[i] 0xFF; hexChars[i * 2] HEX_ARRAY[v 4]; hexChars[i * 2 1] HEX_ARRAY[v 0x0F]; } return new String(hexChars); } }這段代碼看起來簡單但已經(jīng)考慮了三個問題一是捕獲了NoSuchAlgorithmException并轉(zhuǎn)成了運行時異常調(diào)用方不會被強制try-catch煩擾二是顯式使用UTF-8編碼消除跨平臺亂碼三是Hex轉(zhuǎn)換用查表法性能比String.format高出一個量級。實測在普通筆記本上這段代碼計算一萬次短字符串SHA-256耗時在幾十毫秒級別完全夠用。3.2 大文件哈希校驗怎么優(yōu)化內(nèi)存計算文件SHA-256有一個非常經(jīng)典的坑直接用Files.readAllBytes()把整個文件讀進內(nèi)存再哈希。這在幾十MB的小文件上沒問題但一旦文件到了幾個GB內(nèi)存就爆了。正確的姿勢是開一個緩沖區(qū)循環(huán)讀文件塊每讀一塊就update一次最后digest。public static String sha256File(File file) throws IOException { try (InputStream in new BufferedInputStream(new FileInputStream(file))) { MessageDigest digest MessageDigest.getInstance(SHA-256); byte[] buffer new byte[8192]; int len; while ((len in.read(buffer)) ! -1) { digest.update(buffer, 0, len); } return bytesToHex(digest.digest()); } catch (NoSuchAlgorithmException e) { throw new IllegalStateException(SHA-256 algorithm not available, e); } }緩沖區(qū)大小選8192字節(jié)是基于常見磁盤塊大小和JVM默認IO緩沖折算出來的。你可以試著調(diào)成16KB或64KB在某些文件系統(tǒng)上吞吐會更好但8192是實測穩(wěn)定且內(nèi)存占用優(yōu)雅的組合。這里有一個進階優(yōu)化點update(buffer, 0, len)比update(buffer)更安全因為最后一次read返回的字節(jié)數(shù)可能小于緩沖區(qū)長度如果直接update(buffer)會把上次遺留的無用數(shù)據(jù)也計算進去。重要提示文件哈希建議配合CRC32或文件大小一起使用。SHA-256只能確保內(nèi)容一致如果文件元數(shù)據(jù)比如文件名、修改時間也需要校驗?zāi)切?shù)據(jù)不屬于文件字節(jié)內(nèi)容需要單獨處理。3.3 批量計算時的并發(fā)處理和開銷分析批量哈希的場景常見于數(shù)據(jù)同步、重命名去重或者構(gòu)建增量索引。一次處理幾萬個字符串時如果循環(huán)里每次都重新getInstanceJVM創(chuàng)建對象的開銷和GC壓力會明顯上升。我的做法是根據(jù)CPU核數(shù)開一個固定大小線程池用ThreadLocal緩存MessageDigest實例。private static final ThreadLocalMessageDigest DIGEST_HOLDER ThreadLocal.withInitial(() - { try { return MessageDigest.getInstance(SHA-256); } catch (NoSuchAlgorithmException e) { throw new IllegalStateException(e); } }); public static String sha256Concurrent(String text) { MessageDigest digest DIGEST_HOLDER.get(); digest.reset(); byte[] hash digest.digest(text.getBytes(StandardCharsets.UTF_8)); return bytesToHex(hash); }注意這里我在使用前主動調(diào)了reset()目的就是防止上一個任務(wù)留下的內(nèi)部狀態(tài)污染當前結(jié)果。ThreadLocal加上reset()的組合既消滅了并發(fā)問題又避免了頻繁創(chuàng)建實例。實測在四核機器上處理100萬次短字符串哈希這個寫法比同步單線程快3倍左右。不過要提醒你如果每個數(shù)據(jù)體量很小批量計算的瓶頸往往不在CPU而在對象創(chuàng)建和IO上。不要盲目上多線程先用單線程測一下耗時分布確認CPU密集后再做并發(fā)優(yōu)化否則只是為了“看起來高性能”而陷入過度設(shè)計。3.4 用HMAC-SHA256解決密鑰參與摘要的問題有時候你需要算的不是簡單的哈希而是帶密鑰的摘要典型場景是API簽名、Webhook回調(diào)驗簽。直接SHA-256(secret data)有長度擴展攻擊等隱患正確的做法是用HMAC。JDK里Mac類支持HmacSHA256用法跟MessageDigest非常像只是初始化時需要傳入SecretKeySpec。import javax.crypto.Mac; import javax.crypto.spec.SecretKeySpec; import java.nio.charset.StandardCharsets; public static String hmacSha256Hex(String data, String secretKey) { try { Mac mac Mac.getInstance(HmacSHA256); SecretKeySpec keySpec new SecretKeySpec( secretKey.getBytes(StandardCharsets.UTF_8), HmacSHA256); mac.init(keySpec); byte[] rawHmac mac.doFinal(data.getBytes(StandardCharsets.UTF_8)); return bytesToHex(rawHmac); } catch (Exception e) { throw new IllegalStateException(HMAC computation failed, e); } }這段代碼里SecretKeySpec的第二個參數(shù)必須是HmacSHA256它告訴JVM這是一把用于HMAC-SHA256的密鑰。密鑰本身的長度建議至少32字節(jié)256位如果密鑰太短雖然算法不會報錯但抗暴力破解能力會下降。另外注意HMAC的密鑰是敏感數(shù)據(jù)不要在日志里打印也不要在代碼倉庫里寫死明文密鑰要放到配置中心或環(huán)境變量里管理。4. 說“安全”之前得先明白SHA解決什么問題不解決什么問題既然標題里有“加密”兩個字我覺得有必要把安全的邊界講透。SHA是一個很基礎(chǔ)的密碼學原語它本身不“加密”任何東西也不保證“安全”。你在項目里到底該怎么用它取決于你面對的是哪種威脅模型。4.1 密碼存儲只用SHA是典型的反面教材我在代碼評審時看到太多類似的實現(xiàn)注冊的時候把密碼sha256Hex(password)存進數(shù)據(jù)庫登錄的時候再算一次比對。這種方案在安全測試面前不堪一擊——因為你沒有加鹽同一個密碼在所有系統(tǒng)里都得到同一個哈希值。攻擊者拿到數(shù)據(jù)庫后只需要用彩虹表預先算好的海量密碼哈希表一匹配弱密碼立刻原形畢露。正確做法是給每個用戶生成獨立的隨機鹽至少16字節(jié)然后把鹽 密碼的哈希結(jié)果存下來。更穩(wěn)妥的做法是使用專門的慢哈希算法比如PBKDF2、bcrypt、scrypt或Argon2這些算法通過迭代計算加大暴力破解的成本。Java標準庫自帶PBKDF2實現(xiàn)一個加鹽密碼哈希其實并不復雜。// 生成帶鹽的PBKDF2哈希比單純SHA-256更適合密碼存儲 public static byte[] pbkdf2(char[] password, byte[] salt, int iterations, int keyLength) throws Exception { PBEKeySpec spec new PBEKeySpec(password, salt, iterations, keyLength); SecretKeyFactory factory SecretKeyFactory.getInstance(PBKDF2WithHmacSHA256); return factory.generateSecret(spec).getEncoded(); }如果你在維護一個舊系統(tǒng)密碼已經(jīng)是普通SHA-256了也不建議立刻全量重算因為用戶不會告訴你明文密碼。通常的做法是在登錄驗證邏輯里如果發(fā)現(xiàn)當前用戶還是舊的哈希方案用輸入的明文做一次升級算出新的加鹽哈希再覆蓋舊值。這叫做“漸進式哈希遷移”。4.2 文件完整性校驗與發(fā)布校驗的差異文件下載站的SHA-256校驗值跟你在數(shù)據(jù)同步系統(tǒng)里算文件哈希目的完全不同。前者對抗的是“下載過程被篡改”前提是哈希值本身是通過可信渠道獲得的后者對抗的是“傳輸或存儲中的意外損壞”。同樣是SHA-256這兩類場景的信任模型不一樣。做文件發(fā)布校驗時哈希值最好跟發(fā)布包分開渠道傳播。如果攻擊者同時篡改了文件內(nèi)容和官網(wǎng)上展示的哈希值那校驗就形同虛設(shè)。實際項目中我一般把哈希值放到簽名文件中或者直接從構(gòu)建服務(wù)器讀取并配合HTTPS傳輸。進一步說如果發(fā)布流程里有可信任的簽名私鑰建議對哈希值再做一次數(shù)字簽名這樣校驗方就能確認“哈希值來自官方”。4.3 在實際項目里SHA需要配合哪些機制第一是時間戳。很多場景不只是要驗證內(nèi)容沒變還要驗證“在某個時間點之前內(nèi)容就是這個樣子”這需要可信時間戳服務(wù)配合。第二是隨機數(shù)。如果你的系統(tǒng)需要一個防碰撞的標識比如生成短鏈接或唯一文件名用SHA-256對“隨機數(shù)內(nèi)容”做哈?？梢越档团鲎哺怕实饕S機性還是要依賴安全的隨機源。第三是審計日志。哈希值本身只能檢測內(nèi)容是否變化不能告訴你誰在什么時候改了內(nèi)容所以要有配套的日志和權(quán)限系統(tǒng)。我不建議你把SHA當成一個萬能安全組件。它是密碼學工具箱里的一塊積木只有跟其他機制組合起來才能撐起一個完整的安全邊界。5. 常見問題與排查技巧實錄寫哈希工具類看似容易實際一跑起來問題一堆。這一節(jié)我把這些年頻率最高的問題和排查思路整理成一個速查清單。每個問題都是我在實際項目里真遇到過的不是憑空想的。5.1 同一個字符串為什么我算出來和工具站不一樣八成是字符集問題。你代碼里用的是平臺默認字符集而某些在線工具站默認用UTF-8如果你的運行環(huán)境是GBK結(jié)果當然不一樣。排查方法很簡單在代碼里顯式打印出text.getBytes()的字節(jié)長度跟工具站的輸入字節(jié)長度對比。如果字節(jié)數(shù)都不一樣說明底層編碼已經(jīng)錯了。還有一個小概率原因是在線工具站把輸入當成Base64解碼后再哈希這種情況需要你先確認對方工具的輸入處理邏輯。5.2 每次啟動計算結(jié)果不同是怎么回事正常業(yè)務(wù)里同一個輸入得到同一個哈希是基本要求如果結(jié)果不穩(wěn)定第一檢查點是你有沒有往輸入里混入隨機鹽。鹽本身是隨機的如果你在計算用戶密碼哈希時每次生成新鹽當然每次都不同——這其實是正確行為。但如果你確認輸入完全一致卻得到不同結(jié)果那就要看是不是MessageDigest實例被多線程共享了。前面說過它不是線程安全的兩個線程同時digest會導致內(nèi)部狀態(tài)互相覆蓋。建議每個計算入口都新建實例或者用ThreadLocal隔離。5.3 文件哈希校驗不通過先檢查這三處第一文件傳輸過程中是否被轉(zhuǎn)換過換行符。Windows的\r\n和Linux的\n是不同字節(jié)上傳下載工具有時會自動轉(zhuǎn)換這會讓哈希完全變掉。第二文件尾部是否有額外數(shù)據(jù)。很多下載工具會給文件追加.part后綴或者元數(shù)據(jù)段直接改后綴名續(xù)傳可能導致字節(jié)不一致。第三你的緩沖區(qū)讀取是否漏掉了最后一次不滿一個緩沖區(qū)的數(shù)據(jù)。如果代碼里用了update(buffer)而不是update(buffer, 0, len)結(jié)果必錯。5.4 性能“真慢”先看是不是在代碼結(jié)構(gòu)上犯渾我見過最夸張的一個案例某個服務(wù)計算短字符串哈希時每次請求都新建MessageDigest實例同時用String.format去拼接Hex結(jié)果在雙核小機器上TPS只能跑到幾百。排查后發(fā)現(xiàn)瓶頸根本不在算法本身而在Hex轉(zhuǎn)換和對象創(chuàng)建上。把String.format換掉之后性能直接翻了十幾倍。所以如果你覺得SHA-256慢先別急著上并發(fā)先用JMH或簡單的System.nanoTime()做個基準測試看看CPU時間到底花在哪。5.5 排查方法清單與工具推薦我現(xiàn)在排查哈希問題有一套固定流程先固定輸入編碼強制UTF-8再固定輸出格式統(tǒng)一小寫Hex最后固定算法名連字符大寫。按這個順序檢查90%的問題都能定位。如果還找不到問題就寫一個最小復現(xiàn)類把輸入、中間字節(jié)、輸出全部打印出來跟開源工具站逐一比對很容易看出差異在哪一步。工具方面除了在線哈希工具站我常用openssl命令行在Linux環(huán)境中做交叉驗證echo -n Hello, World! | sha256sum echo -n Hello, World! | openssl dgst -sha256注意echo -n不能丟丟了會多算一個換行符結(jié)果就跟程序里算了Hello, World!\n一樣這是另一個經(jīng)典坑。最后給一個常見問題速查表建議截圖或收藏現(xiàn)象可能原因解決方案字符串哈希結(jié)果與工具站不一致字符集編碼不同顯式使用UTF-8取字節(jié)返回[Bxxxx直接對byte[]調(diào)用toString()用Hex轉(zhuǎn)換工具類大文件計算OOM一次性readAllBytes改用緩沖區(qū)update并發(fā)下偶發(fā)結(jié)果錯誤MessageDigest被多線程共享改用ThreadLocal或新實例密碼哈希被破解沒有加鹽或使用快速哈希改用PBKDF2/bcrypt/Argon2文件哈?？偢l(fā)布方不同換行符轉(zhuǎn)換或尾部附加數(shù)據(jù)檢查傳輸工具配置比對字節(jié)數(shù)我個人在實際操作中的體會是SHA算法本身沒有太多可鉆研的黑魔法真正的復雜度都藏在工程細節(jié)里——字符集、緩沖區(qū)、線程隔離、安全邊界。你把這幾個細節(jié)打磨好了一個看似簡單的哈希工具類也會變得很可靠。如果你后續(xù)打算做文件秒傳系統(tǒng)或者要在分布式環(huán)境里做內(nèi)容尋址存儲這篇文章里提到的思路完全可以作為起點只需要把文件塊大小的策略和哈希索引的結(jié)構(gòu)再往深處設(shè)計一層就行。