準備工作

需要準備：電腦、USB 隨身碟（或任何可移動儲存媒介）、網路連線、基本的資訊檢索能力

• 不論使用何種安裝映像檔方案，即使是離線版映像檔，建議準備好網路環境，以確保核心和工具的更新。若你非常熟悉 Arch Linux，也可自行決定是否需要網路。
• 如果使用無線網路，請確保 Wi-Fi 名稱使用英文，因為在 tty 環境下無法顯示中文，中文名稱會顯示為無法辨識的方塊字元。
• 如果計劃在同一顆硬碟上安裝雙系統，請為 Arch Linux 預留足夠的硬碟空間，建議至少 100GB 以便安裝其他軟體；並確保 EFI 分區容量不少於 256MB，或新增額外的掛載點。
• 檢查 Windows 10 分區是否啟用 BitLocker 加密，務必提前取得恢復金鑰，並關閉電源選項中的「快速啟動」功能！

在操作前，請務必仔細閱讀並針對不理解的部分進行搜尋學習，謹慎操作，及時備份，資料無價。

安裝媒介的製作

1. 建議僅從 Arch Linux 官方映像檔來源 下載，請注意，Arch Linux 是滾動更新發行版。
2. 若要自行編譯核心，請參考「核心/傳統編譯」。
3. 若使用官方提供的安裝映像檔，建議使用 Ventoy 燒錄。

基礎安裝

1. 使用 Arch Linux 引導碟

關機，插入 USB 隨身碟後開機，進入 BIOS 選擇從 USB 啟動，選取第一個選項並按 Enter，進入 Arch Linux 安裝環境。

2. UEFI 檢查

systemctl stop reflector.service
# 禁用自動更新軟體來源，因為地理因素可能影響網路環境，建議關閉。

ls /sys/firmware/efi/efivars
# 若顯示一串 EFI 變數，表示已使用 UEFI 模式啟動。2025 年的大多數機器皆為 UEFI 引導。

3. 連線網路

Arch Linux 安裝需要網路環境，離線安裝步驟較為繁瑣，可參考社群的 離線安裝指南。

有線網路連線無需多述，接上網路線後檢查介面指示燈是否閃爍，等待數秒後即可完成連線。

若在校園網路環境中，需由上層路由器完成認證，可參考 nbtverify 專案。

無線網路則使用 iwctl 進行連線。

lspci -k | grep Network
# 檢查無線網卡是否正常運作，若確認無問題可跳過此步。

檢查核心是否載入無線網卡驅動程式。

通常會顯示類似：00:14.3 Network controller: Intel Corporation Wi-Fi 6 AX201 (rev 20)。

若無顯示，檢查無線連線是否被禁用（blocked: yes）。

rfkill list
# 無線網卡通常命名為 wlan0。

ip link set wlan0 up
# 若出現類似「Operation not possible due to RF-kill」錯誤，則執行：
rfkill unblock wifi

# 使用 iwctl 連線網路
iwctl # 進入互動式命令列
device list # 列出無線網卡設備名稱，例如 wlan0
station wlan0 scan # 掃描網路
station wlan0 get-networks # 列出所有 Wi-Fi 網路
station wlan0 connect wifi-name # 連線至指定網路，注意無法輸入中文名稱。輸入密碼後按 Enter
exit # 連線成功後退出

ping www.google.com # 測試網路連通性

