浮動式（floating） 是多數人熟悉的模式。視窗可以重疊、可以任意拖拉調整大小、可以最小化藏起來。macOS、Windows、GNOME、KDE 預設都是浮動式。操作直覺是「每個視窗是一張紙，自己決定放哪裡」。

平鋪式（tiling） 的規則不同：視窗自動排列填滿螢幕、不重疊，由 WM 的規則決定版面怎麼切割。開一個新視窗時，WM 自動把現有空間分一半給它；關掉一個視窗時，相鄰視窗自動擴展填補。操作直覺是「螢幕是一塊蛋糕，WM 負責切」。

多數平鋪式 WM 支援混合模式：特定視窗可以設為浮動，脫離平鋪規則。設定面板、密碼輸入框、小工具這類不適合塞進格子的視窗，通常會設成浮動例外。平鋪是預設，浮動是按需啟用的例外。

手動貼齊 vs 自動平鋪

在進入平鋪式 WM 之前，macOS 和 Windows 都提供了「手動貼齊」功能——用快捷鍵或拖拉把視窗貼到螢幕的半邊、角落、三分之一。macOS 原生的 window snapping、Windows 的 Snap Layout、以及 Rectangle 和 Magnet 這類第三方工具都屬於這個範疇。

手動貼齊跟自動平鋪的差距，在視窗數量少的時候幾乎感覺不到。開兩個視窗、左右各半，手動按一下快捷鍵就到位，完全夠用。

差距在視窗數量多的時候才出現。每開一個新視窗都要決定它放哪、按對應的快捷鍵；關掉一個視窗就留下空洞，要手動拖拉其他視窗去填——當這種版面管理的決策負擔開始分散你對工作本身的注意力時，就是自動平鋪開始有價值的時機。這個斷點因螢幕大小和工作類型而異：23 吋單螢幕上同時開終端機、編輯器、瀏覽器、文件，版面很快就不夠分；雙螢幕寬螢幕上同樣的視窗數量可能還很從容。

自動平鋪在這個情境下的優勢有三層。

第一層是自動回填。開視窗、關視窗，WM 自動重新分配空間，版面永遠是滿的、整齊的。你不用做任何版面決策。

第二層是操作對象的轉換。手動貼齊的操作對象是「某個視窗」——把 A 視窗貼到左邊、把 B 視窗貼到右上。平鋪式 WM 的操作對象是「版面結構」——把焦點往右移、把當前視窗跟隔壁交換、把這一格再水平切一半。你操作的是位置關係，不是絕對座標。

第三層是工作區整合。平鋪式工作流通常搭配多個工作區（workspace），每個工作區是一套獨立的平鋪佈局。「編輯器和終端機在工作區 1、瀏覽器在工作區 2、通訊軟體在工作區 4」——用快捷鍵瞬間切換整套上下文，而不是在一堆重疊視窗裡找。手動貼齊工具通常不帶工作區管理。

適用判讀

平鋪式視窗管理的投資報酬率取決於你的工作型態。

高回報情境：經常同時操作多個視窗且版面管理開始分散注意力、多數是「方方正正、可平鋪」的 app（終端機、編輯器、瀏覽器、文件閱讀器）、鍵盤操作為主、多螢幕、工作需要頻繁切換上下文（多個專案、不同任務區）。

低回報情境：大量使用需要特定比例或自由拖拉的 app（設計工具、影片剪輯、簡報製作）、很少同時開多個視窗、已經習慣且滿意目前的工作流、不想花時間學新鍵位。

折衷方案：所有平鋪式工具都支援 per-app 的浮動例外。不適合平鋪的 app（設定面板、計算機、某些對話框）設成浮動，其餘維持平鋪。這不是全有全無的選擇。

一個常見的踩坑模式是：看到 Hyprland 的截圖很漂亮，衝動裝了，發現日常有一半 app 不適合平鋪、鍵位記不住、每次更新都要修配置，兩週後放棄。務實的進入路徑是先在目前的系統上試手動貼齊工具（macOS 的 Rectangle 或 AeroSpace），確認自己真的享受鍵盤操作視窗的節奏，再往 Linux tiling WM 推進。或者用 VM 跑 Hyprland 體驗看看——體驗打折（VM 沒有 GPU 加速，動畫會卡），但能確認自己是否喜歡這種操作邏輯，再決定要不要花時間在實體機上搭建。

