Web 二維碼生成最佳實踐：從後端生成到前端渲染的架構演進

方案一：後端生成 + 靜態文件存儲（踩坑實錄）

流程：前端 AJAX 請求 → 後端用 ZXing 生成圖片 → 以 userId.png 存入 /webapp/qrcode/ → 返回文件名 → 前端 <img src="/qrcode/userId.png">

致命缺陷：瀏覽器緩存導致二維碼「失效」

• 用戶多次點擊生成，業務邏輯要求每次生成新二維碼（含時間戳/一次性 token）。
• 文件名固定（userId.png），瀏覽器發現 URL 未變，直接讀取緩存圖片。
• 掃碼得到的仍是第一次生成的舊鏈接，業務邏輯判定失效。

嘗試過的失敗方案：Cache-Control: no-cache（不穩定）、每次生成唯一文件名（磁盤爆炸）、強制用戶清理緩存（不可行）。

方案二：前端渲染（終極解法）

核心思路：後端只返回二維碼內容字符串（如帶加密參數的跳轉鏈接），前端用 qrcode.js 即時在 Canvas/Table 中繪製。

實現步驟

1. 引入 qrcode.min.js（官網）。
2. 頁面預留容器：<div id="qrcode"></div>
3. AJAX 獲取內容後一行代碼生成：

   new QRCode(document.getElementById("qrcode"), {
       text: data.qrContent,      // 後端返回的跳轉鏈接
       width: 200,
       height: 200,
       colorDark: "#000000",
       colorLight: "#ffffff",
       correctLevel: QRCode.CorrectLevel.H
   });

優勢對比

關鍵安全提示

• 後端返回的跳轉鏈接必須加密簽名（如 JWT 或 AES），防止前端被篡改參數。
• 二維碼內容不應包含敏感明文（手機號、身份證等）。
• 對於極長內容，注意 QRCode 版本限制（數字模式最多 7089 字符），必要時改用短鏈接服務。

大廠（微信、支付寶、抖音）的 Web 端二維碼幾乎均採用前端渲染方案。後端僅負責業務邏輯與簽名，前端按需繪製，完美規避緩存與資源問題。