前言：語言是信息傳播最大障礙，多語言站是破局鑰匙

多語言網站：**同一內容、多種語言、同一域名/入口、無縫切換**。核心挑戰：架構選型、動態數據多語言存儲、字符集統一。本文系統拆解三大戰場。

一、架構選型：靜態 vs 動態，無絕對優劣，只有場景適配

方案 A：靜態多語言（文件級隔離）

• **結構**：每語言一套完整靜態文件，通過後綴（`index_en.html`）或子目錄（`/en/index.html`）區分
• **優點**：無服務端運算，極快響應，高併發支撐，部署簡單（CDN 直發）
• **缺點**：內容同步地獄——非文本資源（圖片、JS、CSS）也需多份複製，存儲浪費；新增語言 = 全量複製；跨語言連結維護痛苦
• **適用**：內容靜態、更新極低、語言數固定 ≤ 3、團隊無後端能力的中小項目

方案 B：動態多語言（語言變量 + 模板引擎）

• **核心**：單一套動態模板，文本輸出點統一用語言變量（`{{ t('welcome') }}`），運行時根據用戶語言注入對應值
• **優點**：單一代碼庫，內容與邏輯分離，新增語言只增翻譯文件，存儲極省，維護集中
• **缺點**：每請求需服務端渲染，消耗 CPU/內存，併發上限較低；首屏渲染較靜態慢（可配合 SSR/SSG/ISR 緩解）
• **適用**：內容高頻更新、語言數多/持續增長、有後端團隊、需 SEO 的中大型項目

二、動態數據多語言存儲：三級方案優劣對比

數據庫中涉語言文本（商品名、文章、評論等）如何存？

| 方案 | 粒度 | 實現方式 | 優點 | 缺點 | 適用場景 | |------|------|----------|------|------|----------| | **庫級** | Database | 每語言獨立 DB | 物理隔離極致、權限清晰 | 空間浪費極大（非文本表全量複製）、跨庫查詢/事務極痛、擴展語言 = 新建 DB + 同步 Schema | 極少見，僅極少數超大型跨國獨立運營實體 | | **表級** | Table | 每語言獨立表（`product_en`, `product_zh`） | 共用 DB 連接池、非文本表共享、新增語言 = 建新表、維護相對簡單 | 共享字段（庫存、價格、SKU）同步麻煩、跨語言 JOIN 複雜 | **最推薦**：中大型電商、CMS、多語言內容平台 | | **字段級** | Column | 同表多語言字段（`title_en`, `title_zh`） | 單表查詢、無同步問題 | **擴展語言需 ALTER TABLE 加鎖、鎖表風險大、Schema 膨脹、查詢 SELECT * 暴雷** | 僅適合語言數**永久固定 ≤ 3** 的極簡項目 |

共享字段難題的最佳解法：抽離共享表

將**所有語言共享字段**（SKU、庫存、價格、重量、編碼、圖片 URL）抽離至**共享基礎表**（`product_base`），各語言表僅存**語言相關字段**（`title`, `description`, `slug`, `seo_meta`）。
查詢時 `JOIN base + lang_table` —— **維護簡單、擴展零風險、查詢高效、空間最優**。

三、字符集：Unicode (UTF-8) 是唯一正解

**痛點**：GB2312/Big5/Shift_JIS/EUC-KR 等單一字符集無法同時展示多語言，用戶瀏覽非本地語言頁面必現亂碼。
**解法**：**全站強制 UTF-8**——雙字節編碼，覆蓋 65,536+ 字符，涵蓋全球通用語言。

必做清單（項目 Day 1 完成）

1. 數據庫、表、欄位 Collation 全部 `utf8mb4_unicode_ci`（支援 Emoji/補充平面）
2. HTML `` 首行：``
3. HTTP 響應頭：`Content-Type: text/html; charset=utf-8`
4. 服務端腳本（PHP/Python/Node/Java）內部編碼統一 UTF-8，輸出前無需轉碼
5. 表單提交、AJAX、API 請求/響應 Header 全鏈路 `charset=utf-8`
6. 文件存儲編碼：編輯器/IDE 統一保存為 UTF-8 **無 BOM**

警告：專案中途改字符集 = 重寫所有文本內容。**Day 1 定調 UTF-8，一輩子不後悔。**

四、PHP/舊系統特有：CodePage 歷史包袱處理

舊 ASP/VBScript/PHP 系統涉及內碼轉換（GB2312/Big5 ↔ Unicode），依賴 `CodePage`：
• `codepage=936` 簡中 GBK
• `codepage=950` 繁中 Big5
• `codepage=65001` UTF-8
**現代化路徑**：棄用 CodePage 機制，全鏈路 UTF-8，資料庫一次性 `iconv`/`mb_convert_encoding` 清洗遷移，徹底斷舊根。

五、工程化落地清單

1. 採用 **i18n 框架**（next-i18next, react-intl, vue-i18n, Laravel Localization, Django i18n）管理翻譯文件
2. 建立 **翻譯管理流程**：鍵值命名規範 → 翻譯平台 → CI/CD 自動同步構建
3. 實現 **語言檢測與切換**：`Accept-Language` + URL 前綴 (`/zh/`, `/en/`) + 用戶偏好 Cookie，優先級明確
4. SEO：`hreflang` 標簽完整佈放、Sitemap 多語言版本、Canonical 指向當前語言版本
5. 測試矩陣：主流語言 × 主流瀏覽器 × 真機/模擬器，**專項測試長文本換行、RTL 佈局（阿拉伯/希伯來）、字體回退、日期/數字/貨幣本地化**

結語：多語言是架構決策，不是功能補丁

在項目啟動前確定架構模式、數據模型、字符集策略，**將多語言能力內化為系統基因**，而非上線前兩周臨時加的「語言包」。這才是面向全球用戶的專業工程態度。