macOS 原生 Window Tiling（macOS 15+）

macOS Sequoia（15，2024 年 9 月）內建了 window tiling 功能：鍵盤快捷鍵把視窗貼到螢幕的半邊或四分之一、拖拉到邊緣自動貼齊（edge snap）、相鄰視窗可以組成 tile group 一起調整比例。

原生 tiling 的邊界：沒有多工作區管理、快捷鍵自訂空間有限（只能用系統偏好設定裡的固定選項）、不支援自動平鋪（仍然是手動觸發的 snap，不會在開新視窗時自動重排）。

如果「貼到半邊 + 邊緣吸附」就足夠，原生功能免安裝即可使用。以下第三方工具解決的是原生功能做不到的事：更多排列選項（Rectangle）、自動平鋪（Amethyst）、完整的鍵盤工作流加多工作區（AeroSpace / yabai）。

Rectangle

免費、開源。用快捷鍵把視窗貼到螢幕的半邊、三分之一、角落。不是自動平鋪——每個視窗都要你主動下指令。安裝後開箱即用，學習成本最低。

適合的情境：只需要快速排版、不想花時間學新操作邏輯、偶爾分割就滿足需求。

配置檔位置：~/Library/Preferences/com.knollsoft.Rectangle.plist（macOS plist 格式，不太適合手動編輯，通常用 GUI 設定）。

Amethyst

自動平鋪，安裝後視窗就會自動排列。提供多種 layout（tall, wide, fullscreen, column 等）可以用快捷鍵切換。設定比 Rectangle 多但比 yabai 少，是「想要自動平鋪但不想深度折騰」的選擇。

配置檔：~/.amethyst.yml，YAML 格式，可以版控。

AeroSpace

近年最受歡迎的選擇。核心優勢是不需要關閉 SIP（System Integrity Protection）——它用自己實作的虛擬工作區概念，不依賴 macOS 原生的 Spaces，因此繞過了很多系統層的限制。

配置是純文字的 TOML 檔 ~/.aerospace.toml，改完即時生效。工作區模型靈活，多螢幕支援被普遍認為比 yabai 穩定。

 1# ~/.aerospace.toml 片段
 2after-startup-command = ['workspace 1']
 3
 4[gaps]
 5inner.horizontal = 10
 6inner.vertical = 10
 7outer.left = 10
 8outer.right = 10
 9
10[mode.main.binding]
11alt-h = 'focus left'
12alt-j = 'focus down'
13alt-k = 'focus up'
14alt-l = 'focus right'
15alt-shift-h = 'move left'
16alt-shift-j = 'move down'
17alt-shift-k = 'move up'
18alt-shift-l = 'move right'
19alt-1 = 'workspace 1'
20alt-2 = 'workspace 2'
21alt-3 = 'workspace 3'

配置結構直覺：gaps 控制視窗間距、binding 定義快捷鍵對應的動作。整份檔案進 dotfile repo 就能跨機器還原操作習慣。

yabai + skhd

功能最完整的 macOS tiling WM。yabai 負責視窗管理，skhd 負責快捷鍵綁定。支援 BSP（binary space partitioning）樹狀分割——每次開新視窗都是把現有空間二分，形成一棵樹，你可以操作樹的節點來旋轉、交換、調整比例。

代價是部分進階功能（某些視窗操作、取消動畫）需要部分關閉 SIP。對某些人這是門檻，對另一些人不是問題。

配置檔是 shell script：.yabairc（yabai 設定）和 .skhdrc（快捷鍵設定），進 dotfile repo 管理。

 1# .yabairc 片段
 2yabai -m config layout bsp
 3yabai -m config window_gap 10
 4yabai -m config top_padding 10
 5yabai -m config bottom_padding 10
 6
 7# 某些 app 不適合平鋪，設為浮動
 8yabai -m rule --add app="System Preferences" manage=off
 9yabai -m rule --add app="Calculator" manage=off
10yabai -m rule --add app="Finder" title="Info" manage=off

選型判讀

選工具的判準不是「哪個最強」，而是「你願意花多少時間、想要多少控制權」。