若網路設定遇到問題，可參考 [網路設定.wpi

System: 設定/無線網路設定](https://wiki.archlinux.org/title/Network_configuration/Wireless)。

5. 同步系統時間

timedatectl set-ntp true # 將系統時間與網路時間同步
timedatectl status # 檢查服務狀態

6. 更換台灣或國際軟體來源（若在國際網路環境可忽略）

vim /etc/pacman.d/mirrorlist # 準備更換軟體來源，若已透過代理連線國際網路可忽略
Server = https://free.nchc.org.tw/archlinux/$repo/os/$arch # 國家高速網路與計算中心
Server = https://archlinux.cs.nctu.edu.tw/$repo/os/$arch # 國立交通大學
Server = https://mirror.liquidtelecom.com/archlinux/$repo/os/$arch # Liquid Telecom

7. 建立 Btrfs 分區

查看磁碟資訊

lsblk

顯示當前分區情況。請仔細檢查你要安裝 Arch Linux 的目標硬碟名稱。

硬碟命名規則：

• SATA 協議：sda、sdb、sdc …… 分區為 sda1、sda2 等
• NVMe 協議：nvme0n1、nvme1n1 …… 分區為 nvme0n1p1、nvme0n1p2 等

示例以 SATA 硬碟為例，請根據實際情況替換 /dev/sdx。

cfdisk /dev/sdx

是否看到一個友好的 TUI 分區介面？😄

分區操作步驟

1. 建立 Swap 分區

• 使用方向鍵選中 Free space。
• 按下 [New] 並按 Enter，輸入大小（建議為記憶體大小的 60%~100%）。
• 按 [Type]，選擇 Linux swap。

2. 建立根分區（用於 Btrfs）

• 選中剩餘的 Free space，按 [New] 並按 Enter。
• 輸入大小（預設使用全部剩餘空間）。
• 保持類型為預設的 Linux filesystem。

3. 寫入分區表

• 選中 [Write]，輸入 yes 並按 Enter。

  ⚠️ 注意：若未寫入，之前的操作不會生效！

格式化分區

再次檢查磁碟

fdisk -l

格式化 EFI 分區（若需新建）

mkfs.fat -F32 /dev/sdxn

💡 若為雙系統使用者，可共用 Windows 的 EFI 分區，無需格式化，但需確保空間足夠，詳見 與 Windows 雙系統。

格式化 Swap 分區

mkswap /dev/sdxn

格式化 Btrfs 分區

mkfs.btrfs -L myArch /dev/sdxn

建立並掛載 Btrfs 子卷

mount -t btrfs -o compress=zstd /dev/sdxn /mnt

# 建立子卷
btrfs subvolume create /mnt/@        # 根目錄子卷
btrfs subvolume create /mnt/@home    # /home 子卷

umount /mnt

⚠️ 最後提醒

• 請再次檢查命令和操作的正確性！
• 誤操作可能導致資料遺失，尤其是誤刪 Windows 分區 😥

8. 掛載，從根目錄依序掛載

mount -t btrfs -o subvol=/@,compress=zstd /dev/sdxn /mnt # 掛載 / 目錄
mkdir /mnt/home # 建立 /home 目錄
mount -t btrfs -o subvol=/@home,compress=zstd /dev/sdxn /mnt/home # 掛載 /home 目錄
mkdir -p /mnt/boot # 建立 /boot 目錄
mount /dev/sdxn /mnt/boot # 掛載 /boot 目錄
swapon /dev/sdxn # 掛載交換分區

df -h # 檢查掛載
free -h # 檢查 Swap 分區掛載

9. 安裝系統

pacstrap /mnt base base-devel linux linux-firmware btrfs-progs
# 若使用 Btrfs 檔案系統，需額外安裝 btrfs-progs 套件

pacman -S archlinux-keyring
# 若提示 GPG 證書錯誤，可能是因為使用的不是最新映像檔，可透過更新 archlinux-keyring 解決

pacstrap /mnt networkmanager vim sudo zsh zsh-completions
# 使用 pacstrap 指令碼安裝必要的功能性軟體

10. 生成 fstab 檔案

生成 fstab 以定義磁碟分區，會受到當前掛載情況影響。

genfstab -U /mnt > /mnt/etc/fstab

11. 進入新系統

arch-chroot /mnt
# 程式碼高亮消失了？別擔心，這表示你已成功切換到新系統！

12. 設定主機名稱與時區

vim /etc/hostname
# 為你的電腦取個名字吧 XD（避免使用特殊字元和空格，否則可能出問題；不設定主機名稱也可能導致某些 GUI 程式異常終止，建議務必設定）

vim /etc/hosts
# 編輯主機 hosts 檔案

填入以下內容（將 myarch 替換為你設定的主機名稱，注意中間間隔使用 Tab 對齊）：

127.0.0.1   localhost
::1         localhost
127.0.1.1   myarch.localdomain  myarch

ln -sf /usr/share/zoneinfo/Asia/Taipei /etc/localtime
# 在台北時區建立符號連結

ls /usr/share/zoneinfo/
# 檢查可用時區，必要時更換上述命令中的時區路徑

13. 硬體時間設定

hwclock --systohc
# 將系統時間同步至硬體時間

14. 設定語系

vim /etc/locale.gen
# 編輯 /etc/locale.gen，移除 en_US.UTF-8 UTF-8 和 zh_TW.UTF-8 UTF-8 行前的註解符號（#）
# 此步驟決定軟體使用的語言和字元集

locale-gen
# 生成語系

echo 'LANG=en_US.UTF-8' > /etc/locale.conf
# 設定 locale.conf，不建議使用中文語系，否則 tty 可能出現亂碼

15. 設定 root 密碼

passwd root
# 輸入密碼時不會顯示，屬正常現象，非鍵盤故障 XD

16. 安裝微碼

pacman -S intel-ucode # Intel 處理器
Джpacman -S amd-ucode # AMD 處理器

17. 安裝 Grub 引導程式

pacman -S grub efibootmgr os-prober
# grub 為啟動引導程式，efibootmgr 用於向 NVRAM 寫入啟動項，os-prober 用於引導 Windows 10

grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=ARCH
# 將 grub 安裝至 EFI 分區

vim /etc/default/grub
# 編輯啟動參數

# 將 "loglevel=3 quiet" 修改為 "loglevel=5 nowatchdog"
# 在檔案末尾新增一行：GRUB_DISABLE_OS_PROBER=false

• 移除 GRUB_CMDLINE_LINUX_DEFAULT 行中的 quiet 參數。
• 將 loglevel 的數值從 3 改為 5，以便在系統錯誤時方便排錯。
• 加入 nowatchdog 參數，可顯著提升開關機速度。
• 加入 os-prober 參數，用於引導 Windows 10。

grub-mkconfig -o /boot/grub/grub.cfg
# 生成 grub 所需的設定檔
# 若檢測到 Windows 10，會顯示一行類似「Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi done」的回顯
# 若 Windows 10 位於另一顆硬碟，可能不會顯示，進入系統後重新掛載並再次執行即可

有關全部參數的說明，可參考 Arch Wiki。

18. 完成安裝

exit # 返回安裝環境
umount -R /mnt # 卸載新分區
reboot # 重新啟動

重新啟動後使用 root 帳戶登入。

systemctl enable --now NetworkManager # 設定開機自啟並立即啟動 NetworkManager 服務
ping www.google.com # 測試網路連通性

若使用無線網路：

nmcli dev wifi list # 顯示附近的 Wi-Fi 網路
nmcli dev wifi connect "Wi-Fi 名稱（SSID）" password "網路密碼" # 連線至指定的無線網路

nmtui
# 個人較推薦 nmtui，介面較為友好 XD

pacman -S fastfetch
fastfetch
# 安裝 fastfetch，檢查系統資訊
# 喜聞樂見的 neofetch 時刻 XD

shutdown 0
shutdown -h now
poweroff
# 以上三個命令皆為關機，🤣 記得關機，因為電源策略尚未設定

恭喜 🎉

至此，你已完成一個基礎的無圖形介面的 Arch Linux 安裝！

圖形化介面的安裝指南將在下次更新發布，還是那句老話：多閱讀官方手冊！

本文旨在拋磚引玉，希望吸引更多同好加入技術交流的行列！

友情連結：NBTCA

• 📧 NBTCA 電子郵件：contact@nbtca.com
• 🌐 NBTCA GitHub：https://github.com/nbtca

服務端渲染 (SSR) 極大地改善了 Web 應用程式的「首屏載入速度」 (FCP)。瀏覽器直接接收到完整的 HTML 內容並立刻渲染，使用者能很快看到頁面內容，這對 SEO 和使用者感知都非常友善。

但此時的頁面只是一個「靜態的空殼」。雖然看起來已經載入完畢，但頁面上的按鈕點擊、輸入框互動都毫無反應。為了讓這個靜態頁面「活」過來，我們需要一個過程，這個過程就是 Hydration（注水／啟用）。

2. 什麼是 Hydration？

Hydration 是指客戶端的 JavaScript 框架「接管」由服務端渲染的靜態 HTML 的過程。

這個過程大致如下：

1. 瀏覽器下載並執行頁面所需的 JavaScript 套件（例如 React、Vue 的執行階段和業務程式碼）。
2. 框架在記憶體中重新建構元件樹。
3. 框架遍歷服務端渲染的 DOM，並將事件監聽器（如 onClick）附加到對應的 DOM 節點上。
4. 框架確保客戶端的元件狀態與服務端渲染時的狀態一致。

完成之後，頁面才真正變得可互動。可以把 Hydration 想像成：你收到一個已經拼好的樂高模型（HTML），但為了讓模型的某個元件能動，你必須把整個模型的拼裝說明書（JS）從頭到尾讀一遍，並檢查一遍所有積木的位置，然後才給那個元件裝上電池（附加事件監聽器）。

3. Hydration 的問題：「非互動的互動介面」

Hydration 解決了 SSR 頁面無法互動的問題，但它自身也帶來了新的效能瓶頸，即所謂的 「非互動幽谷」 (Uncanny Valley) 或 「注水延遲」 (Hydration Gap)。

這個問題指的是從使用者看到頁面內容 (FCP) 到頁面可以真正回應使用者互動 (TTI) 之間存在一個時間差。在這個時間差內，頁面看起來是可用的，但實際上是「假死」狀態。

造成這個問題的原因是：

• JS 下載和執行阻塞: 瀏覽器必須下載、解析並執行大量的 JavaScript 程式碼，才能開始 Hydration 過程。
• 昂貴的啟動成本: 框架需要在客戶端執行大量工作來重新建構元件樹和附加事件監聽器，即使頁面上 90% 的內容都是非互動的靜態內容。

4. Hydration 的最佳化與替代方案

為了解決 Hydration 的效能問題，社群探索出了多種更先進的模式。

a. 局部注水 (Partial Hydration)

Astro 框架推廣的 島嶼架構 (Islands Architecture) 是局部注水的典型實作。其核心思想是：預設情況下，所有元件都只輸出純靜態 HTML（零 JS）。對於需要互動的元件，你可以將其明確標記為一個「島嶼」。

建置時，Astro 只會為這些「島嶼」元件打包並傳送 JavaScript。這樣，瀏覽器只需對頁面上的幾個孤立部分進行 Hydration，而不是整個頁面，極大地減少了啟動時需要載入和執行的 JS 量。

b. 漸進式注水 (Progressive Hydration)

這是一種更細粒度的最佳化策略，它按照一定的優先順序來 Hydrate 元件。例如，可以優先 Hydrate 視口內或使用者即將互動的元件，而延遲處理頁面底部的、非關鍵的元件。

c. 可恢復性 (Resumability)

Qwik 框架提出了一個革命性的概念——Resumability，旨在完全消滅 Hydration。

它的運作方式是：

1. 序列化: 在服務端，Qwik 將應用程式的所有狀態、元件關係、事件監聽器等資訊全部序列化，並嵌入到 HTML 中。
2. 恢復: 在客戶端，Qwik 的極小執行階段（約 1KB）不需要在啟動時重新建構元件樹或附加所有事件。它透過一個全域的事件監聽器，可以精確地知道當使用者點擊某個按鈕時，應該去下載並執行哪一小塊程式碼。

Qwik 的目標是實現 即時互動 (Instant-on)。它不是「重新執行」一遍服務端的工作，而是從服務端停止的地方「恢復」執行。

結論

Hydration 是連接服務端渲染和客戶端互動的橋樑，但在傳統實作中，它是一個昂貴且可能損害使用者體驗的過程。現代前端框架正在透過局部注水（Astro）和可恢復性（Qwik）等創新模式，努力擺脫 Hydration 這個「必要之惡」，向著更極致的效能和更快的互動速度邁進。

長久以來，JavaScript 幾乎是 Web 前端開發的唯一語言。儘管它非常成功，但作為一種動態直譯語言，其效能在處理 CPU 密集型工作（如 3D 算繪、影片編解碼、複雜運算）時始終存在瓶頸。

WebAssembly（簡稱 WASM）的出現，正是為了打破這一局面。它不是要取代 JavaScript，而是作為一種強大的補充，為 Web 平台帶來前所未有的效能和可能性。

2. 什麼是 WebAssembly？

WebAssembly 是一種為堆疊式虛擬機器設計的二進位指令格式。它是一種低階、類似組合語言的語言，但並不是讓開發者直接撰寫的。

相反地，它被設計為 C、C++、Rust、Go 等高階語言的編譯目標。你可以用這些高效能語言撰寫程式碼，再將它們編譯成 .wasm 檔案，在瀏覽器中以接近原生的速度執行。

關鍵點：

• 它不是 JavaScript 的替代品：WASM 與 JavaScript 是合作夥伴關係。
• 它是一種編譯目標：你撰寫 C++／Rust，再編譯成 WASM。
• 它快速、高效且可攜：設計之初就以效能為核心。

3. JavaScript 與 WASM 的協作模式

WASM 模組本身執行於沙箱環境中，無法直接存取 DOM、呼叫 Web API 或發出網路請求。所有這些操作都需要由 JavaScript 擔任「膠水」層加以仲介。

典型的協作模式是：

1. JavaScript 負責編排：JS 程式碼負責應用程式的整體邏輯、處理使用者事件、更新 DOM。
2. WASM 負責運算：遇到運算密集型工作時，JS 會呼叫從 .wasm 模組匯出的函式。
3. 資料交換：JS 和 WASM 之間可以高效地交換資料，主要是數字型別和線性記憶體區塊。

可以把 JavaScript 想像成「經理」，而 WebAssembly 則是「專家級工程師」。經理負責溝通和協調，工程師則負責解決最棘手的技術難題。

4. 現實世界中的應用案例

WASM 已經不再是一項實驗性技術，許多頂尖 Web 應用程式都在使用它驅動核心功能：

• Figma：這款熱門線上設計工具的核心算繪引擎以 C++ 撰寫並編譯為 WASM，因此能提供流暢的圖形編輯體驗。
• Adobe Photoshop & Lightroom：Adobe 成功地透過 WASM，將其旗艦桌面應用程式的 C++ 核心程式碼庫移植到 Web 上，讓使用者可以在瀏覽器裡使用功能強大的 Photoshop。
• Google Earth：新版 Google Earth 完全在瀏覽器中執行，其複雜的 3D 地球算繪正是由 WASM 驅動。
• AutoCAD Web App：Autodesk 將其龐大的 C++ CAD 引擎編譯為 WASM，實現在瀏覽器中執行完整的 AutoCAD。

這些案例證明，WASM 已經有能力將過去被認為只有桌面應用程式才能勝任的複雜軟體帶到 Web 平台。

5. 未來：WASI 與瀏覽器之外

WASM 的雄心不只在瀏覽器。WASI（WebAssembly System Interface） 是一項新興標準，旨在為 WASM 提供一套標準的系統級 API（如檔案系統、網路存取等）。

這代表未來 .wasm 檔案可能成為一種通用、跨平台且安全的二進位格式，可以在任何地方執行——從伺服器（挑戰 Docker）、邊緣運算節點，到物聯網裝置，真正實現「一次編譯，到處執行」。

結論

WebAssembly 正在深刻改變我們對 Web 應用程式能力邊界的認知。它讓 JavaScript 能專注於最擅長的領域——UI 互動和應用程式邏輯編排，並將效能的「天花板」交給由 Rust、C++ 等系統級語言編譯而來的 WASM 模組。對前端開發者來說，理解 WASM 的能力與適用情境，將是建構下一代高效能 Web 應用程式的關鍵。

在 Web 開發中，我們長期面臨一個體驗上的兩難選擇：

• 多頁應用程式 (MPA): 架構簡單、穩定，但每次頁面跳轉都會有一次完整的載入，帶來「白屏」或「閃爍」，體驗不連貫。
• 單頁應用程式 (SPA): 透過前端路由實現了流暢的「無重新整理」體驗，但開發者需要手動處理複雜的過渡動畫、狀態管理和程式碼分割，開發成本高昂。

有沒有一種方法，既能保持 MPA 的簡單性，又能獲得 SPA 的流暢過渡體驗？View Transitions API 正是為此而生。

2. View Transitions API 是什麼？

View Transitions API 是一個瀏覽器原生 API，它提供了一種機制，讓我們能夠輕鬆地在兩個不同的 DOM 狀態之間建立動畫過渡。

它的核心工作流程非常簡單：

1. 當你觸發一個轉換時，API 會對目前頁面（舊狀態）進行「截圖」。
2. 然後，你用 JavaScript 更新 DOM 到新狀態。
3. API 會對新頁面（新狀態）也進行「截圖」。
4. 最後，瀏覽器會在「舊截圖」和「新截圖」之間建立一個平滑的預設過渡動畫（通常是淡入淡出）。

這一切都由瀏覽器在底層高效處理，我們只需要呼叫一個簡單的函式。

3. 如何使用？

在單頁應用程式中，使用 View Transitions 非常簡單。只需將你的 DOM 更新邏輯包裹在 document.startViewTransition 函式中即可。

// 假设你有一个更新页面内容的函数
async function updatePageContent(url) {
  const response = await fetch(url);
  const newHtml = await response.text();
  // 用新内容替换旧内容 (具体实现取决于你的架构)
  document.body.innerHTML = newHtml;
}

// 在导航链接的点击事件中调用
document.querySelector('a').addEventListener('click', (event) => {
  event.preventDefault();
  const url = event.target.href;

  // 检查浏览器是否支持
  if (!document.startViewTransition) {
    updatePageContent(url); // 不支持则直接更新
    return;
  }

  // 使用 View Transition
  document.startViewTransition(() => updatePageContent(url));
});

僅僅這樣，你的頁面跳轉就會帶上一個預設的淡入淡出效果！

4. 自訂過渡動畫

預設的淡入淡出效果很棒，但 API 的真正威力在於其可自訂性。當 startViewTransition 執行時，瀏覽器會建立一個包含以下偽元素的 DOM 結構：

• ::view-transition: 根元素，包含了整個過渡。
• ::view-transition-old(root): 舊檢視的「截圖」。
• ::view-transition-new(root): 新檢視的「截圖」。

我們可以透過 CSS animation 來覆蓋預設效果，例如實現一個滑入動畫：

@keyframes slide-in {
  from { transform: translateX(100%); }
}

::view-transition-new(root) {
  animation: slide-in 0.5s ease-out;
}

5. 元素間的「變形」：view-transition-name

API 最令人驚豔的功能是能夠讓兩個頁面中的 不同元素 被識別為 同一個物件，並在這兩個元素之間建立平滑的「變形」動畫。

這透過 view-transition-name 這個 CSS 屬性實現。

頁面 A（列表頁）:

<img src="thumbnail.jpg" style="view-transition-name: hero-image;" />

頁面 B（詳細頁）:

<img src="full-size.jpg" style="view-transition-name: hero-image;" />

當從頁面 A 跳轉到頁面 B 時，瀏覽器看到兩個元素的 view-transition-name 相同，它就會自動計算它們在位置、尺寸、形狀上的差異，並產生一個平滑的過渡動畫，而不是簡單的淡入淡出。這對於圖片、卡片等元素的過渡效果極佳。

結論

View Transitions API 為 Web 帶來了期待已久的原生過渡能力。它極大地簡化了過去需要複雜 JavaScript 動畫函式庫才能實現的互動效果，讓打造電影般流暢的應用程式體驗變得前所未有的簡單。隨著 Astro、Nuxt 等框架的整合，以及未來在多頁應用程式中的普及，它必將成為現代 Web 開發者的標準技能之一。

React Server Components（RSC）是一種新的 React 元件類型，它在建置時或在伺服器上被渲染。與傳統的、在客戶端瀏覽器中渲染的元件（現在稱為「Client Components」）不同，RSC 的程式碼永遠不會被傳送到客戶端。瀏覽器接收到的僅僅是渲染好的 HTML 或一種特殊的串流格式。

這標誌著 React 從一個純粹的客戶端函式庫，演變為一個可以在伺服器和客戶端之間無縫運作的全端框架。

2. RSC 解決了哪些問題？

RSC 的出現主要是為了解決以下幾個核心痛點：

• 巨大的 JavaScript 套件體積: 傳統 React 應用程式會將所有元件的 JS 程式碼（包括那些不直接互動的）打包傳送到客戶端，導致初始載入緩慢。RSC 允許我們將大量元件（如文字、版面配置、資料展示）保留在伺服器端，從而實現零 JS 體積。
• 請求瀑布（Request Waterfalls）: 在客戶端取得資料的典型模式是：渲染元件 -> useEffect -> 發起請求 -> 等待資料 -> 再次渲染。如果元件巢狀層級很深，就會形成請求瀑布，拖慢頁面呈現速度。RSC 可以在伺服器端直接以 async/await 取得資料，將資料和元件一起串流傳輸到客戶端，從根本上解決這個問題。
• 直接存取後端資源: RSC 執行在伺服器端環境中（如 Node.js），這意味著它們可以直接、安全地存取資料庫、檔案系統或內部 API，無需再向客戶端暴露額外的 API 端點。

3. Server Components vs. Client Components

理解兩者的區別是掌握 RSC 的關鍵。

經驗法則: 預設將所有元件視為 Server Components。只有當你的元件需要使用 useState、useEffect 或處理使用者事件（onClick 等）時，才在檔案頂部加入 "use client"; 指令，將其標記為 Client Component。

4. 它們如何協同運作？

一個現代 React 應用程式會是兩者的混合體。例如，一個部落格文章頁面：

• PageLayout（Server Component）: 負責整體版面配置。
• ArticleContent（Server Component）: 從資料庫或 Markdown 檔案中取得文章資料並渲染。
• LikeButton（Client Component）: 包含 useState 和 onClick 事件來處理按讚互動。
• Comments（Client Component）: 取得並顯示留言，包含表單送出等互動。

伺服器端元件可以在伺服器端「持有」客戶端元件的「位置」，最終在瀏覽器中將兩者無縫地拼接在一起。

結論

React Server Components 是一次深刻的範式轉變，它將 React 的能力從瀏覽器擴充套件到了伺服器，帶來了顯著的效能優勢和更優的開發體驗。雖然它引入了新的心智模型，但透過 Next.js App Router 等框架的實踐，RSC 正在快速成為建構高效能、可擴充 Web 應用程式的新標準。

在 Node.js 應用程式中，我們透過 process.env 存取環境變數。這是一套簡單有效的機制，但它存在一個固有問題：型別不安全。

process.env 物件的值不是 string，就是 undefined。這會造成幾個常見問題：

• 意外的 undefined：如果你忘了在 .env 檔案或伺服器上設定某個變數，process.env.MY_VAR 在執行階段會是 undefined，可能在程式碼深層邏輯中導致 TypeError。
• 型別不符：你可能預期連接埠號是 number 型別，但 process.env.PORT 始終是字串，因此必須在使用它的地方手動呼叫 parseInt。
• 驗證邏輯分散：我們常在程式碼各處撰寫防禦性程式碼，例如 const port = process.env.PORT || 3000;，使環境變數的管理變得混亂。

2. 核心原則：啟動時失敗（Fail-Fast）

對環境變數這類關鍵設定而言，最佳實務是 「啟動時失敗」（Fail-Fast）。

這代表應用程式應在啟動最初階段，就檢查所有必要環境變數是否均已提供且格式正確。若有任何問題，應用程式應立即擲回錯誤並停止執行，而不是在未來某個不確定的時間點因設定錯誤而崩潰。

這樣能讓我們在部署或開發時立即發現設定問題，而不是等到使用者存取時才發現。

3. 使用 Zod 實作型別安全驗證

Zod 是一個以 TypeScript 為優先的 schema 宣告與驗證函式庫，非常適合用來解決環境變數的型別安全問題。

我們的策略是：

1. 為所有環境變數定義一個 Zod schema。
2. 在應用程式啟動時，用這個 schema 解析 process.env。
3. 如果解析失敗，也就是驗證未通過，Zod 會擲回錯誤，應用程式啟動失敗。
4. 如果解析成功，我們會得到一個完整型別化的物件，並在整個應用程式中使用它。

實作範例

首先安裝 Zod：pnpm add zod

接著，建立一個專門處理環境變數的檔案，例如 src/env.ts：

// src/env.ts
import { z } from 'zod';

// 1. 定义 Schema
const envSchema = z.object({
  NODE_ENV: z.enum(['development', 'production', 'test']).default('development'),
  DATABASE_URL: z.string().min(1, 'DATABASE_URL is required.'),
  PORT: z.coerce.number().int().positive().default(3000),
  // z.coerce 会尝试将字符串转换为数字
});

// 2. 解析和导出
// .parse 会在验证失败时抛出错误，实现 "Fail-Fast"
export const env = envSchema.parse(process.env);

現在，你可以在應用程式的任何其他地方從 src/env 匯入 env 物件。

// src/server.ts
import { env } from './env'; // 导入经过验证和类型化的 env 对象

// env.PORT 的类型是 `number`，而不是 `string | undefined`
const port = env.PORT;

// env.NODE_ENV 的类型是 'development' | 'production' | 'test'
if (env.NODE_ENV === 'development') {
  console.log('Running in development mode');
}

// 如果 DATABASE_URL 未设置，应用在启动时就已经崩溃了，
// 所以在这里我们可以放心地认为它是存在的，并且类型是 `string`。
connectToDatabase(env.DATABASE_URL);

4. 帶來的好處

這種模式能立即帶來好處：

• 完整的型別安全：在程式碼中存取 env.PORT 時，TypeScript 知道它是一個 number。
• 集中的文件和驗證：env.ts 檔案本身就成了環境變數的權威文件，所有驗證邏輯也都集中於此。
• 可靠的執行階段：杜絕因環境變數拼寫錯誤、缺失或格式不正確而造成的執行階段 Bug。
• Fail-Fast：任何設定問題都會在部署或開發的第一時間被發現。

結論

將環境變數的驗證提前到應用程式啟動時，並使用 Zod 這類工具保證型別安全，是一項投入產出比極高的工程實務。它能顯著提升應用程式的健全性與開發者信心，是現代 TypeScript 專案不可或缺的一環。

2024 年初，Vue 團隊發布了 3.4 版本，代號為「Slam Dunk」。這次更新雖然不像 3.0 那樣具有顛覆性，卻在兩個關鍵領域帶來重要改進：內部效能最佳化和開發者體驗提升。

其中最引人注目的變化，包括重寫的響應式系統、穩定的 defineModel API，以及更簡潔的 v-bind 語法。

2. 響應式系統重構

Vue 3.4 對核心響應式系統進行了大規模重構。這次重構的主要目標，是提升 computed 計算屬性的效率。

在舊版本中，即使計算屬性的相依項目沒有實際變化，也可能會進行不必要的重新計算。新版本透過更智慧的相依性追蹤，確保只在真正需要時才觸發計算，從而減少不必要的元件重新算繪。

對大部分開發者來說，這是一頓「免費的午餐」——你不需要修改任何程式碼，升級到 3.4 版本後便能自動享有效能提升。

3. defineModel：優雅的元件雙向綁定

在 3.4 版本之前，要在元件上實作類似 v-model 的雙向綁定，需要撰寫不少樣板程式碼：

之前 👎：

<script setup>
const props = defineProps(['modelValue'])
const emit = defineEmits(['update:modelValue'])

// 通常需要一个计算属性来包装
const value = computed({
  get: () => props.modelValue,
  set: (val) => emit('update:modelValue', val)
})
</script>

<template>
  <input v-model="value" />
</template>

Vue 3.4 將 defineModel API 從實驗階段轉為正式穩定。現在，實作上述功能只需要一行程式碼：

現在（Vue 3.4）👍：

<script setup>
const model = defineModel()
</script>

<template>
  <input v-model="model" />
</template>

defineModel 巨集會自動註冊 modelValue prop 和 update:modelValue 事件，並回傳一個可直接讀寫的 ref。這大幅簡化了支援 v-model 的元件開發。

4. v-bind 同名屬性簡寫

另一項提升開發體驗的語法糖，是 v-bind 的同名簡寫。當傳給元件的 prop 與你在 <script setup> 中定義的變數同名時，現在可以省略屬性值。

之前 👎：

<script setup>
const id = 'my-id'
const title = 'Hello Vue'
</script>

<template>
  <MyComponent :id="id" :title="title" />
</template>

現在（Vue 3.4）👍：

<script setup>
const id = 'my-id'
const title = 'Hello Vue'
</script>

<template>
  <MyComponent :id :title />
</template>

這個小改動讓範本程式碼變得更加清爽易讀。

結論

Vue 3.4 是一次紮實的迭代。它透過底層的效能最佳化和上層的 API 簡化，進一步鞏固了 Vue 作為一個「漸進式」框架的理念——既為大型應用程式提供強大的效能保障，也為日常開發帶來實實在在的便利。特別是 defineModel 的穩定，解決了長久以來元件封裝中的一個痛點，是本次更新中最值得稱讚的亮點。

在現代前端開發中，一個專案通常需要一套複雜的工具組合才能順利執行：

• Linter：ESLint 用於檢查 JavaScript/TypeScript 程式碼品質。
• Formatter：Prettier 用於統一程式碼風格。
• Compiler：Babel 或 TypeScript（tsc）用於程式碼轉換。
• Bundler：Webpack、Rollup 或 Vite 用於打包。

管理這些工具的設定、外掛、版本和彼此間的互動，本身就是一項不小的工作，這便是所謂的「工具疲勞」。多年來，社群一直在探索「一體化工具鏈」的可能性，希望能用一個工具解決所有問題。

2. Rome 的願景與 Biome 的誕生

Rome 是由 Facebook 前員工、Babel 作者 Sebastian McKenzie 發起的雄心勃勃專案，旨在用 TypeScript 重寫整個前端工具鏈。它的願景是提供一個零設定、高效能的統一工具。然而，在經歷多年開發和商業化嘗試後，Rome Labs 公司於 2023 年宣布停止營運。

幸運的是，Rome 的核心程式碼是開源的。社群迅速行動起來，建立了一個名為 Biome 的分支，並由專門的社群組織維護，旨在繼承並實現 Rome 最初的願景。

3. Biome 是什麼？

Biome 是一個用 Rust 重寫的高效能前端工具鏈。它旨在提供統一、極速的開發體驗，以取代 ESLint、Prettier 等一系列獨立工具。

截至 2023 年底，Biome 的核心功能主要集中在 Linter 和 Formatter 上，並在這兩方面展現出驚人的實力。

主要優勢：

• 極致效能：得益於 Rust 語言，Biome 的執行速度遠超用 JavaScript 編寫的 ESLint 和 Prettier。對於大型程式碼庫，其效能提升可達一個數量級。
• 統一設定：只需一個 biome.json 檔案，即可管理所有工具的行為，告別散落各處的 .eslintrc、.prettierrc、.editorconfig。
• 詳盡的診斷資訊：Biome 的 Linter 不只能指出錯誤，還能提供非常詳盡的上下文和修正建議，協助開發者理解問題根源。
• 與 Prettier 相容：Biome 的格式化工具旨在與 Prettier 95% 以上的規則相容，使得從 Prettier 遷移的成本非常低。

4. 快速上手

你可以透過 npx 快速在專案裡嘗試 Biome：

# 检查当前项目中的代码问题
npx @biomejs/biome check ./src

# 自动修复可修复的 lint 问题
npx @biomejs/biome check --apply ./src

# 格式化代码
npx @biomejs/biome format --write ./src

建立一個 biome.json 檔案可以讓你自訂規則和設定：

{
  "$schema": "https://biomejs.dev/schemas/1.4.1/schema.json",
  "organizeImports": {
    "enabled": true
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  }
}

5. 未來展望

Biome 的發展藍圖非常清晰：在穩定 Linter 和 Formatter 的基礎上，逐步實現 Compiler、Bundler、Test Runner 等功能，最終成為一個名副其實的「一體化」工具鏈。

雖然它還很年輕，但 Biome 憑藉出色的效能、社群驅動的開放模式，以及對開發者體驗的專注，已經成為前端工具領域一股不容忽視的新生力量。對於尋求簡化工具堆疊、提升開發效率的團隊而言，Biome 提供了一個非常有吸引力的未來選項。

十多年來，Node.js 一直是伺服器端 JavaScript 的代名詞。儘管 Deno 在安全性和現代 API 方面提出了新的思路，但 Node.js 的地位似乎從未被真正動搖。然而，在 2023 年 9 月，隨著 Bun 1.0 正式發布，情況可能將迎來改變。

Bun 不只是另一個 JavaScript 執行環境，它是一個從零開始設計、注重效能的「一體化」工具包，旨在涵蓋從開發到部署的整個生命週期。

2. Bun 的核心：速度、速度，還是速度

Bun 的首要設計目標就是效能。為了實現這一點，它做出了幾個與眾不同的技術選擇：

• Zig 語言：Bun 的底層由 Zig 編寫，這是一種現代、注重效能和記憶體控制的系統程式語言，使其能對底層細節進行極致最佳化。
• JavaScriptCore 引擎：與使用 Google V8 引擎的 Node.js 和 Deno 不同，Bun 選擇了 Apple 的 JavaScriptCore（JSC）引擎。JSC 以更快的啟動速度和通常更低的記憶體消耗而聞名。

這些選擇使 Bun 在指令碼啟動、bun install 速度以及內建 API 的執行效率上，都展現出驚人的效能數據。

3. 不只是一個執行環境

Bun 的「一體化」設計是另一大特色。它不只是一個 node 指令的替代品，還內建了：

• 套件管理器：bun install 的速度是 npm install 的數倍甚至數十倍。它使用全域模組快取和高效的相依性解析演算法，大幅縮短安裝時間。
• 建置工具／打包器：Bun 內建高效能打包器，可以直接將專案打包成可執行檔或瀏覽器使用的程式碼，其效能可與 esbuild 相比。
• 原生轉譯器：你可以直接執行 TypeScript（.ts）和 JSX（.jsx、.tsx）檔案，無須預先設定 tsc 或 babel。Bun 會在執行時高速轉換它們。
• 測試執行器：bun test 提供與 Jest 高度相容的測試環境，但執行速度快得多。

這表示，對於一個新專案，你可能只需要安裝 bun 這一個工具，就能完成開發、測試和打包的全過程。

4. Node.js 相容性

為了方便遷移，Bun 團隊投入大量精力實現與 Node.js API 的相容性。它內建對 node_modules 解析、CommonJS（require）和 ESM（import）模組，以及大量 Node.js 核心模組（如 fs、path、http）的支援。

對於許多現有的 Node.js 專案，理論上可以直接用 bun 執行，並立即享受效能提升。

5. 挑戰與未來

Bun 的出現挑戰了前端界長期以來「組合小型專用工具」的哲學。它的「大而全」模式帶來無與倫比的便利性和開箱即用的高效能，但也可能犧牲一部分彈性。

Node.js 擁有極其龐大且成熟的生態系統，這是 Bun 在短期內難以企及的。然而，Bun 1.0 的發布標誌著它已為正式環境做好準備。其驚人的效能和一體化開發體驗，對新專案和追求極致效率的團隊而言，具有難以抗拒的吸引力。

無論 Bun 未來能否顛覆 Node.js 的地位，它的出現都已經為 JavaScript 工具鏈的發展注入新的活力，並設立了新的效能標竿。

如果你寫過幾年前的前端程式碼，一定對 Sass 或 Less 不陌生。在這些 CSS 前處理器中，有一個功能幾乎是所有開發者的最愛：選擇器巢狀（Nesting）。它允許我們像寫 HTML 一樣，將子選擇器的規則寫在父選擇器內部，大幅提升程式碼的可讀性和組織性。

// Sass 语法
nav {
  ul {
    margin: 0;
    padding: 0;
    list-style: none;
  }

  li { display: inline-block; }

  a {
    display: block;
    padding: 6px 12px;
    text-decoration: none;
  }
}

多年來，我們一直依賴建置工具將這種語法編譯成瀏覽器認得的普通 CSS。但現在，情況變了。

2. 原生 CSS 巢狀登場

從 2023 年初開始，主流瀏覽器（Chrome、Safari、Firefox）陸續宣布支援原生 CSS Nesting Module。這表示，我們可以直接在 .css 檔案裡編寫巢狀規則，無須任何前處理。

上面的範例用原生 CSS 可以這樣寫：

/* 原生 CSS 语法 */
nav {
  ul {
    margin: 0;
    padding: 0;
    list-style: none;
  }

  li { display: inline-block; }

  a {
    display: block;
    padding: 6px 12px;
    text-decoration: none;
  }
}

是的，它看起來和 Sass 完全一樣！

3. & 的重要角色

和前處理器一樣，& 符號在原生巢狀中也扮演關鍵角色，它代表父選擇器。這在處理虛擬類別、虛擬元素或組合選擇器時非常有用。

.card {
  background: white;
  border-radius: 8px;

  /* & 代表 .card */
  &:hover {
    box-shadow: 0 4px 12px rgba(0,0,0,0.1);
  }

  /* & 代表 .card，组合成 .card.dark-mode */
  &.dark-mode {
    background: #333;
  }

  /* & 代表 .card，组合成 .card > .header */
  > .header {
    font-weight: bold;
  }
}

4. 與 Sass 的一個微小但重要的差異

在 Sass 中，你可以直接巢狀類別選擇器，例如 .card { .title { ... } }。在原生 CSS Nesting 的早期規範中，這是不允許的，任何巢狀規則都必須以一個符號（如 &、>、+、~）開頭。

雖然最新規範放寬了這一限制，允許直接巢狀標籤選擇器（如 article { h1 { ... } }），但在巢狀類別選擇器時，為了明確並避免歧義，最佳實務仍然是使用 &。

/* 推荐写法 */
.article {
  & .author-name {
    font-style: italic;
  }
}

/* 不推荐的写法 (在某些早期实现或严格解析器中可能无效) */
.article {
  .author-name {
    font-style: italic;
  }
}

使用 & 可以清楚表達 .author-name 是 .article 的後代。

5. 瀏覽器支援與未來

截至 2023 年 9 月，所有主流現代瀏覽器（Chrome 112+、Safari 16.5+、Firefox 117+）均已支援 CSS Nesting。這表示我們可以開始在正式環境中逐步使用它。

原生 CSS 巢狀的到來，是 Web 平台自身演進的另一個重要里程碑。它減少我們對建置工具的依賴，讓 CSS 本身變得更強大且富有表現力，也讓剛入門的前端開發者能更直觀地編寫和理解樣式程式碼。

在 Utility-First 出現之前，我們有許多優秀的 CSS 方法論來組織樣式，例如：

• BEM (Block, Element, Modifier): 透過 block__element--modifier 的命名約定來保證樣式的獨立性和可維護性。
• OOCSS (Object-Oriented CSS): 提倡將結構與外觀分離，以及容器與內容分離。
• CSS-in-JS: 將 CSS 直接寫入 JavaScript 元件中，實現了元件層級的樣式封裝。

這些方法在一定程度上解決了 CSS 全域污染和程式碼組織的問題，但通常也帶來了新的問題：為無數的 class 命名所耗費的心力、檔案切換的繁瑣，以及 CSS-in-JS 可能帶來的執行階段開銷。

2. 什麼是 Utility-First？

Utility-First（功能優先）是一種 CSS 思想，它主張提供一系列 單一用途、命名不變的功能類別，然後透過組合這些類別來建構複雜的 UI。

例如，你不會去寫一個 .card 類別，然後在 CSS 檔案裡定義它的 display、padding、box-shadow。 取而代之的是，你直接在 HTML 中這樣寫：

<div class="block p-6 rounded-lg shadow-lg bg-white">
  
</div>

這裡的 block、p-6、rounded-lg 等都是功能類別，它們各自只負責一件小事。

3. Tailwind CSS：Utility-First 的典範

Tailwind CSS 是目前最流行的 Utility-First CSS 框架。它提供了一套極其詳盡的功能類別，幾乎涵蓋了所有常用的 CSS 屬性。

核心優勢:

• 極速開發: 你幾乎不需要離開 HTML 檔案。透過組合原子類別，可以快速建構出任何設計，極大地提升了原型設計和開發的效率。
• 強制設計系統: 由於所有的樣式（顏色、間距、字號）都來自預先定義的設定 (theme)，團隊成員可以輕鬆地保持 UI 的一致性，避免了「魔法數字」的出現。
• 無需為命名煩惱: 「電腦科學兩大難題：快取失效和命名。」Tailwind 讓你基本告別了為 CSS 類別命名的煩惱。
• 極致效能: 在正式環境建置時，Tailwind 會掃描你的檔案，透過 PurgeCSS（或內建的 JIT 引擎）移除所有未被使用的 CSS 類別，最終的 CSS 檔案體積通常會非常小。

4. 「類別名稱地獄」？—— 看待缺點的不同視角

對 Tailwind 最常見的批評就是它讓 HTML 變得非常臃腫，可讀性差，像是回到了「行內樣式」的時代。

<button class="py-2 px-4 font-semibold rounded-lg shadow-md text-white bg-blue-500 hover:bg-blue-700">
  Click me
</button>

這確實是一個需要適應的過程。但支持者認為：

1. 樣式和結構本就緊密耦合，將它們放在一起反而更便於維護。
2. 透過提取可重複使用的元件（如 React/Vue 元件），可以將這部分「混亂」封裝起來。

對於需要重複使用的樣式組合，Tailwind 提供了 @apply 指令：

/* in your css file */
.btn-primary {
  @apply py-2 px-4 font-semibold rounded-lg shadow-md text-white bg-blue-500 hover:bg-blue-700;
}

這樣你就可以在 HTML 中使用 .btn-primary 了。不過，Tailwind 官方更推薦透過元件化來解決重複使用問題。

結論

Utility-First 和 Tailwind CSS 的成功，標誌著前端開發在「關注點分離」上的理念轉變——從「語言的分離」 (HTML/CSS/JS) 轉向了「元件的分離」。它透過一種看似「原始」的方式，解決了現代 Web 開發中的許多實際痛點，為開發者提供了一條通往高效、一致和高效能 UI 的捷徑。

端對端（End-to-End，E2E）測試是保障應用程式品質的最後一道防線。它透過模擬真實使用者操作（點擊、輸入、導覽），驗證整個應用程式流程是否順暢。然而，E2E 測試也以「脆弱」和「不穩定」聞名：

• 非同步問題：指令碼執行時，DOM 元素可能尚未載入完成，導致測試失敗。開發者需要手動加入大量 wait 或 sleep，讓測試變得不可靠。
• 跨瀏覽器相容性：確保測試能在所有主流瀏覽器（Chrome、Firefox、Safari）上穩定執行，是一項巨大挑戰。
• 偵錯困難：當測試在 CI/CD 環境中失敗時，重現和定位問題非常困難，也缺少現場快照與網路日誌。

為了解決這些問題，新一代測試工具應運而生，而 Playwright 正是其中的佼佼者。

2. Playwright 是什麼？

Playwright 是由微軟開發的 Node.js 函式庫，用於自動化 Chromium（Chrome、Edge）、Firefox 和 WebKit（Safari）瀏覽器。它由最初開發 Google Puppeteer 的團隊核心成員建立，可視為 Puppeteer 的精神繼承者，但設計更加現代且強大。

3. Playwright 的核心優勢

a. 真正的跨瀏覽器測試

這是 Playwright 最顯著的優勢。使用一套統一的 API，就能撰寫可在三個主流瀏覽器引擎上執行的測試。這代表你能輕鬆發現並修正只在特定瀏覽器（例如 Safari）出現的 Bug。

b. 自動等待（Auto-Waits）

Playwright 從根本上解決了非同步問題。在執行一項操作（例如 page.click()）之前，Playwright 會自動進行一系列可操作性檢查，例如：

• 等待元素出現在 DOM 中。
• 等待元素變得可見。
• 等待元素不再被動畫遮擋。
• 等待元素接收事件。

這代表你幾乎不再需要撰寫任何手動等待程式碼，測試穩定性也獲得大幅提升。

c. 強大的配套工具

• Codegen（程式碼產生器）：這是一項革命性的功能。你可以執行 pnpm exec playwright codegen example.com，Playwright 會開啟瀏覽器視窗。你在瀏覽器中的所有操作都會被自動錄製並轉換成測試程式碼，大幅降低撰寫 E2E 測試的門檻。

• Trace Viewer（軌跡檢視器）：這是 Playwright 的「時光機」。測試失敗時，你可以產生完整的測試軌跡檔案。用 Trace Viewer 開啟後，可以：

  • 檢視測試每一步的 DOM 快照。
  • 檢視完整的網路請求日誌。
  • 檢視 console 日誌和錯誤資訊。
  • 在時間軸上來回移動，直觀地看到頁面在每項操作前後的變化。

這使得偵錯 CI 中的失敗案例變得前所未有地簡單。

4. 一個簡單的測試範例

Playwright 的 API 設計非常直觀。

import { test, expect } from '@playwright/test';

test('页面应有正确的标题', async ({ page }) => {
  await page.goto('https://playwright.dev/');

  // 断言页面的 title 包含 "Playwright"
  await expect(page).toHaveTitle(/Playwright/);
});

test('点击 "Get started" 链接应跳转到介绍页', async ({ page }) => {
  await page.goto('https://playwright.dev/');

  // 通过角色和名称定位并点击链接
  await page.getByRole('link', { name: 'Get started' }).click();

  // 断言 URL 包含 "intro"
  await expect(page).toHaveURL(/.*intro/);
});

結論

Playwright 憑藉出色的跨瀏覽器支援、可靠的自動等待機制和無與倫比的偵錯工具（尤其是 Trace Viewer），為現代 Web 應用程式的 E2E 測試建立了新標準。它不僅提升了測試的穩定性與可靠性，也透過 Codegen 等工具大幅改善開發者撰寫測試的體驗。如果你正在為專案尋找現代且強大的自動化測試方案，Playwright 絕對是首選之一。

前端開發的本質是「將狀態映射為 UI」。多年來，我們見證了響應式模型的不斷演進：從手動 DOM 操作，到 MVC/MVVM 模式，再到由 React 推廣的虛擬 DOM（Virtual DOM）。VDOM 透過在元件層級進行狀態變更的批次處理和 Diffing，極大地簡化了 UI 開發。

然而，VDOM 並非銀彈。其元件層級的重新渲染和 Diffing 開銷，在某些高度動態的情境下會成為效能瓶頸。近年來，一種更古老但經過現代編譯器最佳化的範式——細粒度響應式（Fine-Grained Reactivity）——重新回到舞臺中央，而其核心載體正是 Signals。

2. 什麼是 Signals？

Signal 是一種響應式原語（Reactive Primitive），它封裝了一個值，並能在該值變化時自動通知其所有相依項目。與 VDOM 框架在元件層級追蹤變化不同，Signal 在資料讀取的層面自動建立相依關係圖。

當一個 Signal 的值被更新時，只有直接或間接相依於該 Signal 的計算（Memo）或副作用（Effect）會被重新執行，從而實現「外科手術式」的精確 DOM 更新，完全繞過了 VDOM Diffing 的需要。

其核心通常由三個原語構成：

• createSignal(value): 建立一個響應式的 state 單元。
• createEffect(() => {}): 建立一個自動追蹤相依關係並響應變更的副作用。
• createMemo(() => {}): 建立一個衍生的、帶快取的響應式計算。

// SolidJS 语法示例
const [count, setCount] = createSignal(0);

const doubleCount = createMemo(() => count() * 2);

createEffect(() => {
  console.log(`The double count is: ${doubleCount()}`);
});

setCount(1); // 这将触发 memo 重新计算，并触发 effect 重新执行

一個關鍵的心智模型是：在基於 Signal 的框架（如 SolidJS）中，元件函式本身只在初始化時執行一次。後續的更新完全由響應式系統驅動，而不是透過元件的重新渲染。

3. 生態系統的廣泛採用

Signal 並非全新概念，其思想可以追溯到 Knockout.js 等早期框架。但藉助現代 JavaScript 編譯器，它煥發了新的生機，並被各大框架廣泛採用：

• SolidJS & Qwik: 完全基於 Signal 建構，是該範式的標竿實作。
• Preact: 透過 @preact/signals 套件引入了官方支援，並可以與現有的 Preact/React 專案整合。
• Vue: 其 Composition API 中的 ref 和 computed 本質上就是 Signal 的一種實作。
• Svelte 5: 即將到來的「Runes」更新，是 Svelte 團隊對響應式模型的一次重構，其核心正是借鑑並實作了 Signal 範式。
• Angular: 近期版本中也引入了 Signals 作為新的響應式原語。

這種跨框架的趨同，證明了 Signal 作為一種高效、可預測的響應式模型的價值。

4. 優勢與權衡

優勢：

1. 卓越的效能: 透過避免 VDOM 和元件層級的重新渲染，在效能基準測試中通常表現優異。
2. 可預測性: 狀態更新的流向清晰，易於理解和除錯。
3. 記憶體占用小: 無需維護整個元件樹的虛擬表示。

權衡：

1. 心智模型轉變: 對於習慣了 React 渲染週期的開發者來說，需要適應「元件只執行一次」的新模型。
2. 生態整合: 雖然自身效能強大，但與龐大的 React VDOM 生態（例如，某些 UI 函式庫）的深度整合可能需要額外的適配工作。

結論

Signals 的復興標誌著前端狀態管理範式的一次重要演進。它將開發者的注意力從「元件如何渲染」拉回到了「狀態如何流動」這一更本質的問題上。透過與編譯器的深度結合，Signal 在提供優秀開發體驗的同時，也為 Web 應用程式的效能邊界帶來了新的可能性。

在傳統的前後端分離開發中，API 就是兩者之間的「契約」。我們通常透過以下方式維護這份契約：

• RESTful API：依賴 OpenAPI（Swagger）等工具產生並維護詳盡的 API 文件。
• GraphQL：依賴嚴格的 Schema Definition Language（SDL）定義資料結構與操作。

這些方案確實有效，但都存在一項共同問題：契約與實作彼此分離。當前端開發者呼叫 API 時，他相信該 API 會回傳文件或 schema 中描述的資料結構。但如果後端實作發生變更（例如修改欄位名稱），文件或 schema 卻未能及時更新，這種不一致只會在執行階段才暴露，進而造成 Bug。

有沒有一種方法，能讓這份「契約」自動與實作保持同步，甚至在編譯時便發現不一致？

2. tRPC 的核心思想：共享型別，而非 schema

tRPC（TypeScript Remote Procedure Call）提出一項激進但極其簡單的方案：如果前端與後端都使用 TypeScript，為什麼不直接共享型別？

tRPC 讓你能將純 TypeScript 函式撰寫成後端 API，接著直接在前端呼叫，並享有完整的型別推斷與自動完成，就像呼叫本機模組中的函式一樣。

它不依賴任何 schema 或程式碼產生。唯一的「契約」就是 TypeScript 型別本身。

3. 它如何運作？

tRPC 的魔法來自型別推斷，以及一點巧妙的封裝。

a. 後端：定義 API Router

在後端（通常是 Node.js 服務），你使用 tRPC 函式建立一個或多個「Router」。每個 Router 都是一組可供呼叫的「Procedure」，也就是 API 端點。

// server/router.ts
import { initTRPC } from '@trpc/server';
import { z } from 'zod'; // 使用 Zod 进行运行时校验

const t = initTRPC.create();

export const appRouter = t.router({
  // 定义一个名为 `getUser` 的查询 procedure
  getUser: t.procedure
    .input(z.object({ userId: z.string() }))
    .query(({ input }) => {
      // 在这里查询数据库或执行其他逻辑
      const user = { id: input.userId, name: 'Alex' };
      return user;
    }),

  // 定义一个名为 `createUser` 的变更 procedure
  createUser: t.procedure
    .input(z.object({ name: z.string() }))
    .mutation(({ input }) => {
      const user = { id: `${Math.random()}`, name: input.name };
      return user;
    }),
});

// 导出 router 的类型定义
export type AppRouter = typeof appRouter;

b. 前端：建立用戶端並呼叫 API

在前端，你只需要從後端匯入 AppRouter 這個型別。請注意，匯入的只有型別，而不是任何伺服器端程式碼。

// client/trpc.ts
import { createTRPCReact } from '@trpc/react-query';
import type { AppRouter } from '../server/router'; // 只导入类型

export const trpc = createTRPCReact<AppRouter>();

現在，你可以在 React 元件中像呼叫本機函式一樣呼叫 API，並獲得完整的型別安全與自動完成！

// client/components/UserInfo.tsx
import { trpc } from '../trpc';

function UserInfo({ userId }: { userId: string }) {
  // `useQuery` 的第一个参数是 procedure 的路径
  // 你输入 `trpc.` 时，IDE 会自动提示 `getUser` 和 `createUser`
  const userQuery = trpc.getUser.useQuery({ userId });

  if (userQuery.isLoading) {
    return <div>Loading...</div>;
  }

  // `userQuery.data` 的类型被自动推断为 { id: string; name: string }
  return <div>User: {userQuery.data?.name}</div>;
}

如果此時後端開發者將 getUser 回傳的 name 欄位重新命名為 fullName，前端的 userQuery.data?.name 會立即在 TypeScript 編譯時報錯，而不是等到執行階段才被發現。

4. 為什麼選擇 tRPC？

• 絕對的端對端型別安全：這是它的核心價值，能消除因 API 契約不一致而產生的一整類 Bug。
• 卓越的開發體驗：IDE 自動完成功能讓你不必查閱文件或猜測 API 結構。重構也變得異常輕鬆且安全。
• 不需產生程式碼：沒有額外的建置步驟，回饋循環非常快速。
• 輕量且靈活：tRPC 本身非常小，並可與任何前端框架及後端服務整合。

結論

tRPC 為全端 TypeScript 開發帶來前所未有的流暢體驗。透過消除對 API 文件與 schema 的依賴，它讓前端和後端之間的協作變得無縫且極其安全。在 Monorepo 架構下，這些優勢會進一步放大。如果你正在建構全端 TypeScript 應用程式，tRPC 絕對是一項值得投入時間嘗試的革命性工具。

React、Vue、Svelte 等現代前端框架大幅提升了建構複雜 Web 應用程式的開發體驗。但當我們將它們用於建構部落格、作品集、文件或行銷網站時，一個問題也隨之而來：這些以內容呈現為主的網站，真的需要將整個頁面作為單頁應用程式（SPA）來載入嗎？

答案通常是「否」。對於這類網站，使用者的核心需求是快速取得內容，過多的 JavaScript 反而會拖慢頁面的可互動時間（TTI），影響使用者體驗和 SEO。

Astro 正是為了解決這個問題而誕生的。

2. Astro 的核心理念：內容優先，預設零 JS

Astro 是一個現代化的靜態網站產生器（SSG），它的核心理念是內容優先。它旨在盡可能將更多工作放在建置時完成，向瀏覽器傳送盡可能少的 JavaScript。

為了實現這一點，Astro 提出了兩大創新：

• 預設零 JavaScript（Zero-JS by Default）：Astro 會將你的所有 UI 元件（無論使用 React、Vue 還是 Svelte 編寫）在建置時算繪成純粹的 HTML。如此一來，瀏覽器收到的就是靜態頁面，無須載入任何框架的 JS 執行環境，載入速度極快。
• 島嶼架構（Islands Architecture）：這是 Astro 的精髓所在。在一個由靜態 HTML 構成的「海洋」中，任何需要用戶端互動的元件都可以被標記為一座「島嶼」。Astro 會獨立為這些島嶼打包並載入所需的 JavaScript，而頁面的其餘部分則保持純靜態。

3. 「島嶼」是如何運作的？

在 Astro 中，你可以透過加入 client:* 指令，將一個元件標記為互動式島嶼。

例如，我們有一個用 React 編寫的計數器元件 Counter.jsx。在 Astro 頁面中可以這樣使用它：

---
// src/pages/index.astro
import Counter from '../components/Counter.jsx';
---
<html>
  <body>
    <h1>Astro 示例</h1>
    <p>这是一个静态的段落，它不会加载任何 JS。</p>

    {/* 这个组件是一个交互式岛屿 */}
    <Counter client:load />

    <p>这是另一个静态段落。</p>
  </body>
</html>

client:load 指令告訴 Astro：

1. 在伺服器端算繪 Counter 元件的初始 HTML。
2. 為 Counter 元件建立一個獨立的 JS 套件。
3. 在頁面載入時，自動載入這個 JS 套件並「啟用」（hydrate）該元件，使其具備互動性。

Astro 還提供了更精細的載入指令，例如 client:idle（瀏覽器閒置時載入）和 client:visible（元件進入視窗時載入），讓效能最佳化更進一步。

4. 框架無關性

Astro 的另一大魅力在於它對 UI 框架的包容性。你可以在同一個 Astro 專案中，同時使用來自 React、Vue、Svelte、SolidJS、Lit 等不同框架的元件。這為團隊協作和技術選型提供了極大的彈性。

結論

Astro 並非要取代 React 或 Vue，而是為特定情境提供了更好的解法。如果你的專案是一個以內容為核心、對效能和 SEO 有極高要求的網站（例如這個部落格本身就是使用 Astro 建構的！），那麼 Astro 無疑是一個值得深入探索的絕佳選擇。它將靜態網站的效能優勢與現代框架的開發體驗完美地結合在一起。

2022 年 12 月，Svelte 團隊正式宣布 SvelteKit 1.0 版本發布。對於 Svelte 社群乃至整個前端領域來說，這都是一個里程碑式的事件。SvelteKit 不再僅僅是一個「Svelte 版的 Next.js 或 Nuxt.js」，它帶著自己獨特的設計哲學，旨在提供一種更簡單、更靈活、效能更高的 Web 應用程式建構方式。

什麼是 SvelteKit？

如果你熟悉 Svelte，你可能知道 Svelte 本身是一個元件框架。它透過一個激進的編譯器，在建置時將你的 .svelte 檔案轉換為高效的命令式 JavaScript 程式碼，從而實現了驚人的效能和極小的執行期開銷。

而 SvelteKit 則是建立在 Svelte 之上的應用程式框架。它為你處理了建構一個完整應用程式所需的一切：路由、伺服器端渲染（SSR）、資料載入、部署適配等等，讓你能專注於業務邏輯的開發。

核心特性一覽

1. 檔案系統路由（Filesystem-based Routing）

和 Next.js 類似，SvelteKit 的路由是基於你的檔案系統結構自動產生的。src/routes 目錄下的檔案結構直接映射為應用程式的 URL。

• src/routes/+page.svelte -> /
• src/routes/about/+page.svelte -> /about
• src/routes/blog/[slug]/+page.svelte -> /blog/some-post

這種慣例優於設定的方式極大地簡化了路由管理。

2. 靈活的渲染模式

SvelteKit 讓你可以在頁面層級精確控制渲染方式。無論是伺服器端渲染（SSR）、靜態網站產生（SSG），還是兩者的混合，都可以在同一個應用程式中實現。你甚至可以為單個頁面關閉 SSR，將其變為一個純粹的客戶端單頁應用程式（SPA）。

3. 通用的 load 函式

SvelteKit 統一了資料載入的模式。在每個頁面（或版面配置）的同層目錄下，你可以建立一個 +page.js 或 +page.server.js 檔案，並匯出一個 load 函式。

• +page.js 中的 load 函式同時在伺服器端和客戶端執行。
• +page.server.js 中的 load 函式僅在伺服器端執行，你可以在這裡安全地存取資料庫或私人 API。

load 函式回傳的資料會自動傳遞給對應的 +page.svelte 元件。

// src/routes/blog/[slug]/+page.server.js
import * as db from '$lib/server/database';

export async function load({ params }) {
  const post = await db.getPost(params.slug);
  return { post };
}

4. 適配器（Adapters）

「一次撰寫，隨處部署」是 SvelteKit 的核心承諾之一。透過適配器，SvelteKit 可以將你的應用程式打包成適用於任何目標平台的格式。

• @sveltejs/adapter-node: 用於部署到傳統的 Node.js 伺服器。
• @sveltejs/adapter-vercel: 適配 Vercel 平台。
• @sveltejs/adapter-static: 將整個應用程式預先渲染為靜態檔案，適用於任何靜態主機。
• 還有更多適用於 Netlify、Cloudflare Workers 等平台的官方和社群適配器。

結論

SvelteKit 1.0 的發布，標誌著 Svelte 生態的成熟。它將 Svelte 編譯器的極致效能與一個經過深思熟慮的應用程式框架相結合，為開發者提供了一個強大而愉悅的開發體驗。如果你正在尋找一個能夠建構從簡單靜態頁面到複雜動態應用程式的全能型框架，SvelteKit 絕對值得一試。

「如何優雅地管理狀態？」這是每一個 React 開發者在專案成長過程中都必須面對的核心問題。從簡單的元件內部狀態，到複雜的跨元件全域狀態，React 社群探索出了多種解決方案。這些方案的演進，也反映了我們對元件化開發理解的不斷深化。

階段一：樸素的時代 —— useState 與屬性鑽探（Props Drilling）

在最開始，我們只有 useState（或類別元件的 this.state）。當一個狀態需要被多個元件共享時，React 的官方建議是 「狀態提升」（Lifting State Up）。我們將狀態提升到這些元件的最近公共父元件中，再透過 props 將狀態和更新函式傳遞下去。

當元件層級很深時，這種模式就導致了 「屬性鑽探」（Props Drilling）：一些中間層的元件僅僅是為了將 props 傳遞給更深層的子元件，自身完全用不到這些 props。這使得元件的耦合度增高，重構和維護變得困難。

階段二：官方的答案 —— Context API

為了解決「屬性鑽探」的問題，React 官方提供了 Context API。它允許我們建立一個「上下文」，並在元件樹的頂層提供（Provide）一個值，然後在任何深度的子元件中都可以直接取用（Consume）這個值，無需手動逐層傳遞。

// 1. 创建 Context
const ThemeContext = React.createContext('light');

// 2. 在顶层提供值
<ThemeContext.Provider value="dark">
  <App />
</ThemeContext.Provider>

// 3. 在子组件中消费
const theme = useContext(ThemeContext); // 'dark'

然而，Context API 也有其「陷阱」：效能問題。只要 Provider 的 value 發生變化，所有取用該 Context 的元件都會重新渲染，即使它關心的只是 value 物件中的一小部分。這使得 Context API 不適合管理頻繁變化的、複雜的全域狀態。

階段三：大一統時代 —— Redux

在 Context API 尚不成熟的年代，Redux 橫空出世，迅速成為大型複雜應用程式狀態管理的實際標準。它借鑑了 Flux 架構和函數式程式設計思想，帶來了：

• 單一資料來源（Single Source of Truth）: 整個應用程式的 state 被儲存在一個單一的 store 中。
• State 是唯讀的: 唯一改變 state 的方法就是 dispatch 一個 action。
• 使用純函式來執行修改: Reducer 接收先前的 state 和 action，並回傳新的 state。

Redux 憑藉其可預測性、強大的除錯工具（時間旅行）和豐富的中介軟體生態，解決了大型應用程式中的狀態管理難題。但它的缺點也同樣明顯：繁瑣的樣板程式碼（Boilerplate）。為了實作一個簡單的功能，開發者需要撰寫 Actions、Reducers、Dispatchers，心智負擔較重。

階段四：文藝復興 —— 輕量級、Hooks-First 的方案

隨著 React Hooks 的普及，以及對 Redux 複雜性的反思，社群開始湧現出一批新的、更輕量的狀態管理函式庫。它們的共同特點是 API 簡潔、心智模型簡單，並且充分利用了 Hooks 的能力。

Zustand 是其中的傑出代表。它提供了一個極其簡單的 create 函式來建立 store，並且：

• 無需 Provider: Store 存在於 React 元件樹之外，可以在任何地方匯入使用。
• API 極簡: 透過一個 Hook 即可存取和更新狀態。
• 選擇性訂閱，效能更優: 元件可以只訂閱它關心的那一部分 state，避免了 Context API 的效能問題。

const useStore = create(set => ({
  count: 0,
  inc: () => set(state => ({ count: state.count + 1 })),
}));

function Counter() {
  // 只订阅 count 的变化
  const count = useStore(state => state.count);
  return <h1>{count}</h1>;
}

結論：沒有銀彈，按需選擇

React 狀態管理的演進史告訴我們，沒有一勞永逸的「最佳方案」，只有「最適合當前情境」的方案。

• useState: 永遠是元件區域狀態的首選。
• Context API: 適合管理那些不經常變化的全域資料，如主題、使用者驗證資訊等。
• Zustand / Jotai: 對於大多數需要客戶端全域狀態的應用程式來說，它們在效能和開發體驗之間取得了絕佳的平衡。
• Redux（Redux Toolkit）: 對於需要嚴格資料流規範、複雜中介軟體和強大除錯能力的超大型應用程式，它依然是可靠的選擇。

Webpack 是一個極其強大且可設定的模組打包工具，多年來一直是前端專案的基石。但隨著專案規模增長，其以「打包」為核心的思路也帶來了效能瓶頸：

• 緩慢的冷啟動：每次啟動開發伺服器（dev-server），Webpack 都需要遍歷整個相依性圖，將所有模組打包到記憶體中。這個過程在大型專案中可能花費數分鐘。
• 緩慢的熱更新（HMR）：當你修改一個檔案時，Webpack 需要重新計算相關模組並進行替換。雖然比整個頁面重新整理更快，但在大型專案中，這個過程的延遲也可能達到數秒甚至十幾秒，打斷開發心流。

2. Vite 如何解決這些問題？

Vite（法語意為「快」）另闢蹊徑。它利用現代瀏覽器對原生 ES 模組（ESM）的支援，將建置過程分成兩部分：

• 開發時：Vite 啟動一個伺服器，但不會預先打包所有模組。相反地，它會攔截瀏覽器的模組請求，按需轉換並提供原始碼。例如，瀏覽器請求 main.js，Vite 提供它；main.js 匯入了 Button.vue，瀏覽器再次發起請求，Vite 再提供轉換後的 Button.vue。這使開發伺服器幾乎能瞬間啟動。
• 正式環境：Vite 使用 Rollup（同樣高效的打包工具）進行打包，以獲得高度最佳化的靜態資源。

這種模式徹底改變了開發體驗，帶來閃電般的啟動速度和毫秒級熱更新。

3. 遷移實作步驟

將一個現有 Webpack 專案遷移到 Vite，通常涉及以下步驟：

a. 安裝相依套件並建立設定檔

首先，安裝 Vite：

pnpm add -D vite @vitejs/plugin-react # 或 @vitejs/plugin-vue

然後在專案根目錄建立 vite.config.js：

import react from '@vitejs/plugin-react'
import { defineConfig } from 'vite'

export default defineConfig({
  plugins: [react()],
})

b. 移動 index.html

Webpack 通常將 index.html 放在 public 目錄下，並自動注入打包後的 JS。Vite 則將 index.html 視為應用程式的進入點。你需要將它移到專案根目錄，並手動加入指令碼參照：

<body>
  <div id="root"></div>
  <script type="module" src="/src/main.jsx"></script>
</body>

c. 替換 Webpack 外掛

你需要找到 Webpack Loaders 和 Plugins 所對應的 Vite 外掛。社群生態非常豐富，大部分需求都能找到解決方案。

d. 處理環境變數

在 Webpack 中，我們習慣使用 process.env.NODE_ENV。在 Vite 中，需要透過 import.meta.env 來存取環境變數，例如 import.meta.env.VITE_API_URL。

e. 設定路徑別名

在 vite.config.js 中設定路徑別名非常簡單：

import path from 'node:path'
// vite.config.js
import { defineConfig } from 'vite'

export default defineConfig({
  // ...
  resolve: {
    alias: {
      '@': path.resolve(__dirname, './src'),
    },
  },
})

4. 遷移後的成果

遷移到 Vite 後，最直觀的感受就是快。

• 開發伺服器啟動時間從 50 秒縮短到 2 秒。
• 熱更新時間從平均 3–5 秒降低到幾乎無感的數十毫秒。
• 設定檔（vite.config.js）相比 webpack.config.js 大幅簡化。

結論

雖然遷移過程可能需要處理一些專案特有的設定問題，但從 Webpack 遷移到 Vite 所帶來的開發體驗提升非常巨大。如果你還在忍受緩慢的建置過程，那麼現在就是擁抱 Vite 的最佳時機。

CSS-in-JS 方案，如 styled-components 和 Emotion，透過允許開發者在 JavaScript/TypeScript 檔案中編寫 CSS，徹底改變了元件化開發的樣式管理方式。它帶來了許多好處：

• 元件作用域: 樣式預設與元件綁定，解決了 CSS 全域命名衝突的問題。
• 動態樣式: 可以基於元件的 props 或 state 輕鬆建立動態樣式。
• 程式碼共存: 樣式和元件邏輯放在同一個檔案中，便於維護和組織。

然而，這些便利性並非沒有代價。傳統 CSS-in-JS 函式庫的核心是 執行階段 (Runtime)。當元件在瀏覽器中掛載時，CSS-in-JS 函式庫的 JavaScript 執行階段會：

1. 解析範本字串或物件中的 CSS。
2. 產生唯一的類別名稱。
3. 將樣式動態地注入到文件的 <head> 中的 <style> 標籤裡。

這個過程會增加 JavaScript 的套件體積，並在應用程式啟動和渲染時帶來一定的計算開銷，影響效能。

2. 「零執行階段」的破局之道

為了解決執行階段效能問題，社群提出了一種新的思路：零執行階段 (Zero-Runtime) CSS-in-JS。

其核心思想是：保留 CSS-in-JS 的開發體驗，但在 建置時 (build time) 就完成所有工作。建置工具（通常是一個 Babel 外掛程式或 Vite 外掛程式）會掃描你的程式碼，找到所有 CSS-in-JS 的用法，然後：

1. 將 CSS 文字提取出來。
2. 產生靜態的 .css 檔案。
3. 將原始的 CSS-in-JS 程式碼替換為產生的、唯一的類別名稱。

最終，交付給瀏覽器的 JavaScript 套件中 不包含任何 CSS-in-JS 的執行階段函式庫，其效果等同於手寫的高度最佳化的靜態 CSS 檔案。

3. 主流零執行階段方案

a. Linaria

Linaria 是零執行階段領域的先驅之一。它允許你使用熟悉的 styled 標籤範本字串語法。

// YourComponent.js
import { styled } from '@linaria/react';

const Title = styled.h1`
  font-size: 2rem;
  color: tomato;
`;

// 构建时，这会被转换为：
// <h1 class="Title_a1b2c3d">...</h1>
//
// 并在一个静态 .css 文件中生成：
// .Title_a1b2c3d {
//   font-size: 2rem;
//   color: tomato;
// }

b. vanilla-extract

由 SEEK 公司團隊開發的 vanilla-extract 更進一步，它利用 TypeScript 來創造完全型別安全的樣式。所有樣式定義都是 .css.ts 檔案中的匯出變數，提供了強大的型別推斷和自動補全。

// styles.css.ts
import { style } from '@vanilla-extract/css';

export const title = style({
  fontSize: '2rem',
  color: 'tomato',
});

c. Panda CSS

Panda CSS 是一個較新的競爭者，它借鑑了 Tailwind CSS 的思想，提供了一種「樣式屬性」 (Style Props) 的開發體驗，同時保證了零執行階段的輸出。

import { css } from '../styled-system/css';

function MyComponent() {
  return <div className={css({ fontSize: '2rem', color: 'tomato' })} />;
}

4. 優勢與權衡

優勢:

• 極致效能: 最終產物是靜態 CSS，沒有 JavaScript 執行階段開銷。
• 更小的套件體積: 無需在客戶端載入 CSS-in-JS 函式庫。
• 強大的開發體驗: 依然享受元件作用域、TypeScript 型別安全和程式碼共存的好處。

權衡:

• 建置時相依性: 必須整合到建置流程中，設定相對複雜一些。
• 動態性受限: 無法根據純執行階段的值（例如，來自 API 的資料）來產生全新的樣式。不過，可以透過 CSS 變數等技術來彌補大部分動態場景。

結論

零執行階段 CSS-in-JS 是對傳統 CSS-in-JS 典範的一次「撥亂反正」。它巧妙地分離了「開發時體驗」和「執行階段效能」，讓我們不再需要在兩者之間做出艱難的妥協。對於追求極致效能和更小打包體積的現代 Web 應用程式來說，它提供了一個近乎完美的解決方案。

隨著 TC39 委員會的年度發布流程，JavaScript 語言每年都在不斷演進。ECMAScript 2022 (ES2022) 帶來了一系列旨在提升開發者體驗和程式碼可讀性的新功能。讓我們一起看看其中最亮眼的幾個特性。

1. Top-Level await

這是 ES2022 中最受期待的特性之一。在此之前，await 關鍵字只能在 async 函式內部使用。這在模組的頂層作用域中處理非同步操作時非常不便，我們通常需要藉助 IIFE（立即呼叫函式運算式）來包裹非同步程式碼。

之前 👎:

// data.js
import { fetchData } from './api.js';

let data;
(async () => {
  data = await fetchData();
  // ... 只能在这里使用 data
})();

export { data }; // 导出时 data 还是 undefined

現在 (ES2022) 👍:

// data.js
import { fetchData } from './api.js';

const data = await fetchData();

export { data }; // 模块会等待 await 完成后再被其他模块评估

Top-level await 極大地簡化了模組的動態載入、相依性初始化等場景，讓非同步程式碼寫起來更符合直覺。

2. .at() 陣列／字串索引方法

在 JavaScript 中，取得陣列的最後一個元素通常需要寫 arr[arr.length - 1]，這既冗長又容易出錯。ES2022 引入了 .at() 方法，統一了正向和反向索引的體驗。

.at() 方法接收一個整數，如果是正數，則回傳對應索引的元素；如果是負數，則從末尾開始倒數。

之前 👎:

const arr = [1, 2, 3, 4, 5];
const lastElement = arr[arr.length - 1]; // 5
const secondToLast = arr[arr.length - 2]; // 4

現在 (ES2022) 👍:

const arr = [1, 2, 3, 4, 5];
const lastElement = arr.at(-1); // 5
const secondToLast = arr.at(-2); // 4

// 同样适用于字符串
const str = 'hello';
console.log(str.at(-1)); // 'o'

3. Object.hasOwn(obj, prop)

檢查一個物件是否擁有某個自有屬性（而不是繼承來的屬性），我們通常使用 Object.prototype.hasOwnProperty.call(obj, prop)。這種寫法非常繁瑣，且在某些情況下（如 Object.create(null) 建立的物件）會出錯。

Object.hasOwn() 提供了一個更短、更可靠的靜態方法。

之前 👎:

const obj = { a: 1 };
console.log(Object.prototype.hasOwnProperty.call(obj, 'a')); // true
console.log(Object.prototype.hasOwnProperty.call(obj, 'toString')); // false

現在 (ES2022) 👍:

const obj = { a: 1 };
console.log(Object.hasOwn(obj, 'a')); // true
console.log(Object.hasOwn(obj, 'toString')); // false

4. 其他值得關注的特性

• Error Cause: Error 建構函式現在可以接收第二個參數，用於指定錯誤的「原因」，方便建構更清楚的錯誤鏈。

  try {
    // ...
  } catch (err) {
    throw new Error('New error message', { cause: err });
  }
  

• RegExp Match Indices (/d flag): 當使用 /d 旗標時，規則運算式的比對結果會額外提供每個擷取群組的起始和結束索引。

結論

ES2022 的新特性雖然沒有帶來顛覆性的變革，但它們在細節上打磨了 JavaScript，解決了許多開發者長期以來的痛點，讓程式碼變得更簡潔、更健壯。

Redux 毫無疑問是 React 生態中最著名、最強大的狀態管理函式庫。它的單向資料流、時間旅行除錯等特性使其成為大型、複雜應用程式的可靠選擇。但對於許多中小型專案，Redux 的「樣板程式碼」（Boilerplate）卻常常令人頭疼：

• Actions & Action Creators: 定義大量的 action 類型和建立函式。
• Reducers: 撰寫龐大的 switch 陳述式來處理不同的 action。
• Dispatch & Selectors: 在元件中透過 dispatch 派發 action，透過 useSelector 訂閱狀態變化。
• Context Provider: 需要在應用程式的根部包覆一個 <Provider>。

這一切使得新增一個簡單的狀態也需要修改多個檔案，流程繁瑣。

2. Zustand：一股清流

Zustand（德語意為「狀態」）是由 Poimandres（react-three-fiber 的作者）團隊開發的一個輕量級狀態管理函式庫。它的設計哲學就是極簡和非侵入式。

核心特點：

• 程式碼量極少: 實作一個功能，Zustand 的程式碼量通常只有 Redux 的一小部分。
• 基於 Hooks: 它的一切都圍繞一個自訂 Hook 展開，符合現代 React 的開發習慣。
• 無需 Context Provider: 你不需要在應用程式頂層包覆任何 Provider。Store 獨立於元件樹，可以在任何地方匯入和使用。
• 上手快: API 極其簡單，幾分鐘就能學會核心用法。

3. 核心用法

Zustand 的使用分為兩步：建立 Store 和在元件中使用。

a. 建立 Store

你可以將 store 定義在任何一個 .js 或 .ts 檔案中。

// src/store.js
import { create } from 'zustand';

const useBearStore = create((set) => ({
  bears: 0,
  increasePopulation: () => set((state) => ({ bears: state.bears + 1 })),
  removeAllBears: () => set({ bears: 0 }),
}));

export default useBearStore;

create 函式接收一個回呼，該回呼的參數是 set 函式（類似於 React 的 setState）。你在這裡定義你的狀態和更新狀態的方法。

b. 在元件中使用

在任何元件中，像使用普通 Hook 一樣使用它。

// src/components/BearCounter.jsx
import useBearStore from '../store';

function BearCounter() {
  const bears = useBearStore((state) => state.bears);
  return <h1>{bears} around here ...</h1>;
}

注意，我們透過一個選擇器函式 (state) => state.bears 來訂閱 bears 狀態。這很重要，因為它能確保只有在 bears 狀態變化時，該元件才會重新渲染，避免了不必要的效能開銷。

// src/components/Controls.jsx
import useBearStore from '../store';

function Controls() {
  const increasePopulation = useBearStore((state) => state.increasePopulation);
  return <button onClick={increasePopulation}>one up</button>;
}

取得 action 也同樣簡單。

4. 非同步 Action

Zustand 處理非同步操作也非常自然，你不需要任何像 redux-thunk 或 redux-saga 這樣的中介軟體。

const useAsyncStore = create((set) => ({
  data: null,
  fetchData: async (url) => {
    const response = await fetch(url);
    const data = await response.json();
    set({ data });
  },
}));

結論

Zustand 並非要完全取代 Redux。Redux 在嚴格的規範、可追溯性和龐大的生態系統方面仍然具有優勢。

然而，對於絕大多數 React 應用程式來說，Zustand 提供了一個更簡單、更快速、心智負擔更低的選擇。如果你厭倦了 Redux 的繁文縟節，或者你的下一個專案需要一個輕快、靈活的狀態管理器，那麼 Zustand 絕對是一個值得你嘗試的優秀方案。

Monorepo（單一程式碼儲存庫）是一種將多個獨立專案或套件（package）存放在同一個程式碼儲存庫中的策略。與每個專案擁有獨立儲存庫的 Polyrepo 模式相比，Monorepo 具有一些顯著優勢：

• 程式碼共享：在不同專案間共享元件、工具函式或型別定義變得非常容易。
• 原子化提交：一個功能的修改如果涉及多個套件，可以透過一次提交完成，確保版本一致。
• 簡化相依性管理：所有專案共享同一個 node_modules（或透過 pnpm/yarn workspace 最佳化），減少相依性衝突和版本不一致的問題。

然而，當儲存庫規模變大時，Monorepo 的挑戰也隨之而來：建置效能。

2. Monorepo 的痛點

想像一下，你的儲存庫裡有 docs、webapp，以及一個共享的 ui 元件庫。當你只修改了 docs 中的一個錯字時，你最不希望發生的事情就是整個儲存庫的所有專案（包括 webapp 和 ui）都被重新建置和測試。

傳統的 Monorepo 管理工具（如 Lerna）在任務編排和建置快取方面有所不足，導致：

• 重複工作：每次 CI/CD 執行時，都會從頭建置和測試所有內容，即使大部分程式碼沒有變化。
• 建置時間長：無法有效利用多核心 CPU 平行執行任務。
• 複雜的指令碼：需要編寫複雜的 package.json 指令碼，手動控制任務的執行順序。

3. Turborepo：為速度而生

Turborepo 是一個專為 JavaScript/TypeScript Monorepo 設計的高效能建置系統（後被 Vercel 收購）。它透過兩大核心技術解決上述痛點：增量建置和遠端快取。

a. 增量建置與任務管線（Pipelines）

Turborepo 讓你在根目錄的 turbo.json 檔案中定義任務之間的相依關係。

// turbo.json
{
  "$schema": "https://turbo.build/schema.json",
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**", ".next/**"]
    },
    "test": {
      "dependsOn": ["build"],
      "outputs": []
    },
    "lint": {
      "outputs": []
    },
    "dev": {
      "cache": false
    }
  }
}

• dependsOn: ["^build"]：^ 符號表示，一個套件的 build 任務依賴於其所依賴的所有套件的 build 任務。Turborepo 會根據這個關係圖，以最高效的平行方式執行任務。
• outputs：告訴 Turborepo 這個任務會產生哪些輸出檔案。

當你執行 pnpm turbo build 時，Turborepo 會計算哪些檔案被修改，並且只重新建置受影響的套件。如果一個套件的原始碼和相依性沒有變化，Turborepo 會直接使用上次的建置產物，這個過程是瞬間完成的。

b. 遠端快取（Remote Caching）

這是 Turborepo 的「殺手級」功能。它不只在你的本機上快取建置結果，還能將這些快取上傳到共享的遠端伺服器（如 Vercel 或你自己的 S3 儲存貯體）。

這表示：

• 你的同事在取得最新程式碼後，如果他要建置的部分你已經建置過，他可以直接下載快取，無須在本機重新建置。
• CI/CD 伺服器也能連線到這個遠端快取。一個 PR 在 CI 中被建置並快取後，其他開發者或後續 CI 任務都能立即享用這項成果。

這能將整個團隊的建置時間從數十分鐘縮短到幾分鐘，甚至幾十秒。

結論

Turborepo 並沒有發明 Monorepo，但它透過引入先進的快取和任務排程系統，大幅最佳化了 Monorepo 的開發體驗，解決其最核心的效能瓶頸。如果你正在使用或準備採用 Monorepo 架構，Turborepo 絕對是一個能為你和團隊節省大量時間的利器。

自 React 推廣虛擬 DOM (Virtual DOM) 以來，VDOM 似乎成了現代前端框架的標準配備。它透過在記憶體中維護一個虛擬的 UI 表示，並透過 diff 演算法來計算最小化的 DOM 更新，從而提升了開發體驗和大多數場景下的效能。

但 VDOM 並非沒有代價。它本身需要佔用記憶體，diff 過程也需要計算成本。一個問題隨之而來：我們能否繞過 VDOM，直接將狀態變更精確地更新到 DOM 上，同時還保持宣告式的、類似 React 的開發體驗？

SolidJS 給出了它的答案。

2. SolidJS 的核心：細粒度響應式 (Fine-Grained Reactivity)

SolidJS 是一個宣告式的、響應式的 JavaScript 框架。它雖然使用 JSX，看起來和 React 非常相似，但其底層原理完全不同。

SolidJS 的編譯器會將你的 JSX 程式碼轉換為最佳的原生 DOM 操作。它不使用 VDOM，而是建立了一個由響應式「訊號」 (Signals) 組成的相依圖。當一個訊號的值發生變化時，只有訂閱了這個訊號的「效果」 (Effects) 或計算（Memos）會重新執行。

一個顛覆性的心智模型：元件只執行一次！

在 React 中，當 state 或 props 變化時，整個元件函式會重新執行。但在 SolidJS 中，你的元件函式 從頭到尾只會執行一次。

import { createSignal } from 'solid-js';

function Counter() {
  console.log('Component function runs!'); // 这句话只会在组件挂载时打印一次

  const [count, setCount] = createSignal(0);

  const increment = () => setCount(count() + 1);

  return (
    <button type="button" onClick={increment}>
      Count: {count()}
    </button>
  );
}

當你點擊按鈕時，只有 count() 這個訊號的讀取器和依賴它的 DOM 文字節點會更新。Counter 函式本身不會再次執行。這種「外科手術式」的更新是 SolidJS 極致效能的根源。

3. 核心 API

SolidJS 的響應式系統主要由三個核心原語構成：

• createSignal(initialValue): 建立一個響應式訊號，回傳一個 getter 和一個 setter。[count, setCount]
• createEffect(() => {}): 建立一個「效果」，它會自動追蹤其內部讀取的所有訊號，並在任何一個訊號變化時重新執行。非常適合用來執行副作用，如手動操作 DOM。
• createMemo(() => {}): 建立一個快取的、衍生的計算值。只有當其內部相依的訊號變化時，它才會重新計算。

import { createSignal, createEffect } from 'solid-js';

function App() {
  const [firstName, setFirstName] = createSignal('John');
  const [lastName, setLastName] = createSignal('Smith');

  // createEffect 会在 firstName 或 lastName 变化时自动运行
  createEffect(() => {
    console.log(`Full name: ${firstName()} ${lastName()}`);
  });

  // ...
}

4. 為什麼選擇 SolidJS？

• 極致的效能: 在各種獨立的效能測試中，SolidJS 常常名列前茅，其效能與原生 JavaScript 程式碼非常接近。
• 極小的套件體積: 由於沒有 VDOM 執行階段，其核心套件非常小。
• 熟悉的開發體驗: 如果你熟悉 React Hooks，你可以很快上手 SolidJS。JSX 和響應式原語的組合既強大又直覺。
• 真正的響應式: 它的模型更接近於 MobX 或 Vue 的 Composition API，但透過編譯器實現了零執行階段代價。

結論

SolidJS 代表了前端框架演進的一個重要方向：即透過編譯器在建置時做更多的工作，來實現更少的執行階段程式碼和更高的效能。它向我們證明了，在不犧牲宣告式開發體驗的前提下，完全可以擺脫虛擬 DOM 的束縛。對於追求極致效能的應用程式，SolidJS 提供了一個極具吸引力的選擇。

Fetch API 已經取代了老舊的 XMLHttpRequest，成為瀏覽器中發起 HTTP 請求的標準方式。它基於 Promise，提供了更簡潔、更強大的請求能力。

然而，Fetch API 預設並沒有提供一個直接取消請求的機制。在許多情境下，請求取消是一個非常重要的功能：

• 效能最佳化: 使用者快速切換頁面或輸入搜尋詞時，取消舊的、不再需要的請求可以節省頻寬和伺服器資源。
• 避免競態條件: 在「搜尋即時輸入」的情境中，如果舊的請求比新的請求回傳得慢，可能會導致 UI 顯示過時的資料。
• 防止記憶體洩漏: 在元件生命週期中發起的請求，如果元件在請求完成前被卸載，嘗試更新一個不存在的元件可能會導致錯誤或記憶體洩漏。

2. AbortController：通用的取消訊號

AbortController 是一個通用的 Web API，它提供了一種機制來中止一個或多個 Web 請求。它獨立於 Fetch API，但可以與 Fetch 完美配合。

AbortController 的核心思想是：

1. 建立一個 AbortController 實例。
2. 從這個實例中取得一個 AbortSignal 物件。
3. 將 AbortSignal 傳遞給可中止的 Web API（如 fetch）。
4. 當你需要取消時，呼叫 AbortController 實例的 abort() 方法。

3. AbortController 與 Fetch 的結合

讓我們透過一個範例來看看如何使用 AbortController 取消 Fetch 請求。

const controller = new AbortController();
const signal = controller.signal; // 获取信号对象

async function fetchDataWithCancellation(url) {
  try {
    console.log('Fetching data...');
    const response = await fetch(url, { signal }); // 将信号传递给 fetch
    const data = await response.json();
    console.log('Data received:', data);
    return data;
  } catch (error) {
    if (error.name === 'AbortError') {
      console.log('Fetch request was aborted.');
    } else {
      console.error('Fetch error:', error);
    }
  }
}

// 示例用法
const promise = fetchDataWithCancellation('https://jsonplaceholder.typicode.com/posts/1');

// 假设在 500 毫秒后，我们决定取消这个请求
setTimeout(() => {
  controller.abort(); // 调用 abort() 方法取消请求
  console.log('Request aborted by timeout.');
}, 500);

當 controller.abort() 被呼叫時，fetch 請求會立即中止，並拋出一個 AbortError。你需要在 catch 區塊中捕捉這個錯誤，並檢查 error.name === 'AbortError' 來區分是取消操作還是其他網路錯誤。

4. 實際應用情境

a. 搜尋即時輸入（Search-as-you-type）

當使用者在搜尋框中快速輸入時，每次輸入都可能觸發一個新的請求。我們可以取消前一個未完成的請求，只保留最新的請求。

let currentController = null;

document.getElementById('searchInput').addEventListener('input', (event) => {
  if (currentController) {
    currentController.abort(); // 取消上一个请求
  }
  currentController = new AbortController();
  const signal = currentController.signal;

  const query = event.target.value;
  if (query.length > 2) {
    fetchDataWithCancellation(`/api/search?q=${query}`, signal);
  }
});

b. 元件卸載時取消請求（Component Unmount）

在 React 或 Vue 等框架中，當元件卸載時，取消其內部發起的未完成請求可以有效避免記憶體洩漏和不必要的 UI 更新。

// React 示例
useEffect(() => {
  const controller = new AbortController();
  fetchDataWithCancellation('/api/data', controller.signal);

  return () => {
    controller.abort(); // 组件卸载时取消请求
  };
}, []);

結論

AbortController 是現代 Web 開發中一個不可或缺的工具。它為 Fetch API 和其他非同步操作提供了原生的取消機制，幫助開發者建構更健壯、更高效、使用者體驗更好的應用程式。掌握 AbortController 的使用，是成為一名優秀前端開發者的必備技能之一。