只需要快速排視窗、不想改工作習慣，Rectangle 足夠。想要自動平鋪但學習曲線要短，Amethyst 是進入點。想要完整的平鋪工作流、多工作區管理、純文字配置、又不想動系統安全設定，AeroSpace 是目前多數人推薦的首選。想要最大的控制權、願意處理 SIP 和更複雜的配置，yabai 給你最多彈性。

從 Rectangle 跳到 AeroSpace 或 yabai 是一次操作思維的轉換——從「我指定每個視窗去哪」變成「我操作版面結構、WM 負責排列」。這個轉換需要一兩週的適應期，適應期內效率會暫時下降。

X11（X Window System）是用了三十多年的傳統協議。成熟、穩定、所有工具都支援。設計上的根本問題是安全性——任何 X11 應用程式都能讀取其他視窗的內容和鍵盤輸入，這是協議層的限制，不是 bug。

Wayland 是設計來取代 X11 的新協議。每個應用程式只看得到自己的視窗、效能更好、對現代硬體的支援更完整。多數主流發行版已經把 Wayland 設為預設，但部分老舊應用程式和特殊需求（某些螢幕錄製、遠端桌面工具）的支援還在追趕中，這些情境會透過 XWayland（相容層）跑 X11 應用程式。

新的 tiling WM 主要基於 Wayland 開發，X11 上的老牌（i3, bspwm, dwm）仍然活躍但不再是未來方向。

主流 Tiling WM

i3（X11）/ sway（Wayland） 是社群最大、文件最齊全、行為最可預測的選擇。i3 跑在 X11 上，sway 是它的 Wayland 移植，配置格式幾乎相同。配置檔用自己的語法，直覺的 key = action 對應。

1# sway/config 片段
2set $mod Mod4
3bindsym $mod+h focus left
4bindsym $mod+j focus down
5bindsym $mod+k focus up
6bindsym $mod+l focus right
7bindsym $mod+Shift+h move left
8bindsym $mod+1 workspace number 1
9bindsym $mod+2 workspace number 2

穩定性是 i3/sway 最大的賣點——配置寫好之後很少因為更新而壞掉。適合想要可靠的平鋪工作流、不需要華麗視覺效果的人。

Hyprland（Wayland） 吸引的是在意桌面視覺品質的平鋪使用者——看 r/unixporn 的 Hyprland 截圖就知道，流暢的視窗切換動畫、圓角、視窗模糊、漸層邊框，這些傳統 tiling WM 社群視為不必要的裝飾，Hyprland 做成內建功能並且認真打磨。配置檔改完即時生效（hot reload），迭代調教的回饋循環很短。

這份視覺投入換來的 trade-off 是穩定性。開發節奏快意味著偶爾會有 breaking changes——某次更新後配置語法改了（2026 年 4 月的 Lua 遷移就是一例）、某個選項改名或移除。把它當主力桌面，要有「更新後可能要回來調配置」的心理準備。Hyprland 配置會詳細講它的設定。

bspwm（X11） 是純粹的 BSP 樹狀分割。它只做一件事：管理視窗的樹狀結構。所有操作透過 bspc 命令列工具驅動，快捷鍵綁定交給 sxhkd（一個獨立的快捷鍵 daemon）。UNIX 哲學——每個工具只做一件事，組合起來用。

dwm（X11） 極簡到配置要改 C 原始碼然後重新編譯。不是給「想要方便配置」的人用的，而是給「想要完全理解自己桌面每一行程式碼」的人用的。

拼裝式桌面的代價

Linux tiling WM 的桌面是你自己拼出來的：compositor（Hyprland/sway）負責視窗管理、狀態列（waybar）負責頂部資訊條、啟動器（rofi/wofi）負責 app 搜尋啟動、通知（mako/dunst）負責通知彈窗、鎖屏另外裝。每一塊是不同專案、不同作者。

好處是每一塊都可以換。壞處是當某件事壞了，你要自己判斷是哪一層的問題。藍牙選單不能點？可能是狀態列的 module 設定錯、可能是 blueman 沒跑、可能是 D-Bus session 有問題。完整桌面環境（KDE/GNOME）幫你整合測試過了，拼裝式桌面沒有這層保障。

多螢幕的處理

多螢幕是自動平鋪比較能展現價值的場景。每個螢幕是獨立的平鋪區域，視窗在哪個螢幕就在那個螢幕的範圍內平鋪。

快捷鍵跨螢幕操作是標配功能：把焦點跳到另一個螢幕、把當前視窗丟到另一個螢幕（丟過去後自動融入那邊的平鋪佈局）。三螢幕時這個便利性比單螢幕更明顯——純滑鼠拖視窗跨螢幕需要的移動距離很長。

工作區跟螢幕的綁定方式是各工具差異最大的地方。

macOS 的 Spaces 是綁定螢幕的——每個螢幕有自己獨立的一組 Spaces。yabai 沿用這個行為，切換工作區時只影響當前螢幕。AeroSpace 用自己的虛擬工作區繞過 macOS 原生 Spaces 的限制，多螢幕操作被普遍認為更穩定、更直覺。

Hyprland 的 workspace 可以動態指派到不同螢幕——workspace 3 現在在螢幕 A，你可以把它移到螢幕 B。這種模型彈性最大，但也需要清楚的心智模型來管理「哪個 workspace 在哪」。

熱插拔螢幕（接上、拔掉外接螢幕）是各工具的常見痛點。拔掉螢幕時，該螢幕上的視窗要搬到剩餘螢幕重新平鋪；插上螢幕時，佈局要擴展。多數工具有對應設定（記住螢幕配置、自動還原佈局），但體驗不見得完美，偶爾需要手動整理。

Dotfile 中的視窗管理配置

視窗管理是 dotfile 管理裡「桌面層」的核心。WM 配置檔決定了整個桌面的操作邏輯——快捷鍵怎麼綁、視窗間距多大、哪些 app 要浮動、工作區怎麼分配。

macOS 工具的配置檔通常是一個檔案：AeroSpace 的 ~/.aerospace.toml、yabai 的 ~/.yabairc + ~/.skhdrc、Amethyst 的 ~/.amethyst.yml。把這些檔案放進 dotfile repo，換 Mac 時就能還原整套視窗管理行為。

Linux tiling WM 的配置在 ~/.config/ 下，通常是一個資料夾：Hyprland 的 ~/.config/hypr/、sway 的 ~/.config/sway/、i3 的 ~/.config/i3/。除了 WM 本身，狀態列（waybar 的 ~/.config/waybar/）、啟動器（rofi 的 ~/.config/rofi/）、通知（mako 的 ~/.config/mako/）等周邊元件的配置也各自有檔案。一套完整的 Linux 平鋪桌面，dotfile repo 裡可能會有十幾個配置目錄——這也是為什麼 Linux 桌面客製化社群那麼依賴 dotfile 管理工具（見管理工具與目錄結構）。

跟螢幕硬體綁定的設定（螢幕解析度、縮放比、螢幕排列順序）通常也寫在 WM 配置裡。這部分在跨機器搬移 dotfile 時需要調整——同一份 Hyprland 配置裡的 monitor 設定，在筆電上是一個螢幕、在桌機上可能是三個。常見做法是把硬體相關設定拆到單獨檔案（如 monitors.lua），主配置用 require 引入，這樣跨機器時只需要替換這一個檔案。同步與環境重建會講跨機器搬移時怎麼處理這類硬體差異。

Wayland 是協議，不是軟體

一個常見的誤解是把 Wayland 當成「一個程式」。Wayland 是一份協議規格（protocol specification），描述了 client（應用程式）和 compositor（負責合成畫面的東西）之間怎麼傳遞 buffer、怎麼處理輸入事件。

每個 Wayland compositor 同時扮演三個角色：display server（管理顯示輸出）、window manager（管理視窗排列）、compositor（合成最終畫面）。X11 的世界裡這三個角色是分開的，Wayland 把它們統一成一個程式。這個「三合一」定位的濃縮版與它在故障排除中的責任邊界，見 Compositor 術語卡。

「Hyprland 是 Wayland compositor」這個說法的意思是：它不只是一個視窗管理器，它同時是整個圖形系統的核心。

X11 vs Wayland 架構差異

X11 的三角架構（1984 年設計）

1應用程式 ──→ X Server（中央仲介）──→ Compositor ──→ 螢幕
2             ↑                         ↑
3             └── 輸入事件 ──────────────┘

X Server 是一個龐大的中央仲介，負責接收所有應用程式的繪圖指令、管理輸入事件、再把畫面交給 compositor 做最終合成。Compositing 是後來才加上去的（Compiz、picom 這些都是外掛的 compositor），不是 X11 原始設計的一部分。

Wayland 的直接模型（2008 年設計）

1應用程式 ──→ Compositor（= display server + window manager）──→ 螢幕
2             ↑
3             └── 輸入事件

應用程式用 OpenGL/Vulkan 自己渲染畫面到 buffer，然後把 buffer 直接交給 compositor。沒有中間人。compositor 收到所有 client 的 buffer 後合成最終畫面輸出到螢幕。

這個架構上的差異帶來三個實際影響：效能、安全、screen tearing。

安全性

X11 的安全模型有一個根本性的設計缺陷：任何連到同一個 X Server 的 client，都能監聽其他 client 的鍵盤輸入、擷取其他視窗的畫面、甚至注入假的輸入事件。這代表一個惡意程式可以輕易做到 keylogging——記錄你在其他視窗打的所有字，包括密碼。

Wayland 從協議層就隔離了 client 之間的存取。每個應用程式只看得到自己的 buffer，無法存取其他視窗的內容或輸入。要做 screen capture 或 screen sharing，必須透過 xdg-desktop-portal 這個受控的中介機制，使用者會看到明確的授權提示。

對 tiling WM 的使用者來說，這個安全差異特別有意義：平鋪式桌面通常同時開大量終端機視窗（有些跑 SSH、有些在 sudo 操作），X11 下任何一個視窗裡的惡意程式都能讀到其他視窗的鍵盤輸入。Wayland 阻斷了這條攻擊路徑。

效能與 Screen Tearing

X11 的渲染路徑有多餘的記憶體複製——應用程式把繪圖指令送給 X Server，X Server 渲染後再交給 compositor，compositor 再合成。Wayland 省掉了中間那一步：應用程式直接渲染到 buffer、直接交給 compositor，記憶體複製更少。

Screen tearing（畫面撕裂）在 X11 上是長年的老問題——需要 compositor + vsync 的各種 workaround。Wayland 在協議層就處理了 frame presentation 的時機，compositor 控制什麼時候把合成好的畫面送到螢幕，原生消除 tearing。這也是為什麼 Hyprland 的動畫能跑得流暢——直接 rendering + 原生 vsync 的組合，在 X11 上需要大量額外配置才能接近的效果。

XWayland：X11 相容層

很多應用程式仍然只支援 X11 協議。XWayland 是一個 X11 server，但它本身作為一個 Wayland client 運行——X11 應用程式連到 XWayland，以為自己在跟正常的 X Server 溝通；XWayland 把 X11 協議翻譯成 Wayland 協議，把 buffer 交給 compositor。

多數 Wayland compositor（包括 Hyprland）預設啟用 XWayland，X11 應用程式不需要任何設定就能運行。

需要 XWayland 的常見應用

• 舊版 Electron 應用（新版可用 --ozone-platform=wayland 旗標切換到 Wayland 原生）
• Java 應用程式（NetBeans 等）
• 舊的 GTK2 應用程式
• 部分 Wine/Proton 遊戲（但 XWayland 下的遊戲效能已經相當好）
• 未啟用 PGTK 的舊版 Emacs build（Emacs 29+ 的 PGTK 後端已原生支援 Wayland）

XWayland 的已知問題

最大的實務痛點是 HiDPI 非整數縮放。在 150%、125% 等非整數 scale 下，XWayland 應用程式可能出現模糊渲染，因為 XWayland 不支援 fractional scaling 協議。整數縮放（100%、200%）則沒有問題。

關鍵 Wayland 協議

wlr-layer-shell

Layer-shell 定義了 client 可以在螢幕的哪個「層」上建立畫面——background（最底）、bottom、top、overlay（最頂）。Status bar（waybar）、notification daemon（mako）、launcher（wofi）、wallpaper（hyprpaper）、lock screen（hyprlock）都透過 layer-shell 來佔據螢幕空間。

沒有 layer-shell 支援的 compositor，這些桌面元件就無法運作。這也是為什麼桌面 Rice 設計的所有工具都只能在支援 layer-shell 的 Wayland compositor 上跑——它是可組裝式桌面的基礎設施。

xdg-desktop-portal

Portal 是一個 D-Bus 介面，讓被隔離的 Wayland 應用程式可以請求特權操作：screen sharing、檔案對話框、螢幕截圖。每個 compositor 提供自己的 portal backend：

• Hyprland：xdg-desktop-portal-hyprland
• GNOME：xdg-desktop-portal-gnome
• KDE：xdg-desktop-portal-kde
• Sway/wlroots 系：xdg-desktop-portal-wlr

Screen sharing 的完整鏈路是：PipeWire + xdg-desktop-portal-hyprland。OBS 的 PipeWire source、瀏覽器的畫面分享，都走這條路。

wlroots 與 Hyprland 的關係

wlroots 是一個模組化的 C library，提供 Wayland compositor 的共用基礎建設——輸入處理、輸出管理、協議實作。Sway、river、wayfire 這些 compositor 都基於 wlroots 開發，共享同一套底層程式碼。

Hyprland 最初也基於 wlroots，但後來 fork 出去自己維護底層。這讓 Hyprland 可以更快地加入新功能（動畫、模糊、漸層邊框），不需要等 wlroots 上游審核。代價是 Hyprland 的更新不再跟 wlroots 生態同步，偶爾會有相容性差異。

2026 年的 Wayland 採用現況

Wayland 在 2026 年已經從「取代 X11 的方向」變成「Linux 桌面的預設」：

X11 上的老牌 tiling WM（i3、bspwm、dwm）仍然活躍，但不再是新專案的主流方向。新的 tiling WM 幾乎都選擇 Wayland 作為基礎。

X11 仍有優勢的場景

Wayland 並非在所有面向都超越 X11：

• SSH X forwarding：X11 原生支援透過網路轉送 GUI 視窗（ssh -X）。Wayland 沒有對等機制，替代方案是 waypipe，但不是 drop-in replacement
• 跨 compositor 的 GUI 自動化：xdotool、wmctrl 在 X11 上可以操控任何 WM 的視窗。Wayland 沒有跨 compositor 的通用對應方案——每個 compositor 提供自己的 IPC 工具。不過 Hyprland 的 hyprctl 在 Hyprland 環境內提供了比 xdotool 更豐富的能力：socket-based IPC、JSON 格式查詢所有視窗和工作區狀態、即時 dispatch 動作、event 監控（hyprctl socket2）。瓶頸在「跨 compositor 通用」，不在單一 compositor 內的功能深度
• VNC / 遠端桌面：X11 的網路透明性讓遠端桌面相對簡單。Wayland 需要 PipeWire + portal，設定複雜度更高
• Color management：專業色彩工作流（ICC profile 管理）在部分 Wayland compositor 上仍需手動配置

這些場景如果是你的核心需求，目前 X11（或 X11-based 的 i3/sway 的 X11 版本）可能仍是更務實的選擇。

為什麼 Tiling WM 使用者該關心 Wayland

平鋪式桌面是「自己從元件組裝桌面」的工作流。Wayland 的幾個特性讓這件事變得更好：

layer-shell 給了 status bar、launcher、notification daemon 一個標準化的方式來佔據螢幕空間，不再需要各種 hack 讓這些元件「浮在視窗上面又不被平鋪規則管到」。

安全隔離在多終端機場景特別有價值——平鋪式桌面通常同時開著 SSH session、密碼管理器、sudo 操作，Wayland 確保任何一個視窗裡的程式都無法偷看其他視窗的鍵盤輸入。

直接 rendering 讓 Hyprland 能做到流暢的視窗動畫和即時模糊，這在 X11 上需要大量額外的 compositor 配置（picom + 各種 backend 選擇 + vsync 調校）才能接近。

從實務角度看：2026 年開始接觸 Linux tiling WM，選 Wayland-based 的工具（Hyprland、Sway）是順流而行。X11 不會立刻消失，但新功能、新工具、社群活力都在 Wayland 這一邊。