光輝咖碼

11ty vs Hugo vs Astro 怎麼選？2026 靜態站產生器決策指南

2026-08-13T03:55:00Z

你已經大概知道 WordPress 不是唯一答案，也聽過「靜態站比較快、比較安全」。結果一搜框架，Hugo、Eleventy（11ty）、Astro 三邊都說自己最適合部落格——讀起來像三杯咖啡同時跟你保證「我這杯最提神」。

選錯的代價很實在：遷移白做一輪、CI build 等到你懷疑人生，或為了用 React 元件硬上 Astro，結果整站只有純文章，卻多了一層元件編譯。這篇不幫你選「2026 最潮框架」，而是幫你回答：以你的文章量、團隊技能、要不要互動元件，三個候選裡誰最不容易後悔。

先確認：你真的需要 SSG 嗎？

在 Hugo、11ty、Astro 裡三選一之前，先確認你該走「純靜態 SSG」這條路，而不是續用 WordPress、Statamic 或 Wix 這類 SaaS。框架選型是第二關，第一關是「你到底要不要靜態化」——還沒過第一關就選 Astro，有點像還沒決定要煮咖啡就先買磨豆機。

若你符合下面多數條件，再往下讀框架比較：

每月新文不多（例如 ≤ 30 篇），格式相近（教學、比較、清單）
至少一人會 git，或願意學「改 Markdown → push → 自動 deploy」
不需要訪客登入、購物車、即時庫存
痛點包含被駭、外掛衝突、主機慢、Core Web Vitals 拉不起來
可接受沒有 wp-admin（或願意走 Headless 混合架構）

若編輯一定要網頁後台，別硬選 SSG——先看 Statamic 或 Headless WordPress。若一週內要上線、零技術，SaaS 可能更實際。還在猶豫要不要離開 WP，可以先讀站內的 WordPress vs 11ty 比較，別還沒決定「要不要靜態」就選框架。

三個框架一句話定位

工具	一句話	典型誰在用
Hugo	Go 寫的極速印表機，模板用 Go template	頁數破千的部落格、多語系大站、技術文件
Eleventy（11ty）	JS 極簡派，模板語言你愛用哪種就哪種	個人站、內容網站、想完全掌控輸出的人
Astro	內容優先 SSG，預設零 JS，要互動才長 Islands	新開內容站、要比較表有一點互動、MDX 愛好者

白話說，三者都是「離線印報紙」：本機或 CI 執行 build，把 Markdown 和模板烤成 _site/ 或 dist/ 裡的 HTML，再上傳 CDN。訪客看到的是靜態檔，沒有 wp-admin、沒有 PHP——PHP 可以下班了，你也不用半夜擔心外掛更新。

60 秒主決策表：先圈出 1～2 個候選

你的狀況	優先考慮	為什麼
文章 500 篇以下、團隊只會一點 JS、要極瘦 HTML	11ty	build 夠快、無框架鎖定；純 Markdown 教學／比較文維護成本低
同上，但想要 Content Collections、MDX、頁面裡嵌 React 比較表	Astro	Islands 只 hydration 需要互動的區塊
文章 3,000+ 篇或 CI build 常超 2 分鐘	Hugo	Go 引擎對大站友好；多語系路由成熟
想最快套現成皮、少改程式（像套 Hugo 主題）	Hugo	themes.gohugo.io 主題市場大
要 npm 外掛（圖片管道、Obsidian 同步、自訂 JS 資料源）	11ty	全 npm 生態；`eleventy.config.js` 就是 JS
要內建多語系 i18n、不想靠外掛	Hugo	i18n 第一公民
文末推薦區塊、比較表版型要完全自控、長期零框架風險	11ty	沒有元件編譯步驟，十年後還能維護
文章靜態、但底部要篩選器／計算機等互動	Astro	`client:visible` 捲到才載 JS，不拖慢全文
已有一堆 Nunjucks／JS 資產	11ty	不必重寫成 Go template

圈出候選後，各花 10 分鐘跑 hello-world（文末有指令），比看十篇 benchmark 文還準。哪個讓你更快「改標題 + 加一篇假文 + 看到 HTML」，長期就選那個——手感順的框架，比社群吵架文可靠。

規格比較表：知道 trade-off 在哪

面向	Hugo	Eleventy（11ty）	Astro
語言／環境	Go 單一執行檔，不用裝 Node	Node.js 18+	Node.js 18+
模板	Go template（學習曲線陡）	Nunjucks、Liquid、MD…可混	`.astro` + 可選 React/Vue/Svelte
預設 JS 輸出	0（除非你加）	0	0（Islands 才加）
約 1,000 頁 build	約數秒級	約 30 秒級（視外掛而定）	約 45 秒級
多語系 i18n	內建強	需外掛	內建路由支援
MDX／元件	有限	靠外掛	原生強
主題生態	上百個現成主題	Starter 專案 + 自訂 `layouts/`	官方模板 + 元件化
最適託管	任何靜態主機	Cloudflare Pages、Netlify、Hostinger	同上

數字會因機器、圖片外掛、模板複雜度而變——重點是比較級距，不是死記秒數。Go template 學起來像另一門語言，但 Hugo 不會因為你還在背 range 就幫你 build 快一點。

Build 速度：別為了 benchmark 選錯框架

很多人選 Hugo 只因為「build 最快」。這在超大站確實重要；但對內容網站，上線後的 Core Web Vitals 比本機 build 幾秒更影響 SEO。

基準情境	Hugo	11ty	Astro	怎麼讀
約 4,000 篇 Markdown（11ty 官方基準）	0.68s	1.93s	~23s（2022 基準）	大站 Hugo 優勢明顯
約 1,000 頁（業界常引級距）	約 1～3s	約 5～15s	約 45s 級	中小站都可接受
上線後客端 JS（預設）	0 KB	0 KB	0 KB	三者都能衝 Lighthouse 98+

幾百篇的個人站：11ty 和 Hugo 上線後速度通常差不多，CDN 一掛 TTFB 多在 10～30ms 級。別為了省 10 秒 build 去啃 Go template，除非你已經確定 CI 是瓶頸。

若你選 11ty 卻覺得 build 變慢，先查：圖片外掛、build 時打外部 API、或未 memoize 的 filter——不一定代表該換 Hugo，有時只是某個 filter 在偷跑馬拉松。

內容網站情境：誰比較順？

情境	建議	對 SEO／變現的影響
比較文、教學文為主，月發 4～8 篇，要衝 Core Web Vitals	11ty 或 Astro	頁面瘦 → GSC 體驗報表較好看
文末推薦、比較表版型要統一，互動少	11ty	Nunjucks 版型直覺，輸出極瘦
文章 + 互動比較表篩選器 + 偶爾 MDX	Astro	Islands 控 JS 預算，正文仍靜態
站齡久、上千篇舊文要一次遷移	Hugo 或分批遷移 + 11ty	build 時間影響 CI 成本與專案排程
Obsidian vault → 網站工作流	11ty	與 npm 生態、Markdown 工作流契合
週末上線個人部落格、想最快套皮	Hugo + 主題	主題一行掛上即可
完全不想碰 CLI，編輯要自己發文	跳過 SSG	改看 Statamic 或 Headless WP

兩兩對打：你卡在誰跟誰之間？

11ty vs Hugo：極速 SSG 二選一

兩邊預設都是零 JS、Jamstack 路線。差別在誰更適合你的團隊與規模：

選 11ty：頁數還沒破千、團隊熟悉 JS／Nunjucks、要 npm 外掛、文章與推薦區塊版型完全自控
選 Hugo：三千篇以上、CI 常超 2 分鐘、內建多語系、想最快套現成主題

Hugo 的 Go template 學習曲線比 Nunjucks 陡；11ty 沒有 Hugo 那種「一行掛主題」的生態，但換來你擁有全部 layout 原始碼。想再深入，可搭配站內靜態網站產生器入門一起看。

11ty vs Astro：JavaScript 陣營二選一

兩邊都跑在 Node.js，但工作流差很多：

選 11ty：純 Markdown 進、HTML 出；互動用原生 JS 或 Web Components 就夠
選 Astro：要 React 元件、Content Collections 型別檢查、比較表篩選器用 client:visible

Astro 的 Islands 讓整頁先當純 HTML 送出，只有標了 client:* 的區塊才載入 JS——適合「3000 字正文靜態、底部篩選器要互動」的長文頁。若你只是放幾個推薦連結或按鈕，11ty 的純 HTML 往往更簡，不必為了兩顆按鈕請整艘 React 郵輪進港。

10 分鐘 hello-world：選型必做

選出 2 個候選後，各花 10 分鐘跑完——感受比讀文重要。

Eleventy

mkdir my-11ty-test && cd my-11ty-test
npm init -y
npm install @11ty/eleventy
npx @11ty/eleventy --init
echo '# Hello' > content/index.md
npx @11ty/eleventy --serve
# 瀏覽器 http://localhost:8080 應看到標題

Astro

npm create astro@latest my-astro-test
# 選 Empty 或 Blog 模板
cd my-astro-test && npm run dev
# 瀏覽器 http://localhost:4321

Hugo

# 需先安裝 Hugo：https://gohugo.io/installation/
hugo new site my-hugo-test && cd my-hugo-test
git init
hugo new content posts/first.md
hugo server -D
# 瀏覽器 http://localhost:1313
# 新手可 clone themes.gohugo.io 上的示範站，少踩 layout 坑

若兩個都順，內容網站優先輸出最瘦、CI 最穩的那個——通常是 11ty 或 Hugo。

選完框架之後的三件事

託管：Cloudflare Pages、Netlify 或 Hostinger 靜態空間都可以。若你已經用 11ty，站內 11ty 與 Hostinger 快取設定也值得先 bookmark。
HTTPS：靜態站一樣要憑證。可參考站內免費 SSL 憑證教學。
遷移 SEO：若從 WordPress 來，URL、301、sitemap、canonical 仍要維護——別以為換框架就自動升級排名。

常見問題

Q：2026 大家都說 Astro 是預設，我還用 11ty 會不會過時？

不會。Astro 適合「想要元件模型、MDX、多框架」的站；純 Markdown 教學／比較文用 11ty 往往更簡、build 設定更少。兩邊都是活躍專案，過時的是「沒在發文」，不是「沒換框架」。

Q：Hugo 這麼快，為什麼還有人主力用 11ty？

Go template 學習成本、與現有 JS／Nunjucks 資產的相容性。頁數還沒破千時，11ty build 夠用；日後若 CI 變瓶頸再評估 Hugo 遷移。

Q：我已經有 11ty 站，要為了潮流換 Astro 嗎？

沒有「需要 React 元件卻硬用 Nunjucks 拼」的痛點就不必換。遷移有 URL、模板、CI 成本。Astro 官方有從 Eleventy 遷移指南，但那是你有明確互動需求時才值得開的專案。

Q：Jekyll 呢？

已在 GitHub Pages 上、文章少可以繼續。新開個人站、要衝 SEO 與維護效率，優先 11ty／Astro／Hugo。

結語：選能維護的，不是選 benchmark 冠軍

Hugo、11ty、Astro 都能做出極快的靜態內容站。真正會讓你後悔的，通常不是「差 10 秒 build」，而是：

選了 Go template 卻團隊只會 JS
為了互動硬上 Astro，結果整站只有純文章
三千篇舊文用 11ty 卻沒評估 CI 時間

先用 60 秒決策表圈候選，再各跑 10 分鐘 hello-world。選定後把託管、HTTPS、遷移 SEO 一次做完——框架只是起點，能持續發文、GSC 體驗報表維持綠色，才是個人站長期流量與轉換的基礎。

若你已經圈出 11ty 或 Hugo，下一步可以開一個最小專案、部署到 Hostinger 或 Cloudflare Pages，用真實網域跑一次 PageSpeed Insights——比較表選對了，馬上就能驗證。驗收完再來一杯咖啡；這次等的是 deploy，不是 CI。

參考資料

Eleventy 官方文件 — Performance：11ty 與其他 SSG 的 build 速度基準與優化建議。
Astro 官方 — Why Astro：Astro 內容優先與 Islands 架構的設計說明。
Astro 官方 — Islands architecture：client:load、client:visible 等指令的行為說明。
Astro 官方 — Migrating from Eleventy：從 11ty 遷移到 Astro 的官方指南。
Hugo 官方文件：Hugo 安裝、模板與多語系設定。
Hugo Themes：Hugo 現成主題目錄，適合快速套皮評估。

Proton Unlimited 全產品與功能介紹（2026）：六合一隱私全家桶值得買嗎？

2026-08-12T09:27:00Z

你本來只想買杯咖啡，結果櫃檯問你要不要加購「瑞士隱私全家桶」——Mail、Calendar、Drive、Pass、VPN、Wallet 一次上。聽起來很划算，但你不確定自己到底會用到幾個 App，還是只會讓 Proton 默默扣款、你默默只用 VPN。

這篇就是幫你把 Proton Unlimited 拆開來看：六個產品各自解決什麼痛點、什麼情境該開哪個、跟單買 Mail Plus 或 VPN Plus 差在哪，以及 2026 年結帳前該怎麼比價。讀完你會知道——全家桶是幫你逃離 Google 控制的，不是幫 Proton 清庫存的。

先講結論：Proton Unlimited 是什麼？

一句話：一個帳號、一筆訂閱，解鎖 Proton 六大核心產品的付費版（Plus 層級）。

產品	Unlimited 內容摘要
Proton Mail	15 個信箱地址、3 個自訂網域、500 GB 共用儲存、無限別名、Proton Sentinel
Proton Calendar	25 個個人行事曆、加密與分享
Proton Drive	與 Mail 共用 500 GB、Docs 線上編輯、進階分享與版本歷史
Proton Pass	50 個 vault、無限 Hide-my-email 別名、內建 2FA
Proton VPN	VPN Plus 全功能：10 台同時連線、120+ 國家、串流、P2P、Secure Core 等
Proton Wallet	10 個錢包、每個錢包 10 個帳戶（自託管 Bitcoin）

附帶但非付費層：Proton Lumo（AI 助理，免費額度）、Proton Meet（免費會議額度）。若要 Lumo Plus 或 Meet Professional，需要 Visionary 等更高方案。

適合誰：不只想要 VPN，而是想把信箱、密碼、雲端、網路連線一起搬到瑞士隱私生態系的人。若你只需要其中一兩項，單買 Mail Plus 或 VPN Plus 通常更划算——就像你不會為了喝一口濃縮，把整間咖啡廳買下來。

六大產品：解決什麼問題、什麼時候用？

Proton Mail — 取代 Gmail 的加密信箱

解決的問題：一般信箱（Gmail、Outlook）供應商能讀取或分析你的信件內容來投放廣告；資料也可能因法院命令外洩。

什麼時候用：

日常收發工作／私人郵件，想脫離 Google 生態
需要自己的網域信箱（you@yourname.com）
要用 Outlook、Thunderbird 等桌面程式（透過 Proton Mail Bridge）
寄給非 Proton 用戶時要密碼保護郵件

Unlimited 相關上限：15 個信箱地址、3 個自訂網域、與 Drive 共用 500 GB、無限寄信（合法用途）、Dark Web Monitoring、Proton Sentinel 帳戶保護。

簡單例子：你經營小型接案，想讓客戶寄到 hello@你的品牌.com，又不想讓 Google 掃描信件內容——Mail + 自訂網域就是起點。

Proton Calendar — 取代 Google Calendar 的加密行事曆

解決的問題：雲端行事曆預設可被服務商讀取；會議時間、行程模式會變成可分析的個資。

什麼時候用：

與 Mail 同一帳號管理行程，減少第三方日曆同步
需要加密分享行事曆給家人或同事（透過連結）
預約會議時段（Appointment scheduling，依方案開放）

Unlimited 相關上限：25 個個人行事曆；儲存空間與 Mail、Drive 共用池。

簡單例子：你跟伴侶共用「家庭行程」日曆，又不想讓平台知道你们每週幾點出門——用 Proton Calendar 分享，比把 Google 日曆設成公開安全。Google 不會因此少賺廣告費，但至少你的行程不會變成「週五晚上常出門」的推薦標籤。

Proton Drive — 取代 Google Drive 的加密雲端

解決的問題：一般雲端硬碟由供應商持有金鑰，帳號被駭或內部存取時檔案可能外洩。

什麼時候用：

備份合約、身分證掃描、財務文件
與客戶分享檔案（可設密碼與到期連結）
在瀏覽器裡編輯 Docs／試算表（無需下載解密）

Unlimited 相關上限：與 Mail 共用 500 GB；含線上文件編輯、進階分享安全、檔案版本歷史（最多 200 版／檔、保留最長 10 年）。

簡單例子：Freelancer 把報價 PDF 放在 Drive，用密碼連結傳給客戶——連結過期後對方就打不開，比 Email 附件好控管。客戶可能會抱怨「連結失效」，但至少你的合約不會在對方轉寄時裸奔。

Proton Pass — 取代 Chrome 密碼管理器

解決的問題：瀏覽器內建密碼庫綁在 Google／Apple 帳號上；外洩時密碼與信箱一併失守。註冊網站時還會把真實信箱留給對方。

什麼時候用：

為每個網站產生唯一強密碼
用 Hide-my-email 別名註冊，之後可一鍵停用別名
在 Pass 內建 2FA 驗證器，登入時少切 App
跨手機、電腦、瀏覽器同步（不限裝置數）

Unlimited 相關上限：50 個 vault、無限 Hide-my-email 別名、內建 2FA authenticator。

簡單例子：你在購物網站註冊，用 Pass 產生 random@pm.me 別名 + 32 字元密碼；若該站日後外洩，你停用別名即可，真實信箱不受影響。這比「用生日當密碼」安全，也比「把密碼寫在便利貼上」——至少便利貼不會被駭。

Proton VPN — 公共網路與 ISP 窺探的防護層

解決的問題：咖啡廳 Wi‑Fi、機場網路可能被竊聽；ISP 能看到你連了哪些網站；部分地區有審查或地理限制。

什麼時候用：

旅行、遠端工作連公共 Wi‑Fi
需要解鎖串流地區片庫（Netflix、Disney+ 等，依服務條款）
BT／P2P 下載要走加密隧道
高風險情境需要 Secure Core 或 Tor over VPN

Unlimited 內含 VPN Plus：10 台裝置同時連線、最高速度、15,000+ 伺服器／120+ 國、NetShield、串流、P2P、Secure Core、Tor over VPN、Split tunneling（Android／Windows）等。

簡單例子：你在日本旅館 Wi‑Fi 上要處理銀行帳務——先開 VPN + 確認 Kill Switch，再開銀行網站，比裸連公共網路安心。Kill Switch 的意思是 VPN 斷線時網路也斷，不會讓你的流量偷偷裸奔——比「我以為有連上」可靠。

若你只需要 VPN、不需要 Mail／Pass，請直接比較 VPN Plus 與 Unlimited，別用 Unlimited 月費當 VPN 單價。可搭配站內 Proton VPN 付費版評價。

Proton Wallet — 自託管 Bitcoin 錢包

解決的問題：把 BTC 放在交易所，交易所倒閉或被駭時可能拿不回資產（「Not your keys, not your coins」）。

什麼時候用：

長期持有少量 Bitcoin，要自己掌控私鑰
用 Bitcoin via Email 轉帳（驗證信箱即可，降低貼錯地址風險）
需要瑞士管轄 + 開源程式碼的錢包

Unlimited 相關上限：10 個錢包、每錢包 10 個帳戶（Free 為 3×3）。Wallet 不是交易所——Proton 不做炒幣，只做託管錢包。

簡單例子：你每月定額買一點 BTC 長期持有，用 Wallet 自託管比放在交易所適合；但若你需要頻繁交易，仍應使用合規交易所——Wallet 是保險箱，不是股票 App。

訂閱前先跑一輪盤點

別讓訂閱變成「買了六個 App，開了兩個，剩下四個在背景默默續約」。照這六步盤點：

列出你現在用哪些 Google／Microsoft 服務（信箱、雲端、密碼、日曆、VPN）。
對照上方六產品表，標記「一定要／可有可無／不需要」。
數儲存與帳號：500 GB 夠嗎？需要幾個自訂網域？家裡幾台裝置同時連 VPN？
到 proton.me/pricing 登入後切換幣別（USD／EUR／CHF）與計費週期，看 Unlimited 與單品加總誰比較便宜。
若兩人以上，改看 Proton Duo（2 人、2 TB）或 Family（6 人、3 TB），不要硬買兩個 Unlimited。
訂閱後依序完成：Mail Easy Switch 匯入 → Pass 匯入密碼 → Drive 上傳關鍵資料夾 → VPN 設 Kill Switch → Wallet 僅在確定要自託管 BTC 時啟用。

方案與價格（2026 官方快照）

地區與幣別：Proton 結帳僅支援 USD、EUR、CHF；台灣可用信用卡，由發卡行依當日匯率扣台幣。實際金額以登入後結帳頁為準；促銷、舊客價格可能不同。

Proton Unlimited 定價（個人）

計費週期	官方標價（USD／EUR 同數字）	說明
月繳	$12.99／€12.99 每月	彈性高、總價最貴
年繳	$119.88／€119.88 每年（約 $9.99／€9.99／月）	多數人比較的基準

官方方案說明頁與帳戶訂閱管理目前以 1 個月／12 個月 為主；VPN Plus 單獨訂閱才有常見的 24 個月選項，Unlimited 整合方案請以結帳頁顯示為準（勿假設一定有兩年約）。

與其他個人方案快速對照

方案	適合誰	你得到什麼	你沒得到什麼
Proton Free	想零成本試用	各產品免費層（Mail 1 GB、VPN 1 台／10 國、Pass 10 別名等）	VPN 串流／P2P、Mail 自訂網域、Pass 無限別名
Mail Plus	只要加密信箱	15 GB、1 網域、10 地址	VPN Plus、Pass Plus、大容量 Drive
VPN Plus	只要 VPN	完整 VPN 功能	Mail／Drive／Pass 付費層
Proton Unlimited	要整套逃離 Google 控制	上述六產品付費層 + 500 GB	Lumo Plus、Meet Professional、Proton Scribe（需 Duo／Family 或 Visionary）
Duo／Family	2～6 人家庭	每人完整付費層 + 更大共用儲存 + Proton Scribe	單人使用不划算

關鍵共用限制（Unlimited）

項目	Unlimited 上限
使用者	1 人
儲存空間	500 GB（Mail + Drive + Calendar 共用）
信箱地址	15 個
自訂網域	3 個
VPN 同時連線	10 台裝置
Pass vault	50 個
Hide-my-email	無限
Wallet	10 錢包 × 10 帳戶／錢包
附件大小	25 MB／封信

儲存滿了怎麼辦？官方會限制新郵件或上傳，需清理或升級 Duo／Family／Visionary。降級後資料通常保留，但可能無法新增內容直到低於新方案上限。

決策表：我該不該買 Proton Unlimited？

依需求選方案

你的情境	建議方案	原因
只在意旅行時 VPN 安全	VPN Plus 或先 Free	Unlimited 的 Mail／Pass 你用不到就是多付
只要 `@自己的網域` 信箱，不打算用 VPN	Mail Plus	比 Unlimited 便宜很多
已用 Proton Free，想要無限別名 + 2FA + VPN 串流	Unlimited	Pass Plus + VPN Plus 分開訂常比 Unlimited 貴
想 Gmail + Drive + 密碼 + VPN 一次搬家	Unlimited	正是整合方案設計場景
兩人要完整付費層 + 更大空間	Proton Duo	2 TB 共用、兩帳號，比買兩個 Unlimited 划算
家裡 3～6 人都要付費功能	Proton Family	6 人、3 TB 共用
只需要密碼管理 + 別名	Pass Plus 或 Pass Free	見站內 Proton Pass 免費版與付費版怎麼選
主要持有 Bitcoin 自託管	Wallet 可用 Free 先試	Unlimited 提高錢包／帳戶上限；非必買全家桶的唯一理由

依「會用到的 App 數量」粗估

你確定會長期使用的 Proton 服務數	建議
1 項（通常 VPN 或 Mail）	單買對應 Plus
2 項	結帳頁加總 vs Unlimited，取便宜的
3 項以上（含 Pass 或 Drive）	優先看 Unlimited
不確定	先用 Free 兩週，再依實際開啟的 App 決定

Unlimited 不適合誰？

只需要 VPN，且已有 Bitwarden 等密碼方案、也不打算換信箱。
儲存需求 > 500 GB 的單人使用者（考慮 Duo 或加購空間方案）。
要 Lumo AI 付費額度、Proton Scribe 寫信助理或專業會議錄影——Unlimited 只有 Lumo／Meet 免費層；Scribe 在 Duo／Family；Lumo Plus／Meet Professional 要 Visionary。
期待 Wallet 當交易所炒幣——Proton Wallet 是自託管，不是交易平台。

與單品加總的價值判斷

官方定位是：Unlimited 年繳約 $9.99／月，包含 Mail Plus、VPN Plus、Pass Plus、Drive Plus、Calendar 付費功能。

自行估算時：

打開 pricing 頁，分別看 Mail Plus、VPN Plus（年繳）價格。
Pass Plus 若單獨販售，一併加入。
若 兩項以上年繳加總 > Unlimited 年繳，買 Unlimited 較合理。
別忘了 500 GB 與 Proton Sentinel 是 Unlimited 額外值，單買 Mail Plus 只有 15 GB。

產品	適合誰	說明
Proton Unlimited（主推）	想 Mail + Pass + VPN + Drive 一次逃離 Google 控制	年繳約 $9.99／月；比單品加總通常更省
Proton VPN Plus	只需要 VPN 完整功能	別為了 VPN 買全家桶
Proton Mail Plus	只要加密信箱 + 自訂網域	比 Unlimited 便宜很多
Proton Pass	只要密碼管理 + Hide-my-email	可搭配站內 Pass 評測文
Proton Free	還不確定、想先試兩週	零成本建立信任，再依實際開啟的 App 升級

結語

Proton Unlimited 值得買嗎？——若你確定會長期用 三項以上 Proton 服務（尤其是 Mail + Pass + VPN 的逃離 Google 控制組合），通常比單品加總划算。若你只是「偶爾旅行開 VPN」，Unlimited 就像買了六人份套餐自己吃——飽是飽了，錢包也瘦了。

三個重點帶走：

Unlimited 是生態系整合方案，不是「加強版 VPN」——先盤點你會用到幾個 App。
500 GB 是 Mail + Drive + Calendar 共用池，大檔案使用者要事先估算。
結帳前到官網比價，幣別、促銷、舊客價格都可能讓結論翻盤。

若你確認需要全家桶，建議先到 Proton 官網領免費帳號 → 實際開幾個 App 試兩週 → 再決定升級 Unlimited 或單買 Plus。遷移完成再來一杯咖啡慶祝——這次沒有 Google 讀你的訂單確認信。

聯盟揭露： 本文包含 Proton 推薦連結。若你透過連結註冊或購買，我可能獲得推薦回饋；這不會增加你的費用。本文依研究筆記與官方文件撰寫，請依你的實際需求與測試結果做最終決定。

👉 免費申請 Proton 帳號 →

參考資料

Proton plans explained（官方方案總覽） — 各產品方案層級與功能對照。
Proton Pricing Plans — 結帳時的方案、幣別與促銷價格（以當日頁面為準）。
Proton Pass plans explained — Pass 免費版與付費版上限。
Proton Wallet 產品頁 — 自託管 Bitcoin 錢包功能說明。
How to manage your Proton subscription — 訂閱管理、升級與降級。
All you need to know about Proton Unlimited（官方部落格） — Unlimited 整合方案官方說明。

Proton Pass 值得用嗎？2026 免費版、Plus 與 Unlimited 怎麼選

2026-08-12T02:19:01Z

你是不是也這樣：Chrome 跳出「要儲存密碼嗎？」，手比腦子快，按了「是」。幾年下來，幾百組帳密全躺在 Google 帳號裡，安靜得像沒發生過事。

直到某天看到外洩新聞，你才突然想起一件小事——這本熟客本，到底鎖在誰家倉庫？

Chrome 記密碼很像店裡的熟客本：你點什麼它都記得。問題是這本筆記本跟 Gmail、雲端硬碟、YouTube 觀看紀錄，常常塞在同一間倉庫。倉庫鑰匙丟了，損失的就不只是一杯美式。

瀏覽器內建密碼管理器「免費又順手」，但你的憑證通常跟大帳號綁在一起：管轄法律、元資料、匯出時的明文 CSV，都是獨立密碼庫想處理的事。若你本來就信任 Proton——例如已經用過 Proton VPN 免費版——Proton Pass 是很自然的下一步。而且免費版已經比多數人想像中完整，不是那種「只能存 50 組密碼、用三天就開始推升級」的試用關卡。

這篇讀完，你會知道：免費版能幹嘛、什麼時候該付費，以及買整套 Proton Unlimited 跟只買 Pass Plus 差在哪。目標很單純——選對方案，而不是被「買最貴才最安全」推著走。

Chrome 密碼管理器夠用嗎？什麼時候該換？

先講白話：Chrome（Google Password Manager）不是不能用，而是方便換來綁定。

情境	建議
帳號不到 20 組、只有娛樂網站	可繼續用，但請開啟 Google 兩步驟驗證
已全套 Apple、只用自己的裝置	iCloud 鑰匙圈體驗佳；重要金融帳號仍建議加硬體金鑰
帳密破百、想減少 Google 掌控	規劃遷移到獨立密碼庫
接案、客戶資料多	獨立金庫＋分 vault，勿跟私人 Chrome 混用

獨立密碼庫多一層：主密碼（再加可選的第二因素）跟 Gmail 登入分開。從 Chrome 匯出密碼時會得到未加密 CSV——這是搬家必經之路，也是風險最高的一刻。把明文密碼檔丟在桌面或同步雲端，等於把家門鑰匙影印後貼在信箱上，還寫「有事請自取」。

所以換工具要一次做對。若你已經在考慮 Proton 生態（Mail、VPN、Drive），Pass 是 De-Googling 拼圖裡門檻最低的一塊：註冊免費帳號就能開始，不必先買最高方案。

Proton Pass 免費版：其實已經很完整

很多人以為「免費密碼管理器 = 只能存幾十組密碼」。依 Proton 官方方案說明，Proton Pass Free 這些項目是不限數量的：

登入資料、筆記、信用卡與身分資料
裝置數量（手機、電腦都能裝）
Passkey（無密碼登入）
10 個 Hide-my-email 信箱別名（轉寄到你真正信箱的隨機地址）

免費版的明確上限也要記清楚，免得用了一陣子才發現卡關：

項目	免費版限制
Hide-my-email 別名	最多 10 個
內建 2FA（TOTP）	最多 3 個項目會顯示驗證碼（依建立日期，最早的三筆）
暗網監控、緊急存取、進階共享	❌ 需付費
自訂網域別名	❌ 需付費

常見誤解順便澄清：免費版可以用 Passkey。付費版主要差在別名數量、完整 2FA、共享與監控，不是「免費版只能當記事本」。AI 若跟你說免費版不能用 Passkey，你可以請它先去讀官方方案頁——這杯咖啡它白喝了。

三種方案怎麼選？一張決策表搞定

你的情境	建議方案	原因
跨手機、電腦存密碼與 Passkey，別名不超過 10 個	Proton Pass Free	登入與裝置不限，夠你起步
每個網站都想用不同別名，或需要內建 TOTP	Proton Pass Plus	不限別名與 2FA，另有共享、暗網監控等
還需要 Proton VPN Plus、Mail、Drive	Proton Unlimited	Pass Plus 功能包在套裝裡；價值在多服務一起用
要家人共用、不是單人帳號	先看 Pass Family	家庭方案重點在多使用者，不是單帳戶加容量

付費前的三個自問

別名夠用嗎？ 只是偶爾註冊試用，10 個可能夠；想「一個網站一個信箱」，Plus 的不限量才是實質升級理由。
2FA 放哪裡？ Pass Plus 內建 TOTP 很方便，但 Proton 官方寫得很清楚：不要用 Proton Pass 的 TOTP 保護 Proton 帳號本身——Proton 登入請用第三方驗證器。白話說：別把備用鑰匙藏在同一扇門的門墊底下。
要不要整套生態？ 若你只需要密碼管理，先比 Pass Plus 就好；若本來就要 VPN、加密郵件和雲端，再把 Unlimited 整包納入計算。

價格提醒： Proton Pass 官網價格會因地區、稅金與促銷變動，結帳前請以 Proton Pass 官方方案頁為準。官網也標示 Pass 付費方案有 30 天退款保證。粗略參考：同類產品裡 Bitwarden Premium 年繳約 US$19.80、1Password 個人年繳約 US$35.88（官網折合月價；新客首年可能有促銷）——Proton 的賣點常是別名 + 瑞士管轄 + 跟 Mail／VPN 打包，不是單純比誰最便宜。

Free vs Plus vs Unlimited 功能對照

功能	Free	Pass Plus	Proton Unlimited
無限密碼與裝置	✅	✅	✅
Passkey	✅	✅	✅
Hide-my-email 別名	10 個	不限	不限
內建 2FA（TOTP）	最多 3 個項目	完整	完整
暗網監控、緊急存取	❌	✅	✅
自訂網域別名	❌	✅	✅
Proton VPN／Mail／Drive 付費功能	❌	❌	✅（套裝）

Unlimited 不是「Pass 的高級版」——它是把 Mail、VPN、Drive、Calendar 等付費功能綁在一起。你若不用其他 Proton 服務，不必為了名稱升級。這很像點了全家桶，卻只吃裡面那包薯條。

若你已經訂了 Proton VPN 付費版，可以對照先前的 Proton VPN 評測文：VPN 解決的是連線加密與 IP 隱私；Pass 解決的是帳密與信箱別名。兩者互補，不是二選一。

Hide-my-email：免費版最被低估的功能

Hide-my-email 會產生一個轉寄到你主信箱的隨機地址。網站只看到別名，看不到你的 Gmail 或 Proton Mail 本體。某個服務外洩或開始狂發廣告時，你可以只停掉那個別名，不必換掉用了十年的主信箱。

這比每次外洩都改一次 email 優雅多了。後者比較像每次咖啡灑出來，就換一張桌子。

實用習慣：

情境	做法
網購、優惠、免費試用	每個服務一個別名 + 唯一密碼
銀行、政府、重要帳戶	可用別名，但別名不能取代身分驗證
不再使用的服務	先停用別名觀察；確認帳戶已關閉再永久刪除

桌面瀏覽器：在註冊頁的 email 欄位點 Proton Pass 圖示 → 選 Hide my email，同時產生隨機密碼並儲存。手機上 Android／iOS 也能在自動填入流程裡建立別名。

免費版 10 個別名用完，就是考慮 Pass Plus 的明確訊號之一。不是「突然變貴」，而是你的使用方式已經超過免費版設計的範圍。

從 Chrome 搬過來要多久？大約 15–30 分鐘

決定用 Proton Pass 之後，遷移核心三步驟（官方支援頁也是這條路）：

Chrome 匯出 CSV（Google Password Manager → 設定 → 匯出）
Proton Pass 擴充功能匯入（Import → Provider 選 Chrome）
立刻刪除 CSV 並清空垃圾桶——這是明文檔，誰拿到誰就能登入你的帳號

匯入後建議：

抽 3–5 個重要網站測試自動填入
在 Chrome 關閉「儲存密碼」與「自動登入」，避免新密碼又寫回 Google
確認無誤後，可依官方步驟在 Google Password Manager 用 Delete Data 清掉舊庫
手機把自動填入預設改成 Proton Pass

項目	能否一次搬完
一般帳密	✅ CSV 匯入
Passkey	❌ 需在各網站重新建立
Chrome 內建 2FA	❌ 通常要在 Pass Plus 用 TOTP 掃 QR 重建

遷移本身不限筆數，免費版就夠用。要無限別名或暗網監控，再考慮升級。Passkey 帶不走這件事，有點像搬家時發現保險箱焊在舊牆上——密碼可以裝箱，鑰匙孔得在新家重做。

跟 Bitwarden、1Password 比，Proton Pass 適合誰？

若你還沒鎖定品牌，可以用這張表快速縮小範圍（價格為 2026-08 官網美元參考，不含稅；結帳前請回各官網確認）：

方案	免費版	個人付費參考	適合誰
Bitwarden	有；不限登入與裝置	Premium 約 US$19.80/年	要最便宜、可自架、開源生態
1Password	僅 14 天試用	Individual 年繳約 US$35.88	最在意跨平台 autofill 順手度
Proton Pass	有；10 個別名 + Passkey	Pass Plus 依官網顯示	在意隱私、瑞士管轄、已用或打算用 Proton 生態

你的情境	先看哪個
已用 Proton Mail 或 VPN	Proton Pass 或 Unlimited 套裝
全家 Apple、帳號不多	Apple Passwords 可能已夠用
要脫離 Google、又要信箱別名	Proton Pass Free 先試

Proton Pass 的差異化不在「介面最花俏」，而在 Hide-my-email 跟密碼庫同一個 app，以及跟 Proton 其他服務打包時的整體性價比。花俏介面很好看，但不能幫你在購物網站外洩後只關掉一個信箱入口。

工具	適合誰	說明
Proton Pass（主推）	想離開 Chrome 密碼庫、在意隱私的一般使用者	免費版無限密碼 + 10 個別名；夠用再升 Plus 或 Unlimited
Proton Unlimited	已確定要 Mail + VPN + Pass 全套	單項加總通常比分開訂閱划算；見官方方案頁比價
Bitwarden	預算優先、或需要自架	客觀替代方案；免費版功能扎實
1Password	家庭共享、最在意 UX	較貴但體驗公認好；無永久免費版

結語：先免費試，再依需求升級

整理三點帶走：

Proton Pass 免費版已經夠大多數人起步——無限密碼、Passkey、10 個信箱別名，不是閹割版試用。
升級 Plus 的真正理由通常是不限別名、完整 2FA、暗網監控與共享——不是「多存幾組密碼」。
Unlimited 是生態系套裝——若你同時需要 VPN 與加密郵件，再一起算帳；若只要密碼管理，不必為名稱多付。

下一步： 到 Proton Pass 官網註冊免費帳號 → 安裝瀏覽器擴充功能 → 匯入 Chrome 密碼 → 為新註冊的網站開一個 Hide-my-email 別名試試看。用一兩週後，再對照本文決策表判斷要不要升級 Plus 或 Unlimited。

沒有一杯咖啡解決不了的密碼焦慮；如果有，就先把金庫從瀏覽器搬出來——然後記得，CSV 刪掉再喝下一杯。

聯盟揭露： 本文包含 Proton Pass 推薦連結。若你透過連結註冊或購買，我可能獲得推薦回饋；這不會增加你的費用。本文依研究筆記與官方文件撰寫，請依你的實際需求與官方當下方案頁做最終決定。

👉 免費申請 Proton Pass 帳號 →

參考資料

Proton Pass plans explained — 官方整理 Free、Pass Plus、Pass Family 與 Unlimited 的功能差異，含免費版 10 個別名與最多 3 個 2FA 項目。
Proton Pass Pricing & Plans — 依地區與計費週期顯示的方案價格、功能對照與 30 天退款說明。
How to use 2FA in Proton Pass — 內建 TOTP 設定方式，以及「不要用 Proton Pass 保護 Proton 帳號本身」的官方提醒。
How to import to Proton Pass from Chrome — 從 Google Password Manager 匯出 CSV、匯入 Pass，以及刪除 Chrome 舊資料的步驟。
Hide-my-email aliases — 別名的建立、轉寄與停用說明。
Bitwarden Pricing — Bitwarden Premium 年繳美元參考價。
1Password Personal Pricing — 1Password Individual 方案與試用說明。

技術部落格怎麼留住讀者？版面、選單與頁面的設計筆記

2026-08-12T00:54:00Z

沒有一杯咖啡解決不了的「讀完就關掉」；如果有，通常不是再加一個漂浮動畫，而是讀者找不到下一杯該喝什麼。

技術部落格很容易變成這樣：文章一篇一篇寫得很認真，首頁卻像自助餐櫃——盤子很多，不知道先拿哪一道。訪客從搜尋引擎進來，讀完一篇，滑到底只看到「上一篇／下一篇」兩個跟主題無關的標題，然後就回去 Google 了。網站沒壞，只是沒有把人留下來的理由。

這篇是給以文章為主的技術筆記站的設計筆記：分類清楚、有搜尋、效能也顧了的那種。重點不是改成電商或社群產品，而是讓訪客更容易做到三件事——找到適合自己的內容、連續讀下一篇、下次還想回來。

讀完你會帶走：主選單怎麼收、首頁怎麼排、文章頁結尾該放什麼，以及先做哪幾項就夠。

先講結論：留存靠「下一篇」，不靠裝飾

對這種網站，留存率的核心不是把版面做得更花，而是讓人更容易點到下一篇有用的文章。

你可以把它想成咖啡店動線：客人不是要看完整菜單背起來，而是想被帶到「下一杯也適合他的」。選單、首頁、分類頁、文章結尾，都該服務這條動線：

搜尋進來的一篇文章
→ 相關文章或學習路線
→ 同一主題再讀一篇
→ RSS／回訪理由

許多技術站已經把基礎做齊：最新文章 Hero、分類區塊、站內搜尋、RSS、文章目錄、上一篇／下一篇。接下來常見的瓶頸不是「再多一個區塊」，而是內容導覽——讓單篇文章連成一條路。

Nielsen Norman Group 對網頁停留的研究也呼應這點：使用者常在前 10–20 秒就決定要不要留下來；頁面若能很快說清楚「這裡有什麼、為什麼值得看」，才比較可能換成幾分鐘的閱讀。技術站的首頁與文章開頭，都該在這段時間內把價值講明白，而不是先秀一排看不出差異的卡片。

主選單：4～5 個入口就夠

選單不是把全站分類平鋪出來。分類是內容管理方式；選單是幫讀者完成目標。

建議控制在這些入口：

入口	它回答的問題	不要做成什麼
首頁	這站是誰、適合我嗎	只有最新一篇、沒有定位
學習路線	我想系統學會一件事，從哪開始	另一份文章清單
文章	我想逛最新或全部文章	跟首頁重複到分不清
分類	我想依主題瀏覽	只有分類名稱、沒有介紹
關於	作者是誰、為什麼該信這站	履歷全文

搜尋與深色模式放工具列就好，不必再佔一個選單字。桌面版選單維持可見；手機版若項目超過約四個，再收進漢堡選單——但 Logo、搜尋仍應留在首屏。NN/g 的研究很直白：隱藏導覽會降低內容被找到的機會；桌面有空間就不要藏，手機才是空間不夠時的取捨。

「分類」和「學習路線」不要混成同一個東西：

分類：這篇文章屬於後端、前端、效能、工具……方便過濾。
學習路線：為了完成一個目標，建議依序讀哪幾篇。例如「從零架站」「效能調校」「某語言入門」。

後者才比較容易讓人連續點下去。功能清單式的分類牆，看起來很完整，卻很少幫人決定「下一篇讀哪篇」。

首頁：先說清楚網站定位

不少技術站的首頁會採類似排法：最新文章，接著一串精選分類。方向通常沒錯，但區塊一多，看起來就容易像目錄，不像入口。

較乾淨的順序是：

網站定位與主要行動
↓
最新文章
↓
熱門學習路線（3 條就夠）
↓
熱門／推薦文章
↓
RSS 訂閱

Hero 不要只放最新一篇。新訪客需要先知道「這個網站適合誰」。例如：

給想系統學某項技術、或把實戰經驗整理成筆記的開發者。
分享教學、工具比較與架站實作。

再配兩個清楚的按鈕：「開始學習」「瀏覽最新文章」。Nielsen Norman Group（尼爾森諾曼集團）把首頁的工作講得很白：要在短時間內強調網站獨特的價值，連結文字也要有資訊氣味——「閱讀全文 →」不如「開始這條效能優化路線」具體。

最新文章區塊可以保留大圖 Hero，但補上這些判斷資訊：

發布或更新日期
預估閱讀時間
文章類型（教學、比較、實戰）
明確的閱讀行動

首頁主題區塊建議只留 3～4 個，其餘用「查看全部」進專題頁。精選區若每欄都長得一樣，大腦會把它當成同一道菜，連續點下去的意願會掉。

文章卡片：讓人 3 秒判斷值不值得點

常見的卡片已有圖片、標題、摘要、分類，但還差決策資訊。建議固定露出：

分類 · 2026-08-12 · 8 分鐘閱讀

閱讀時間可以用正文字數估算，不必人工維護；它不是科學實驗，只是讓讀者知道這杯咖啡大概要喝多久。一篇文章若同時屬於兩個相關分類，卡片上最多留兩個，比只露第一個更有幫助。

日期、閱讀時間、類型放在底部對齊，卡片才比較好比。缺這些時，訪客只能靠標題賭，賭輸就關掉——這不是文章不好，是菜單沒標熱量。

文章頁：結尾比開頭更決定會不會留下

文章開頭維持清楚即可：分類、標題、一句話摘要、更新日期、閱讀時間。長文若有目錄，這件事通常已經先做對。

真正容易漏的是結尾。只放「上一篇／下一篇」時，排序是時間，不是主題。讀者剛讀完 PageSpeed 優化，下一篇卻可能是 VPN 評測——這比較像咖啡喝完店員推薦隔桌的三明治，不是同一產區的下一杯。

結尾比較有效的是：

接下來可以閱讀
1. 同分類或同標籤的相關文章 A
2. 相關文章 B
3. 這個主題的學習路線

相關文章優先依分類、標籤或人工指定，時間序當備案。若是系列文，直接標「第 2／6 篇」——這比任何動畫都更像「請繼續喝」。

回訪入口也放這裡，但不要彈窗攔截。RSS 一句話就夠：

這篇若有幫到你，可用 RSS 訂閱同主題的新文章。

電子報可以之後再加；一開始就跳窗要 Email，留存還沒開始，信任先扣分。

分類頁：不要只剩一排名字

只有分類名稱的頁面，比較像資料庫索引，不像入口。每個分類頁至少補這些：

這分類在講什麼、適合誰
文章數量
建議閱讀順序（3～5 篇）
最新文章列表

例如某個「靜態網站」分類可以寫成：

靜態網站建站
適合想建立快速、低維護成本網站的開發者。

建議閱讀順序：
1. 什麼是靜態網站
2. 選型與基礎設定
3. 加入站內搜尋
4. 進行效能優化

這樣分類頁才會從「標籤牆」變成「從這裡開始」。一篇文章放進多個分類沒關係——同一個內容用不同入口找到，本來就比較符合讀者的腦內分類，只是每個入口都要講清楚自己的用途。

行動版：首屏不要被選單擠爆

窄螢幕上 Header 若直接換行把所有連結攤開，首屏會先被導覽吃掉。比較穩的做法：

Logo、搜尋、主題切換留著
其餘收進選單
選單裡放「學習路線」，不要把所有分類平鋪

漢堡選單是手機的妥協，不是桌面的時尚。重點頁（最新文章、某條學習路線）仍應在首頁或文章結尾用一般連結露出，不要假設大家都願意先點那個三條線。

先做這五件，再談收藏與電子報

不必一次改完。建議分三輪，而且先做能接到「下一篇」的。

第一輪：導覽

卡片加上日期與閱讀時間
文章結尾改放相關文章，而不是只靠時間序
整理 3～5 條學習路線
分類頁加上介紹與建議順序
行動版收合選單

第二輪：回訪理由

RSS 放進文章結尾、標出經典或近期更新文章、系列文標「第 N／M 篇」。收藏或稍後閱讀可以更晚再做——沒有「下一篇」時，收藏只是把迷路延後。

第三輪：用數據看哪條路有走通

若已接上 GA4 或類似分析工具，不要只看停留時間：技術文章常會切分頁複製程式碼，前景時間會被低估。比較值得看的是：

想知道什麼	比較有用的訊號
首頁有沒有把人送進文章	首頁到文章的點擊
讀完後有沒有留下	文章結尾相關連結的點擊
搜尋有沒有在幫忙	搜尋使用次數
分類頁是不是死路	分類頁再進入文章的比例
有沒有人回來	7 日／30 日回訪使用者

GA4 把「engaged session」定義成：停留超過約 10 秒、有關鍵事件，或至少兩個頁面瀏覽。對技術站來說，「讀完後是否點下一篇」通常比單頁停留秒數更接近真實留存。改完一輪就看同一組指標，才知道是相關文章有效，還是只是當週剛好有一篇爆文。

結語：菜單可以短，路線要清楚

技術部落格不難看，難的是讓人看完還想再看。版面、選單、頁面都該服務同一件事：把「剛好讀到一篇」變成「沿著一條路再讀一篇」。

帶走三點就夠：

選單短、路線清楚：分類負責管理，學習路線負責帶路。
首頁先自我介紹，再推最新文：10 秒內講完網站適合誰。
文章結尾是留存開關：相關文章與系列順序，比上一篇／下一篇更接近讀者要的下一杯。

先改結尾的相關文章通常最划算——不用重做整個首頁，就能讓已經在讀的人多點一次。改完再來一杯。下一杯建議：挑一篇流量高的文章，看它滑到底之後，下一篇是不是真的相關。

參考資料

How Long Do Users Stay on Web Pages?（NN/g） — 說明前 10–20 秒的去留判斷，以及為何要在短時間內講清價值
Homepage Design: 5 Fundamental Principles（NN/g） — 首頁要強調獨特價值、連結要有資訊氣味
Menu-Design Checklist: 17 UX Guidelines（NN/g） — 選單應協助定位；桌面不宜無故隱藏導覽
Hamburger Menus and Hidden Navigation Hurt UX Metrics（NN/g） — 隱藏導覽會降低可發現性；手機才較常需要這個取捨
Top 10 Information Architecture (IA) Mistakes（NN/g） — 結構、導覽與搜尋要互相支援，並標示使用者目前在哪
GA4 Engagement rate and bounce rate（Google Analytics Help） — engaged session 的官方定義，適合作為留存觀察的起點

VPN 跟 HTTPS 差在哪？兩者的保護範圍怎麼比？

2026-08-10T06:12:00Z

咖啡店連上 Wi-Fi，網址列出現鎖頭，很多人就以為「這台手機已經安全了」——鎖頭很可愛，但它只管你和某一個網站之間的傳輸，不是整台手機的保護罩。也有人聽說 VPN 很神，開了以為能防釣魚、防病毒；結果在假網站輸入密碼，VPN 還是會很盡責地把資料加密送到那個假網站。唉。

其實 HTTPS 和 VPN 保護的是不同層次：HTTPS 通常由網站和瀏覽器自動協商，保護你和「某個網站」之間的內容；VPN 則是使用者可以選擇啟用，保護裝置到 VPN 伺服器之間的連線。搞懂差異，你才能判斷：哪些情境只要確認 HTTPS 就夠，哪些情境在公共 Wi-Fi 上應該再開 VPN。

一句話記住：兩者保護的範圍不同

	HTTPS	VPN
誰決定是否使用	網站與瀏覽器自動協商；使用者不能把普通 HTTP 網站「開成」HTTPS	使用者自行安裝、連線與關閉
保護對象	你和某一個網站之間的連線	你的裝置到 VPN 伺服器之間的整段流量
主要功能	加密內容、防止竄改、驗證網站身分	把本地網路／ISP 能看到的活動藏起來，換成 VPN 業者成為信任對象
典型比喻	寄信時用密封信封，只有收信人能打開	整條路都走加密隧道，路邊的人較難看你去了哪裡
不能做的事	不能證明網站不是假的；不保護其他 App 流量	不能防釣魚、不能防病毒；目的地若沒 HTTPS 仍可能明文

記這四句就夠（比背 VPN 協定名稱實用多了）：

網站支援 HTTPS：瀏覽器通常會自動使用；你要做的是確認網址是 https:// 且網域正確。
沒有 HTTPS：公共 Wi-Fi 上的其他人可能看到或修改你與網站交換的內容；不要登入或輸入敏感資料。
有 HTTPS、沒有 VPN：內容通常受保護，但本地網路仍可能知道你連到哪些網域。
有 VPN、沒有 HTTPS：裝置到 VPN 這一段受保護，但網站端與 VPN 業者仍是信任問題。
兩者都有：公共 Wi-Fi 上較完整的組合——確認 HTTPS 的同時開啟可信任 VPN；但仍不能取代防詐、更新、強密碼與 MFA。

HTTPS 保護什麼？鎖頭代表什麼？

HTTPS 是 HTTP 加上 TLS 加密。依 Mozilla 等官方說明，它主要做三件事：

加密：傳輸中的資料不容易被旁觀者讀取。
完整性：攻擊者不能在途中悄悄改內容而不被發現。
伺服器驗證：瀏覽器透過憑證確認自己連到的是宣稱的網域。

所以在沒有 HTTPS 的網站上（網址仍是 http://），公共 Wi-Fi 上的其他人可能看到帳號、密碼或表單內容，也可能改頁面。千萬不要在 HTTP 網站輸入信用卡或登入資料——那就像用透明信封寄密碼，鎖頭還沒上場。

但 HTTPS 不是整台裝置的加密罩：

它通常只保護瀏覽器與特定網站之間的連線，不會自動保護其他 App。
網路觀察者通常仍可能知道你連到哪個網域、連線時間與流量大小；不一定能看到具體頁面內容。
有 HTTPS 不代表網站可信。假網站也可能申請有效憑證——鎖頭只代表傳輸加密，不代表這家公司是真的（證書不會幫你審核商業道德）。
若頁面載入未加密的圖片、腳本等混合內容，整體安全性可能被削弱。

現代網站大多已強制 HTTPS，Google 也把它當 SEO 因素；Chrome 會把純 HTTP 標成「不安全」。對站長來說，HTTPS 是建站基本功；對一般使用者來說，重點不是「開 HTTPS」，而是：敏感操作前確認網址是 https://，並核對網域拼字——g00gle.com 有鎖頭也沒用。若網站只提供 http://，使用者無法靠設定把它變成安全的 HTTPS；應離開網站。

VPN 補上哪一塊？為什麼 HTTPS 夠了還有人開 VPN？

VPN 會在裝置與 VPN 伺服器之間建立加密通道。對公共 Wi-Fi 業者或 ISP 而言，較難直接看到你通道內的瀏覽目的地；網站看到的來源 IP 也通常會變成 VPN 伺服器的 IP。

VPN 比較適合這些情境：

你不信任目前的網路（旅館、機場、咖啡店 Wi-Fi）。
你不希望本地網路業者直接看到你的瀏覽網域或 DNS 查詢。
你需要連回公司或家中的私有網路。

但 VPN 不是匿名按鈕，也不是防毒軟體：

VPN 業者本身成為新的信任對象，可能看見部分連線資訊；挑選時要查隱私政策、商業模式與獨立稽核。
VPN 不會阻止釣魚網站、惡意下載、Cookie、帳號登入或裝置指紋追蹤。
若目的地網站沒有 HTTPS，VPN 伺服器到網站之間的內容仍可能沒有端對端保護。
連線中斷、設定錯誤或未更新時，保護效果可能不如預期。

EFF 在 2026 年更新的 VPN 指南也提醒：VPN 主要是在保護網路中繼資料（例如你連了哪些網域），以及把信任從 ISP／本地網路轉移到 VPN 業者。HTTPS 管你和網站之間的內容，VPN 管裝置到伺服器之間的通道——在咖啡店、機場、飯店這類公共 Wi-Fi 上，兩者搭配是合理的習慣。

情境決策表：我現在要做的事，需要 VPN 嗎？

把「內容、網域、整台裝置流量」分開想，就不會把 HTTPS 和 VPN 當成同一個開關，也不會在查地圖時為了 HTTPS 反覆找不存在的設定。

公共 Wi-Fi 常見情境

情境	HTTPS 要確認什麼	沒有 VPN 的限制	較實際的做法
咖啡店登入銀行或信箱	確認網址、網域與官方 App；HTTPS 由瀏覽器自動協商	Wi-Fi 業者仍可能看到你連到哪些網域	確認 HTTPS 並開啟可信任 VPN
在家瀏覽一般 HTTPS 網站	確認網址是 `https://`；不要把鎖頭當成網站真實性證明	ISP 通常仍能看到網域；網站也能用 Cookie 辨識你	HTTPS 通常已足夠；需要隱私時用 VPN，並保持系統更新

我要做什麼 → 怎麼連線（一頁帶走）

我要做什麼	建議連線方式	VPN
看新聞、查地圖	公共 Wi-Fi；確認 HTTPS	可選
機場查航班	公共 Wi-Fi；確認 HTTPS	可選
飯店 Wi-Fi 看 YouTube	飯店 Wi-Fi + VPN；確認 HTTPS	可選
登入信箱、社群	公共 Wi-Fi + VPN；確認 HTTPS 與網域	✅ 建議
咖啡廳寄信	咖啡廳 Wi-Fi + VPN；確認 HTTPS 與網域	✅ 建議
登入銀行 App	公共 Wi-Fi + VPN；使用官方 App 或確認 HTTPS	✅ 建議
網銀轉帳	公共 Wi-Fi + VPN；使用官方 App 或確認 HTTPS	✅ 建議

只有 HTTPS 夠嗎？快速對照

只做這件事	HTTPS 怎麼處理	VPN（公共 Wi-Fi 上）
看新聞、查地圖	確認 `https://`；通常由瀏覽器自動使用	可選
登入信箱、社群	確認 `https://` 與正確網域	✅ 建議
網銀、購物、公司系統	HTTPS 必須存在，並確認網域或官方 App	✅ 建議

Q：公共 Wi-Fi 上需要 VPN 嗎？HTTPS 夠不夠？

短答：這不是二選一。HTTPS 保護你和網站之間的內容，網站支援時瀏覽器會自動使用，你要做的是確認網址與網域正確。VPN 保護裝置到 VPN 伺服器之間的整段流量，在公共 Wi-Fi（咖啡店、機場、飯店）上建議開啟，與 HTTPS 搭配使用。

HTTPS 保護你和正確網站之間的傳輸內容；但它不能證明你連的是真網站，也不能完全隱藏網域、連線時間與流量模式。VPN 可以減少本地網路直接看到這些資訊，但會把部分信任轉移給 VPN 業者。兩者保護範圍不同，在公共 Wi-Fi 上應該一起用，而不是只依賴鎖頭。

常見誤解：別把鎖頭或 VPN 當萬能藥

「有鎖頭就安全」 — 假網站也可能有 HTTPS；要看網域是否正確，必要時用書籤或官方 App。
「開了 VPN 就不會被駭」 — VPN 不防釣魚；你若在仿冒 HTTPS 網站輸入密碼，VPN 仍會把資料加密送到那個假網站（加密很盡責，方向錯了）。
「飯店 Wi-Fi 有密碼就安全」 — 密碼通常只防路過的人；同飯店其他住客或被入侵的路由器仍有風險。連上後應開啟可信任 VPN，並確認 HTTPS 與網域。
「VPN 可以取代防毒、MFA、更新」 — 不能。完整防線還需要強密碼、多因素驗證、系統與瀏覽器更新。

三分鐘安全檢查清單

出門連陌生 Wi-Fi 前，照這六步做（比多下載三個「Wi-Fi 加速器」實用）：

先確認網路名稱：向店家或櫃檯確認 SSID，不要只選訊號最強的同名網路。
先看網址：敏感操作前確認是 https://，不要因為有鎖頭就忽略網域拼字。
連上公共 Wi-Fi 先開 VPN：咖啡店、機場、飯店等陌生網路，確認 HTTPS 的同時啟用可信任 VPN。
選可信任的 VPN 服務：查隱私政策、商業模式與獨立稽核；建議開啟 Kill Switch。
關閉自動連線與檔案分享：公共網路上關閉自動加入 Wi-Fi、AirDrop／檔案分享等不需要的功能。
補上其他防線：更新系統與瀏覽器、使用獨立強密碼、開啟 MFA，並保留裝置防毒與備份。

工具	適合誰	說明
Proton VPN（主推）	常在公共 Wi-Fi、旅行、需要免費入門的人	免費版已有 Kill Switch、無日誌政策與不限流量；連上咖啡店、機場 Wi-Fi 時建議先開。付費版解鎖更多國家、串流與進階功能。
密碼管理器 + MFA	所有有帳號的人	VPN 與 HTTPS 都不防帳號被盜；強密碼與驗證器 App 是基本配。

結語：先搞懂保護範圍，再決定要不要開 VPN

HTTPS 和 VPN 不是同一個開關，而是保護範圍不同的工具：

HTTPS 通常由網站與瀏覽器自動協商，保護你和網站之間的內容有沒有被看見、被改掉。
VPN 由使用者選擇啟用，減少本地網路／ISP 直接知道你連到哪些網域，但新增 VPN 業者這個信任對象。

看地圖、刷新聞，在公共 Wi-Fi 上確認 HTTPS 並開啟 VPN；登入信箱、網銀或在飯店 Wi-Fi 上工作，同樣建議 HTTPS + 可信任 VPN 一起用。VPN 不能取代防釣魚與 MFA，但能補上 HTTPS 管不到的網路通道保護。

若你常在咖啡店、機場或旅館上網，可以先從 Proton VPN 免費版試起——在家連一次、開好 Kill Switch，下次連公共 Wi-Fi 就知道該怎麼搭配 HTTPS 使用。沒有一杯咖啡解決不了的網路焦慮；如果有，就加一層 VPN——然後記得，咖啡還是要自己付。

聯盟揭露： 本文包含 Proton VPN 推薦連結。如果你透過連結註冊或購買，我可能獲得推薦回饋；這不會增加你的費用。

👉 免費申請 Proton VPN 帳號 →

參考資料

Mozilla MDN：Transport Layer Security (TLS) — TLS 的加密、完整性、驗證與混合內容說明。
EFF Surveillance Self-Defense：Choosing the VPN That's Right for You — VPN 用途、限制、信任轉移與選擇準則。
CISA：Securing Wireless Networks — 公共 Wi-Fi、假基地台與流量監聽風險。
FTC：Are Public Wi-Fi Networks Safe? — 公共 Wi-Fi、HTTPS 與假網站提醒。
Proton VPN：Why you need VPN to stay safe on public WiFi — DNS 查詢、公共 Wi-Fi 與 VPN 的差異說明。

Proton VPN 付費版評價（2026）：VPN Plus 值得訂閱嗎？

2026-08-10T05:18:00Z

你已經用 Proton VPN 免費版一陣子了——不限流量、沒廣告，在咖啡店連公共 Wi‑Fi 還算安心。結果一到尖峰時段，影片轉圈圈、不能自己選國家、串流跟 BT 下載通通說再見，你就會開始想：付費版到底值不值得？還是免費版已經夠我這杯咖啡的預算？

這篇不談「VPN 是什麼」（那篇留給入門文），專攻 VPN Plus 付費版評價：速度差多少、哪些功能只有付費才有、跟 NordVPN、Surfshark 比怎麼選，以及訂閱前該確認的價格與退款條件。若你想先看免費版全貌，可搭配站內另一篇 Proton VPN 值得買嗎？免費版與付費版功能完整解析。

先講結論：付費版適合誰？

你的情境	建議	原因
只在咖啡店偶爾上網、1 台裝置就夠	先維持免費版	免費版已有 Kill Switch、無日誌、不限流量；付費的串流／選國家你用不到
想看 Netflix、Disney+ 等地區片庫	VPN Plus	官方串流支援僅限付費方案；免費版不包含
需要 BT／P2P 下載	VPN Plus	免費版不支援 P2P；Plus 有專用高速伺服器
家中 2–10 台裝置同時連線	VPN Plus	最多 10 個同時連線（每個使用中的瀏覽器擴充也算 1 個）
重視可驗證的隱私證據，偶爾需要 Secure Core	VPN Plus	Secure Core、NetShield、Stealth 混淆協定都是付費功能
同時需要 Proton Mail、Drive、Pass	Proton Unlimited	別只用 VPN 月費比；把整個生態系需求一起算
家中超過 10 台裝置常同時連線	先比 Surfshark	Surfshark 付費方案不限同時連線；Proton Plus 上限 10 台
主要追求最低月費或電視 Smart DNS 便利	先比 NordVPN	NordVPN 在串流設備與近距離延遲上常有優勢，但隱私透明度呈現方式不同

一句話總結：付費版的核心價值不是「比免費版快一點點」——那是把 VPN 當成咖啡濃縮，其實你缺的是整杯。完整伺服器選擇、串流／P2P、多裝置，加上 Secure Core 等進階功能，才是升級理由。若你只用免費版做基本加密，其實已經比多數免費 VPN 安全；付費是為了解除那些「剛好卡住你」的限制。

付費版多了什麼？（VPN Plus 功能評價）

速度：差距比你想的大

Proton 不對免費版人工限速，但免費伺服器（美國、荷蘭、日本）負載高，尖峰時段常擠——就像尖峰時段只有三條免費高速公路可選，還不能自己挑出口。第三方測試與社群實測的參考區間如下：

指標	免費版	VPN Plus 付費版
典型下載速度	50–150 Mbps（尖峰可能 <30 Mbps）	950–1,500+ Mbps
典型上傳速度	30–80 Mbps	800–1,200+ Mbps
延遲（Ping）	20–200+ ms	本地 5–30 ms；跨國 80–150 ms
伺服器	3 國自動分配	140+ 國、20,000+ 台 10 Gbps 伺服器
網路優先權	低（排隊等頻寬）	高（Priority Access）

付費版還有 VPN Accelerator：透過優化 TCP 擁塞控制，長途連線速度可提升數倍。日常 4K 串流、大檔下載、視訊會議，付費版的穩定度通常明顯好一截。

誠實提醒：以上數字來自第三方基準測試，你的實際結果會受 ISP、地理位置、伺服器負載與協定影響。訂閱前建議自己測——別讓評測文替你喝這杯苦澀的現實咖啡。

只有付費版才有的功能

功能	做什麼	適合誰
完整伺服器選擇	自由選 140+ 國家，不再被系統分配到美／荷／日	需要特定地區 IP 的人
串流支援	官方列出的 Netflix、Disney+ 等 Plus 伺服器	旅行或跨區看自有訂閱的片庫
P2P／BT	專用高速伺服器	合法的大檔傳輸需求
Secure Core	流量先經瑞士／冰島／瑞典入口，再到出口國	高風險地區出口、重視實體防禦的使用者
NetShield	DNS 級別擋惡意網域、廣告與追蹤器	想少裝一個廣告攔截器的人
Stealth 協議	把 VPN 流量偽裝成 HTTPS，繞過 DPI 審查	在嚴格網路環境需要連線的人
Split Tunneling	指定哪些 App 走 VPN、哪些走直連	同時要本地銀行 App 與 VPN 的場景
瀏覽器擴充	Chrome／Firefox 一鍵連線	只想保護瀏覽器、不想全機 VPN 的人

Secure Core 和 Stealth 是 Proton 付費版較有特色的進階功能，多數競品沒有同等架構。但若你只是在家看串流，這兩個功能不是必開——Secure Core 還會讓速度更慢，官方也不建議拿它來排串流。開 Secure Core 看 Netflix，就像穿三層雨衣去海邊——很安全，但你不會因此游得比較快。

隱私與安全：付費版有比較安全嗎？

加密標準免費與付費相同（AES-256、WireGuard 等），差別在進階功能與伺服器架構：

無日誌政策：免費與付費共用同一套政策；Securitum 已連續第五年稽核，2026 年報告未發現伺服器記錄瀏覽活動或連線中繼資料。
瑞士管轄：截至 2026 年 6 月的透明度報告，47 件外國請求全部標為無法提供資料——因為沒有紀錄可交。
開源 App：程式碼公開在 GitHub，任何人可審計。
Kill Switch：免費版也有；但 macOS 切換伺服器時可能有短暫 IP 暴露，各平台限制不同。

付費版真正的安全加值是 Secure Core（多一跳、實體防禦入口）和 NetShield（擋已知惡意網域），不是「付費才加密」。若你重視可驗證的隱私證據，Proton 在公開稽核與開源這點上，確實比多數競品透明。

付費版值得買嗎？決策表

把「要不要付費」拆成可勾選的條件：

你的需求	免費版夠嗎？	付費版加分多少？
公共 Wi‑Fi 基本加密	✅ 夠	付費主要是速度與穩定度
自己選伺服器國家	❌ 不夠	⭐⭐⭐ 必要
Netflix／Disney+ 串流	❌ 不夠	⭐⭐⭐ 必要（但仍不保證每部片）
BT／P2P 下載	❌ 不夠	⭐⭐⭐ 必要
同時 2 台以上裝置	❌ 免費只有 1 台	⭐⭐⭐ 必要
擋廣告／惡意網域	❌ 沒有 NetShield	⭐⭐ 加分
繞過嚴格網路審查	❌ 沒有 Stealth	⭐⭐ 加分
高風險出口監控	❌ 沒有 Secure Core	⭐⭐ 加分（少數人需要）
只要最低月費	✅ 免費 $0	付費未必最便宜——見下方競品比較

勾選 3 項以上「付費版必要」 → 升級 VPN Plus 很合理。
只勾 1 項「速度」 → 建議先在自己網路實測免費版尖峰速度，再決定。別為了「感覺比較快」付年費，結果發現瓶頸其實是你家 Wi‑Fi——那杯咖啡就白喝了。

價格與方案：別只看促銷標語

官方結帳頁價格會依幣別、地區與促銷變動，以下為研究時的快照，訂閱前請直接查官方頁面：

方案	計費方式	參考價格（快照）	適合誰
Proton Free	—	$0	輕度使用者、先建立信任
VPN Plus	月繳	約 US$9.99／月	短期試用、不想一次付兩年
VPN Plus	年繳	約 US$3.99／月（一次 US$47.88）	確定會用滿一年
VPN Plus	兩年繳	約 US$2.99／月（一次 US$71.76）	長期使用者、單看 VPN 最划算
Proton Unlimited	依官方頁	含 Mail、Drive、Pass、VPN	本來就要用 Proton 全家桶

結帳前三件事：

看「今天要付多少」，不是只看每月折算價。
記下續費價格——促銷期過後可能不同。
確認付款管道——官網、App Store、Google Play 的退款入口不一樣。

30 天退款：訂閱前的安全網

首次直接向 Proton 購買，可在 30 天內取消並申請退款（每位使用者退款選項通常只能用一次）。重點：

取消 ≠ 退款：兩個動作都要做。
刪除 App 不會停扣款：必須在原付款管道取消續訂。
App Store／Google Play 購買：退款要走 Apple 或 Google 的流程，不是 Proton 網站。
取消後通常仍可用到目前計費週期結束，之後降回免費版。

若你只是不確定付費版好不好用，善用 30 天退款期在自己網路實測，比看十篇評測文更有說服力——畢竟你的 ISP 不會因為別人測速漂亮就對你特別溫柔。

跟 NordVPN、Surfshark 比：付費版站得住嗎？

若你已經決定要付費 VPN，但還在猶豫品牌：

比較面向	Proton VPN Plus	NordVPN	Surfshark
同時連線數	10 台	10 台	不限
隱私透明度	Securitum 稽核公開、App 開源、瑞士管轄	Deloitte 查核（報告需登入查閱）、巴拿馬公司	Deloitte 查核、荷蘭管轄
免費入門	✅ 不限流量免費版	❌ 無	❌ 無
串流設備便利	路由器／支援的 App	Smart DNS 對電視較方便	Fire TV、Android TV 等官方支援完整
獨特功能	Secure Core、Stealth、NetShield	NordLynx、威脅防護套件	不限裝置、RAM-only 伺服器
30 天退款	✅（依付款管道）	✅（續費不在內）	✅（依方案與管道）

選 Proton 付費版，若你已經用免費版、想無縫升級；重視公開稽核報告與開源；裝置數 ≤10 台；需要 Secure Core 或 Stealth。

先試 NordVPN，若你主要在智慧電視／遊戲主機看串流（Smart DNS 較省事）；重視近距離低延遲；不在意沒有免費版可長期使用。

先試 Surfshark，若你家中同時連線超過 10 台；預算優先、想要不限裝置。

沒有絕對贏家——兩家都有獨立無日誌查核，差別在證據呈現方式、功能取向與你的使用情境。建議在 30 天退款期內各測自己常用的串流服務與網路環境。

串流實際表現：付費版的真實期待

付費版才支援官方串流伺服器，但這不代表「買了就能看全世界」：

Netflix、Disney+ 仍需另外訂閱；VPN 訂閱不包含串流會員。
Netflix 廣告方案與直播活動官方明確不支援 VPN。
串流平台會更新封鎖規則，不能保證永久解鎖任何片名。
排串流問題時，不要用 Secure Core——它為安全設計，不是為速度。
遇到「使用 VPN 或 Proxy」錯誤：換 Plus 伺服器 → 重開 App → 清快取 → 暫時關 NetShield 測試 → 用 ipleak.net 查 IP／DNS 洩漏。

合理期待：付費版讓你在旅行或跨區時，有機會用自有訂閱看原本的片庫；不是繞過版權的萬能鑰匙。VPN 不是 Netflix 會員卡的加購醬料包。

訂閱前檢查清單

在按下付款前，逐項確認：

[ ] 我需要的功能（串流／P2P／多裝置／選國家）免費版確實做不到
[ ] 同時連線裝置數 ≤10（含瀏覽器擴充）
[ ] 已看過官方當下價格與續費價格
[ ] 知道退款入口（官網／Apple／Google）
[ ] 會在 30 天內實測常用服務與網路速度
[ ] 不把 VPN 當成防毒或完全匿名工具

產品	適合誰	說明
Proton VPN Plus（主推）	已用免費版、需要串流／P2P／多裝置／完整伺服器	30 天退款可實測；開源 App + 公開無日誌稽核
Proton Unlimited	同時需要 Mail、Drive、Pass 的 Proton 生態系使用者	別只用 VPN 單價比，把全家桶需求一起算
Proton Free	輕度使用者、還不確定要不要付費	先建立信任，確認限制再升級
NordVPN	重視電視串流便利（Smart DNS）、近距離低延遲	隱私查核報告需登入查閱；無免費版
Surfshark	家中超過 10 台裝置同時連線	不限同時連線；荷蘭管轄、Deloitte 查核

結語：我的評價

Proton VPN 付費版（VPN Plus）值得訂閱嗎？——若你已經被免費版的「不能選國家、不能串流、只有 1 台裝置、尖峰變慢」卡住，值得。付費版解的不只是速度，而是把 VPN 從「偶爾用用的安全網」變成「日常可用的完整工具」。

但若你只是偶爾在咖啡店上網、一台手機就夠，免費版已經是市場上少數真正可信的選擇，不必為了「付費比較安心」而多花錢——加密標準是一樣的，你的錢包不會因為多付而多一層 AES-256。

三個重點帶走：

付費版的核心價值是串流、P2P、多裝置、完整伺服器與 Secure Core／NetShield／Stealth，不是「付費才安全」。
價格要看續費與付款管道，善用 30 天退款在自己網路實測。
競品不是全面輸贏——裝置數 >10 看 Surfshark，電視串流便利看 NordVPN，隱私透明度與免費漏斗看 Proton。

若你確認需要 Plus 的功能，建議先到 Proton 官網領免費帳號（若還沒有）→ 在 30 天退款期內升級 VPN Plus 實測 → 不合適就依付款管道申請退款。決定好了再來一杯慶祝——或繼續喝免費版也沒關係，至少你的連線有加密。

聯盟揭露： 本文包含 Proton VPN 推薦連結。若你透過連結註冊或購買，我可能獲得推薦回饋；這不會增加你的費用。本文依研究筆記與官方文件撰寫，請依你的實際需求與測試結果做最終決定。

👉 免費申請 Proton 帳號 →

參考資料

Proton VPN plans explained — 官方方案類型、Free 與 Plus 功能差異。
Proton VPN official pricing — 結帳時的方案、幣別與促銷價格（以當日頁面為準）。
How to cancel a Proton VPN subscription — 取消步驟、退款管道與處理時間。
Does Proton VPN keep logs? — 無日誌政策說明。
Proton VPN passes 5th annual external audit — 2026 年 Securitum 無日誌稽核。
How to watch Netflix with Proton VPN — 串流支援範圍與限制。
Proton VPN Features — Secure Core、NetShield、Stealth 等功能說明。

為什麼要發明 Pi？從作者角度理解 Pi vs Claude Code 該怎麼選

2026-08-07T03:32:15Z

終端裡的 AI 程式助手越來越多：Claude Code、Cursor，還有各種「多代理＋Plan Mode＋MCP」大禮包。功能清單看起來很強，但你有沒有遇過這種感覺——工具一更新，行為就變了；你以為它在「幫你想」，其實有一段上下文是介面看不到的；出錯時又不知道該查哪一層？

（有點像咖啡店改菜單：你點的還叫同名，內容卻換了豆。AI 工具也會這樣，而且通常不會在杯子上貼告示。）

Pi Coding Agent 的作者 Mario Zechner，正是從這類痛點出發，選擇重做一個極小核心，而不是繼續往既有工具堆功能。這篇不做沒有實測根據的「誰比較強」評比，也不喊誰全面勝利；目標很單純：用作者為什麼要發明 Pi 當鏡頭，幫你看懂兩種哲學，再決定自己要的是 Pi 的可控性，還是 Claude Code 的現成工作流。

讀完你會帶走：作者動機怎麼對到設計、四個原則怎麼想、一張決策表幫你 30 秒對號入座。

先講清楚：這不是「Claude Code 不好」

作者的公開文章把 Claude Code 當成「既有 Coding Agent 逐漸變複雜」的對照例子——但那是他對自己工作流的取捨，不是對所有人的判決。以下的功能描述以相關官方文件與文章目前列出的內容為準；這類工具更新很快，實際行為仍要以你使用的版本和設定為準。

Claude Code 適合：想要內建 Plan、子代理、MCP、斜線指令，少自己組裝。
Pi 適合：想看見上下文與中間產物、把工作流放在檔案／CLI／tmux，願意自己決定要加什麼。

讀完這篇，你應該能回答一句話：「我比較怕黑箱變動，還是比較怕自己組工具的成本？」

答得出來，比背一百個功能還有用——功能清單只告訴你「有什麼」；真正幫你判斷怎麼修、怎麼選的，是你對工具的使用原則。

作者為什麼要重新做一個 Coding Agent？

既有工具遇到的問題（作者說法）	Pi 的設計回應	你實際可以怎麼用
Claude Code 從早期較簡單，逐漸變成作者用不到很多功能的複雜工具；發布常改 system prompt／工具定義，既有工作流與模型行為跟著變	核心「不需要就不建」；短 system prompt；差異放到外部擴充	固定自己的提示、`AGENTS.md`、驗證流程；升級後重新檢查，不要假設行為永遠不變
Context engineering 很重要，但其他 harness 可能在 UI 看不到的地方注入上下文	Session、工具呼叫、來源與產物保持可見；規劃寫成檔案，不藏在黑箱代理裡	要求 Agent 把研究／計畫／檢查結果寫成可讀檔，人工看完再進下一階段
內建子代理把上下文傳遞與錯誤藏在另一層，出錯難追查	不提供專用子代理工具；需要時用 bash 再開一個 Pi，或用 Extension／Package 自己組	任務邊界與輸出格式清楚才拆 session，中間產物一律存檔

一句話總結作者動機：

當 Coding Agent 變得複雜、常改又不透明時，最可靠的回應不是再加一層功能——而是縮小核心、提高可觀測性，讓使用者自己決定要加什麼。

官方定位也呼應這點：「讓 Pi 適應你的工作流，而不是反過來。」——翻成口語：工具來遷就你的終端習慣，不是你遷就它的儀式流程。咖啡機有預設模式很方便；但如果你想自己調研磨度，誰也不能禁止你拿出手沖壺。

Pi 的四個設計原則（對照 Claude Code 怎麼想）

1. 極簡核心，不是功能競賽

作者文章描述：Pi 的 system prompt 與預設工具定義合計可低於約 1,000 tokens；預設核心大致是讀、寫、編輯與 bash。極簡不是叫大家永遠只用四個工具，而是把 MCP、子代理、Plan Mode 等能力移到 Extensions、Skills、Prompt Templates、Packages——按痛點再加。這裡的「四個」是核心設計的概括，不代表每個版本或擴充後都只剩四項能力。

Claude Code 走另一條路：代理人循環（收集上下文 → 執行動作 → 驗證結果）＋較豐富的內建工具與斜線指令（如 /compact、/diff、/model），並以 CLAUDE.md、Skills、MCP 擴充。對「我想立刻開工」的人，這通常比較省事。

白話對照：Claude Code 像開箱即用的咖啡機；Pi 像手沖壺——多一步，但你看得見水溫、粉量和時間。

2. 可觀測性優先

Pi 偏好把計畫寫成 Markdown：人可以編、跨 session 重用，也能進版本控制。「Agent 做了什麼」變成可檢查的產物，而不是只信最後一句摘要。換句話說，規格、計畫和進度先落檔，人工過目再寫碼；這種做法也比較容易留下日後能追溯的線索。

Claude Code 也有規範檔與驗證迴圈，但作者批評的重點是：若規劃與子工作藏在內部狀態，除錯成本會變高。你若本來就習慣「先看 diff／計畫再准執行」，兩套都能做；差別在於狀態預設放在哪——檔案系統，還是工具內建流程。

3. 用組合取代內建一體化

Pi 刻意不內建	官方建議替代	什麼時候值得自己組
MCP	小型 CLI＋README，或自行加 Extension	工具少、要控 token、輸出想直接寫檔串接
子代理	tmux 再開 Pi、Extension、Package	要看見子過程，或真的要平行任務
Plan Mode	計畫寫入檔案，或自行擴充	計畫要跨 session、共同編輯、版控
背景 bash	tmux	長跑測試、開發伺服器、互動除錯
權限彈窗	容器／隔離帳號／自訂確認	不可信程式碼或機密資料

作者對大型 MCP 的具體顧慮是：工具說明每次塞進上下文，token 貴，輸出還常得繞回 Agent 才能保存。他提的替代是「小型 CLI + README + bash」——需要時才讀，輸出可直寫檔。

Claude Code 官方文件列有 MCP 整合，對「接資料庫／瀏覽器／外部服務、不想自己包 CLI」的人是加分。你要選的是：內建方便 vs 按需載入、看得見成本。

4. 安全責任放回執行環境

Pi 預設不走「權限彈窗＝安全」這條路；作者認為 Agent 一旦能讀寫檔、跑指令，單靠彈窗很難形成完整邊界。這不是宣稱 Pi 比較安全，而是要求你用容器、隔離帳號、網路限制等真邊界。含機密的主機開 YOLO，風險在你，不能照抄作者個人設定。

Claude Code 提供權限確認與相關隔離選項；對不想自己從零設計沙箱的人，通常比較「有提示、有流程」。兩邊都不是魔法盾——差在預設假設誰負責安全，而且最後仍要由你確認實際的執行環境。

比喻	對應的做法	實際效果
門上貼「請勿打擾」	Agent 跳出權限彈窗，你點「允許」	只是提醒／確認，對方真要闖還是進得去
門鎖上了	容器、隔離帳號、網路限制	物理／技術邊界，進不去才是真隔離

彈窗是禮貌的提示；隔離才是真的鎖門。兩者看起來都在「管安全」，保護力差很多。

決策表：我該選 Pi 還是 Claude Code？

用這張表做決定（可以兩邊都裝，但同一目錄不要同時寫檔；要並行請用不同 worktree 或其他隔離方式）：

你的情境	較適合	先確認這件事
想快速使用整合好的流程，不想自己組工具	Claude Code	能否接受 system prompt、工具與版本變動
想逐步檢查上下文與中間產物、計畫要進 Git	Pi（或同等可觀測工作流）	是否願意維護 markdown、CLI、tmux
已在使用 Anthropic 生態、愛斜線指令與內建任務工作流	Claude Code	MCP／Skills 的 token 與權限範圍
本地模型、控 token、設定要可移植（`AGENTS.md`、`.pi/`）	Pi	短 prompt 在你的模型／專案規模是否夠用（要實測）
要查瀏覽器、資料庫、外部服務，且想少寫 glue code	Claude Code＋MCP，或 Pi＋按需 CLI／Extension	工具描述成本、輸出能否存檔
不可信程式碼或機密檔案	先隔離，再選任一 Agent	隔離是否真限制檔案與網路，而不只是警告

30 秒口訣

怕黑箱與升級打破工作流 → 先試 Pi。
怕自己組裝與維護成本 → 先用 Claude Code。
都要一點 → 主流程用 Claude Code／IDE；終端批次、低成本實驗、可版控的 Agent 設定用 Pi。

工具	適合誰	備註
Pi Coding Agent	想要極簡核心、可觀測產物、按需擴充的終端使用者	先用裸 Pi 跑通小任務，再加 Package／Extension
Claude Code	想要整合代理人工作流、MCP 與專案規範的 Anthropic 生態使用者	用 `CLAUDE.md` 固定專案規範；升級後抽查行為
延伸閱讀	想系統學 Pi 工作流	站內：Pi Coding Agent 完整指南

結語：選哲學，再選按鈕

作者發明 Pi，不是為了「功能贏過 Claude Code」，而是為了在複雜、常改、不透明的 Coding Agent 浪潮裡，留下一個看得見、擴得動、核心夠小的 harness。這個選擇不一定讓每個人都更省事，卻讓取捨本身變得比較清楚。

帶走三點：

動機：縮小核心＋可觀測性，對抗黑箱與工作流被升級拆掉。
取捨：Claude Code 用整合換省心；Pi 用組合換控制權。
下一步：用上面的決策表對號入座，不要只比功能勾選清單。

先挑一個小任務（例如修一個測試失敗）——若你要「開箱即用」，用 Claude Code 跑完並檢查差異；若你要「計畫與驗證都落檔」，用 Pi 把計畫寫成 Markdown 再改碼。跑完一次，比再讀十篇比較文更準。畢竟工具比較文可以收藏，失敗的測試不會因為被收藏就自己修好。

審完再來一杯。下一杯建議：直接動手，別再收藏文章了。

參考資料

What I learned building an opinionated and minimal coding agent — Mario Zechner 說明為何做極簡 Pi、對照既有 Coding Agent 的痛點
What if you don't need MCP at all? — 作者對大型 MCP 成本與「小型 CLI + README」替代方案的論點
Pi coding agent README — 官方定位、刻意不內建項目與擴充方向
Pi Coding Agent 官網 — 產品入口與文件入口
Anthropic Claude Code 官方指南 — Claude Code 的工作方式、MCP、CLAUDE.md 與擴充能力
Building Pi, and what makes self-modifying software so fascinating — Pragmatic Engineer 訪談／整理，補作者背景脈絡

我如何用 PageSpeed Insights 優化 11ty 網站：為什麼比 WordPress 更容易直接修

2026-08-06T01:25:00Z

沒有一杯咖啡解決不了的效能問題；如果有，就先把 PageSpeed Insights 的診斷報告打開，看看是哪個資源在拖後腿。

我做 11ty 網站效能優化時，通常會先把網址丟進 PageSpeed Insights，看它指出的具體問題，再回到 11ty 的模板、CSS、圖片設定或 JavaScript 原始碼逐項修正。很多「改 HTML 屬性、補尺寸、延後腳本」這類步驟，其實可以交給 AI 動手；你負責寫清楚提示詞，再審核 diff 與實際結果。

這個流程在 11ty 上很直接：首圖太大，就處理首圖；圖片沒有明確寬高，就改 HTML 或圖片管道；第三方 JavaScript 阻塞主執行緒，就延後或移除那支腳本。改完重新 build、部署，再用相同條件測一次。

WordPress 當然也能優化，但問題有時藏在佈景主題、頁面編輯器、快取外掛和圖片外掛互相疊加的結果。你可能知道 PageSpeed Insights 要求什麼，卻不知道哪一層才是可以安全修改的地方。

這篇記錄我如何把 PageSpeed Insights 的建議轉成 11ty 的實際修改。重點不是宣稱哪個框架永遠比較快，而是：在 11ty 裡，診斷結果通常可以直接對應到你能控制的模板、資產或腳本。

先說結論：PageSpeed Insights 是診斷工具，不是框架評分表

PageSpeed Insights 不能單獨拿來比較 11ty 和 WordPress 誰比較快。它會提供實驗室資料與欄位資料，兩者用途不同：

Lighthouse 實驗室資料：適合重現問題、觀察剛做的改動。
Chrome 使用者體驗報告（CrUX）欄位資料：反映真實使用者的體驗，通常看第 75 百分位。

新網站流量不足時，可能暫時沒有 CrUX 資料。這時仍然可以先用 PageSpeed Insights 和 Lighthouse 做預防性優化，但不要把一次測試的分數當成網站的永久成績單。

我會先看這三個 Core Web Vitals 指標：

指標	它在看什麼	我通常先檢查什麼
LCP	首屏最大文字或圖片多久出現	hero 圖片、TTFB、阻塞 CSS、圖片是否被 lazy-load
CLS	頁面載入時是否跳動	圖片寬高、字體、嵌入內容和廣告預留空間
INP	使用者點擊或輸入後多久得到回應	第三方腳本、GTM、搜尋或互動元件

如果 PageSpeed Insights 顯示 95 分，但 Search Console 的 Core Web Vitals 仍有大量需要改善的 URL，我不會只看著實驗室分數自我安慰，而會回頭確認真實裝置和真實網路條件。

我的 11ty 優化循環：測量、定位、直接修改、再驗證

我通常照下面的順序做：

固定同一個 URL 或首頁當測試條件，先跑 PageSpeed Insights，記下 LCP、CLS、INP、FCP 和診斷項目。
找出問題對應的實際 HTML 元素或網路請求，例如「LCP 元素」是哪張圖，或是哪支腳本造成長任務。
把診斷原文貼給 AI，一次只請它改一類問題（例如只修 LCP 首圖），並寫清楚「不要動哪些檔案」。
在本機 build，檢查輸出的網頁是否真的產生預期的 HTML 和資產。
部署後用相同 URL 重跑 PageSpeed Insights，記錄改了什麼、分數和診斷如何變化。
如果是 GTM 或分析工具，除了看效能，也確認事件和轉換追蹤沒有被犧牲。

一次只改一類問題，比較容易判斷因果。這一輪只處理圖片，下一輪再處理第三方腳本；如果同時換模板、換 CDN、刪掉五個外掛，最後就算分數變好，也很難知道真正有效的是什麼。

如果要在本機重現，先讓網站用和正式環境接近的方式完成 build，再用 Lighthouse 測試可存取的 URL。不要直接拿開發伺服器的熱更新狀態和正式網站比較，否則很容易把「開發工具的噪音」誤認成效能問題。

pnpm run build
pnpm exec lighthouse https://example.com/某篇文章/ \
	--output=html \
	--output-path=./lighthouse-report.html \
	--chrome-flags="--headless"

PageSpeed Insights 適合看整體診斷與欄位資料；Lighthouse 則適合在你能控制的測試環境裡重現問題。兩者不是互相競爭的咖啡師，而是不同杯型的量杯。

通用提示詞骨架（可複製後改診斷內容）

無論修 LCP、CLS 還是腳本，我都會先用類似這樣的骨架：

這是一個 11ty（Eleventy）網站專案。請依 PageSpeed Insights 診斷修正，一次只處理一類問題。

【目標頁面】
https://example.com/某篇文章/

【這次只要處理】
（例如：LCP 首圖太慢 / CLS 圖片缺尺寸 / 第三方 JS 長任務）

【PageSpeed Insights 原文診斷】
（把 Opportunities、Diagnostics、LCP element、相關 network request 整段貼上）

【專案限制】
- 只改與這次問題直接相關的模板、CSS、圖片設定或 JS
- 不要改 URL、permalink、追蹤 ID、部署腳本、與效能無關的內容文案
- 不要一次「整站優化到 100 分」
- 改完請說明改了哪些檔案、為什麼這樣改，並列出我應手動驗證的項目

請先定位對應檔案與輸出 HTML，再提出最小修改。改完請跑本機 build（若專案有現成指令），確認沒有 build 錯誤。

提示詞寫得越具體，AI 越不會順便重構半個站。咖啡加太多糖也不好喝；優化提示詞也一樣，甜度要剛好。

PageSpeed Insights 指出 LCP 慢：先找真正的最大元素

LCP 常常是文章首圖、hero 圖或 H1，但不能只憑猜測決定。先在報告裡確認 LCP element，再針對那個元素處理。最常見的錯誤，是把首屏圖片也加上 loading="lazy"。懶載入適合視窗外的圖片，但會讓瀏覽器更晚發現 LCP 資源。

我會先做幾件事：

把圖片轉成 WebP 或 AVIF。
讓圖片尺寸接近實際顯示寬度，不要把幾千像素的原圖直接送給手機。
為圖片寫上正確的 width 和 height。
首屏圖片視情況使用 loading="eager" 和 fetchpriority="high"。
只有最重要的一、兩個資源使用高優先權，不要所有圖片都搶同一個優先級。

例如首圖可以像這樣：

<img
  src="/img/hero.webp"
  width="1200"
  height="630"
  alt="文章主視覺"
  loading="eager"
  fetchpriority="high"
/>

如果網站圖片很多，我會再導入 @11ty/eleventy-img。它可以在 build 時產生多種格式和寬度，並依產生的圖片資料協助輸出尺寸與 srcset。這比每次寫文章都手動處理圖片可靠。

不過圖片管道的輸出仍要檢查：即使圖片工具產生了 srcset，也不代表瀏覽器一定會用到最適合的候選檔案；而且 hero 圖的載入策略仍要個別確認。

給 AI 的提示詞範例（LCP）

請只處理 LCP，不要動第三方腳本，也不要順便改 CLS 版面預留。

PageSpeed Insights 指出 LCP 元素是：（貼上 LCP element 截圖或文字，例如 article hero img）
目前問題可能包含：圖片過大、格式不是 WebP/AVIF、誤用 loading="lazy"、缺少 fetchpriority、缺少明確 width/height。

請在這個 11ty 專案中：
1. 找出產生該 LCP 圖片的 Markdown / layout / Image Transform 設定
2. 讓首屏圖片改為 loading="eager"、fetchpriority="high"，並確保有 width/height
3. 確認視窗外圖片仍可 lazy-load，不要全站改成 eager
4. 若已使用 @11ty/eleventy-img，優先在既有管道調整，不要另開一套圖片流程
5. 改完說明輸出 HTML 應長什麼樣子，並列出我要驗證的項目

AI 做完後，你要審核什麼（LCP）

diff 範圍：是不是只動了首圖／hero 相關模板或圖片設定，沒有順便改追蹤碼或全站 CSS。
輸出 HTML：本機 build 後打開該頁原始碼，確認 LCP 圖真的是 eager + fetchpriority="high"，且有 width/height。
不要誤傷下文圖片：文章中段、側欄、相關文章縮圖仍應 lazy；若全部變 eager，會反而搶頻寬。
實際載入：用瀏覽器 DevTools Network，確認首屏圖優先被請求，且尺寸合理（不是幾千像素原圖硬塞手機）。
重測：同一 URL 再跑 PageSpeed Insights，看 LCP 與「Improve image delivery」類診斷是否改善。

PageSpeed Insights 指出 CLS：先補尺寸，不要只調分數

CLS 的問題常常不是 11ty 本身造成，而是輸出的 HTML 沒有告訴瀏覽器圖片會佔多大空間。圖片載入後才撐開版面，讀者原本要點的按鈕就可能被推走。

我的檢查順序是：

找出全站 <img>，確認是否都有真實的 width 和 height，或有可預期的 aspect-ratio。
檢查 YouTube、社群貼文和其他 iframe 是否有固定比例或預留高度。
檢查 web font 載入後是否造成文字換行和版面位移。
檢查 cookie、聯盟揭露或廣告區塊是否在內容上方突然插入。

這也是 11ty 好處很明顯的地方：我可以在共用 layout、shortcode 或 Image Transform 統一修正，不必逐頁打開 WordPress 編輯器，也不必猜某個外掛會不會在前端再次改寫 HTML。

給 AI 的提示詞範例（CLS）

請只處理 CLS（版面位移），不要改 LCP 優先權策略，也不要動分析／GTM 載入時機。

PageSpeed Insights 診斷：（貼上 layout shift 相關項目、受影響元素）

請在這個 11ty 專案中：
1. 找出缺少 width/height 的 <img>，以及可能造成位移的 iframe、字體、上方橫幅
2. 在 layout、shortcode 或 Image Transform 統一補上真實尺寸或 aspect-ratio
3. 若有 YouTube／社群嵌入，請用固定比例容器預留空間
4. 不要用「把內容延後載入」這種方式假裝解決 CLS
5. 改完列出改動檔案，並告訴我應在哪些頁面用肉眼看載入過程有沒有跳動

AI 做完後，你要審核什麼（CLS）

尺寸是真的，不是亂填：width/height 要對應實際比例；亂填會讓圖片被壓扁或裁切。
全站一致性：共用 layout／Transform 改過後，抽查首頁、文章頁、分類頁各一頁，確認不是只修了示範頁。
字體與橫幅：若 AI 只補了圖片尺寸，但診斷點的是 web font 或頂部通知條，要退回請它對準真正元素。
肉眼驗證：硬重新整理時盯著標題與按鈕位置，載入過程不應上下跳；必要時開 DevTools 的 Layout Shift regions。
重測：同一條件重跑 PageSpeed Insights，確認 CLS 下降，且沒有為了 CLS 把首圖又改回有害的 lazy。

PageSpeed Insights 指出 JavaScript 太多：先問這支腳本真的需要嗎？

純文章型 11ty 網站可以預設不載入 JavaScript，但只要加上 GA4、GTM、聊天工具、社群分享 SDK 或搜尋功能，INP 和主執行緒就可能開始變差。這裡的重點不是看到一支腳本就立刻刪掉，而是確認它在什麼時機、做了多少工作，以及功能是否真的需要它。

我會先做腳本盤點：

腳本類型	我的處理方式	需要注意的取捨
不再使用的追蹤或聊天工具	直接移除	先確認沒有業務依賴
非關鍵分析	延後到 `window` loaded 或 idle	早期 pageview 可能遺失
使用者點擊後才需要的功能	點擊時才載入	第一次互動可能需要等待
需要精準記錄的轉換事件	保留即時路徑或精簡標籤	不能只為了效能犧牲轉換資料
社群分享	優先用普通連結取代 SDK	互動效果較少，但前端更輕

GTM 不能只看 gtm.js 檔案大小。真正的成本可能來自容器裡的 Facebook Pixel、Hotjar、GA4 或其他標籤執行後造成的長任務。

如果採用 requestIdleCallback 或互動後載入，也要測試事件是否仍能在導向前送出，不能只看分數變好了就算完成。瀏覽器分數變漂亮了，分析資料卻少一半，這種優化就像把咖啡杯擦得發亮，結果裡面根本沒有咖啡。

下面是概念範例，不是可以直接套到所有分析工具的通用初始化碼。實際使用前，仍要依工具文件確認初始化順序、事件佇列和瀏覽器支援情況：

const loadAnalytics = () => {
	// 在這裡載入或初始化非關鍵分析工具。
};

if ('requestIdleCallback' in window) {
	window.requestIdleCallback(loadAnalytics, { timeout: 2000 });
} else {
	window.setTimeout(loadAnalytics, 2000);
}

requestIdleCallback 是「有空再做」的安排，不是「一定在某個時間完成」的保證；timeout 也不是分析事件送達的保證。若事件很重要，應該設計可接受的備援，並用瀏覽器 Network 或工具的除錯模式確認它真的送出。

給 AI 的提示詞範例（第三方 JavaScript）

請只處理第三方／非關鍵 JavaScript 對 INP 與主執行緒的影響，不要改圖片與版面尺寸。

PageSpeed Insights 診斷：（貼上 Unused JavaScript、Reduce JavaScript execution time、長任務、相關 URL）

腳本盤點現況（請先對照專案後再改）：
- 必須保留且需準確的：（例如 GA4 轉換、主要 pageview）
- 可延後的：（例如非關鍵分析）
- 可改為點擊才載入或改成普通連結的：（例如社群 SDK）
- 可移除的：（例如已停用的聊天工具）

請提出最小修改：
1. 先盤點 layout／site.js 實際載入了哪些腳本
2. 依上表延後、互動後載入或移除；不要默默刪掉我標記為必須保留的追蹤
3. 若使用 requestIdleCallback 或 loaded 後載入，請說明對早期 pageview 的取捨
4. 改完列出我應如何驗證：效能重測 + 分析事件是否仍會送出

AI 做完後，你要審核什麼（JavaScript）

業務依賴：確認沒有刪掉仍在用的聊天、廣告、轉換標籤；diff 裡出現追蹤 ID 變更要特別小心。
載入時機：非關鍵腳本是否真的延後；關鍵轉換路徑是否仍即時或有可接受的備援。
功能回歸：搜尋、主題切換、表單、分享按鈕在本機點一輪，確認第一次互動不會整頁壞掉。
分析驗證：開 GA4／GTM 預覽或 Network 過濾相關請求，確認 pageview／轉換在典型瀏覽路徑仍會送出。
重測：同一 URL 看 INP／主執行緒診斷是否改善；分數變好但事件消失，這輪算失敗，要回滾或縮小範圍。

為什麼同一個建議，在 WordPress 上常常比較難落地？

這不是說 WordPress 完全不能優化。簡單、乾淨的 WordPress 站也可能有很好的效能；反過來，11ty 如果塞滿大圖、第三方腳本和錯誤模板，也一樣會拿到差分數。

差異在於問題的可控程度：

PageSpeed Insights 顯示的問題	11ty 常見修改位置	WordPress 常見限制
LCP 圖片太慢	Markdown、template、`eleventy-img`、HTML 屬性	佈景主題、圖片外掛、頁面編輯器可能都有關聯
CLS 版面位移	layout、CSS、Image Transform	主題元件、廣告或外掛動態插入內容
CSS 太多	直接整理模板和 CSS	主題與外掛各自載入，停用可能影響版面
JavaScript 阻塞	直接刪除、延後或修改載入策略	外掛可能依賴特定順序，更新後又重新注入
TTFB 偏高	靜態輸出、CDN、快取設定	PHP、資料庫、主機和快取外掛互相影響

簡單說，WordPress 的問題常是「我知道哪裡慢，但改了會不會破壞整個站？」；11ty 比較常是「我知道哪個檔案要改，改完 build 驗證就好」。

我會用 AI 加速修正，但不會讓 AI 直接亂改整站

AI 很適合把 PageSpeed Insights 的診斷轉成候選 patch，例如：

找出 layout 中所有沒有尺寸的圖片。
檢查 hero 圖是否誤用了 lazy-loading。
依目前的模板補上 fetchpriority 或 srcset。
找出可能重複載入的 CSS 和 JavaScript。
產生一個小範圍的 CSS 或模板修改。

但我會把 AI 當成能快速工作的實習生，而不是自動批准的部署工具。我的流程是：

先把 PageSpeed Insights 的原文診斷、目標指標和不能改動的範圍講清楚。
要 AI 一次只改一個檔案或一類問題。
讀 diff，確認它沒有順便改掉 URL、追蹤 ID 或其他不相關設定。
本機 build，檢查輸出 HTML。
用瀏覽器實際點一輪，確認圖片、選單、搜尋功能正常。
重新跑 PageSpeed Insights，並把改動和結果記錄下來。

提示詞要寫清楚的五件事

要寫清楚	為什麼重要	壞例子
目標頁面 URL	避免 AI 改到不相干的模板	「把網站變快」
只處理哪一個指標／診斷	方便對照前後測結果	「LCP、CLS、JS 一次修完」
診斷原文或截圖重點	讓 AI 對準真實元素，不是猜	「感覺首圖有點慢」
禁止改動的範圍	防止誤改追蹤、部署、文案	完全不設限制
完成後要回報什麼	你審核時有檢查清單	「改好跟我說一聲」

AI 交卷後的總審核清單

不管這輪修的是圖片還是腳本，我都會用同一張清單過一遍：

範圍：diff 是否只涵蓋這次約定的問題？有沒有「順便重構」？
正確性：輸出 HTML／CSS／JS 是否真的對應診斷（例如修 LCP 卻只改了下文 lazy 圖）？
回歸：導覽、搜尋、深色模式、表單、內嵌內容是否仍可用？
資料：若動過 GTM／分析，事件與轉換是否仍正確？
驗證：同一 URL、相近條件重測後，目標指標是否改善？有沒有其他指標明顯變差？
紀錄：這輪改了什麼、前後分數／診斷差異寫下來，方便之後回顧或回滾。

AI 可以幫我縮短「從診斷到修改」的時間，但不能替我判斷該不該犧牲分析資料，也不能保證它產生的 HTML 一定符合這個網站的模板結構，最好是本機開發審核做完再部署。

先上線再祈禱，比較像賭咖啡因，不像做優化。

什麼情況不該只為了 PageSpeed Insights 換成 11ty？

如果網站核心是 WooCommerce、會員、論壇、即時資料或複雜表單，WordPress 的動態能力可能比純靜態效能更重要。若團隊每天都需要非技術人員從後台發文，也要把編輯效率算進去。

我會把選擇簡化成這樣：

如果你的情況是	比較合理的方向
文章和教學為主，願意用 Git，PageSpeed Insights 長期有明確問題	評估 11ty，或先把部分頁面靜態化
WordPress 站很簡單，只是圖片和腳本沒整理	先做圖片、快取、外掛和第三方腳本盤點
每天靠後台編輯，沒有技術人員維護 build	留在 WordPress，優先找出可安全調整的瓶頸
電商、會員和複雜表單是核心	留 WordPress，或評估 headless WordPress 加靜態前台

換成 11ty 也不是 SEO 自動升級。URL、301、sitemap、canonical、內容品質和內部連結仍然要維護。11ty 解決的是「前端和輸出 HTML 更容易控制」，不是替你完成整套 SEO。

結語：把診斷建議變成可執行的工作清單

我喜歡用 11ty 做效能優化，並不是因為它能保證每個網站都拿到滿分，而是因為 PageSpeed Insights 指出問題後，通常可以直接找到對應的模板、CSS、圖片或腳本來修改。

最值得記住的三件事：

LCP 先找真正的最大元素，首圖不要盲目 lazy-load；提示詞要貼診斷原文，審核輸出 HTML 的 eager／fetchpriority。
CLS 先補圖片尺寸和版面預留；審核時確認尺寸是真比例，並用肉眼看載入有沒有跳。
INP 先盤點第三方 JavaScript；AI 延後腳本後，一定要驗證分析和轉換資料還在。

如果你也在維護 11ty 網站，可以先選一個代表性頁面跑一次 PageSpeed Insights，把第一個最具體的診斷貼進上面的提示詞骨架，讓 AI 做最小修改，再用同一張審核清單過完、相同條件重測。先從一個問題開始，通常比一次叫 AI「把整站優化到 100 分」更容易得到可驗證的結果。審完，再來一杯咖啡。

參考資料

PageSpeed Insights — Google 的網頁效能檢測工具，可查看 Lighthouse 實驗室資料與 CrUX 欄位資料。
Lighthouse 文件 — Lighthouse 的用途、報告與本機測試說明。
Web Vitals（web.dev） — LCP、CLS、INP 等 Core Web Vitals 的定義與評估方式。
Largest Contentful Paint（web.dev） — LCP 的計算方式與常見優化方向。
Cumulative Layout Shift（web.dev） — CLS 的成因、計算方式與版面穩定性建議。
Eleventy Image — @11ty/eleventy-img 的官方文件，說明圖片格式、尺寸與 srcset 產生方式。

Pagefind 教學：如何為 Eleventy 靜態網站加入純前端搜尋

2026-08-04T06:51:00Z

Pagefind 教學：如何為 Eleventy 靜態網站加入純前端搜尋

文章一多，讀者只靠導覽列和分類頁，找舊文就像在咖啡渣裡找關鍵字。這時先別急著架資料庫：對以文章為主的 Eleventy 靜態網站來說，Pagefind 通常已經很夠用。

這篇會帶你弄懂 Pagefind 的工作方式，接著完成 layout 標記、build 後建立索引，以及繁體中文搜尋的驗收。讀完後，你應該能判斷 Pagefind 是否適合自己的網站，也知道搜尋失靈時該從哪裡查起。

Pagefind 是什麼？

Pagefind 是在 build 後處理靜態 HTML 的搜尋工具。它會讀取網站輸出的 HTML，建立一組可由瀏覽器載入的索引檔；訪客搜尋時，結果在前端計算，不需要另開一個搜尋 API 或資料庫伺服器。

所以它很適合個人部落格、文件站和產品說明站。文章更新後重新 build，索引也跟著重建。反過來說，如果你的資料需要登入權限、個人化結果或即時更新，Pagefind 不是後端搜尋的替代品——咖啡濾紙也不能拿來當資料庫。

開始前先確認三件事

你需要一個能正常輸出 _site/ 的 Eleventy 專案，並確認共用 layout 的 <html> 有語言標記：

<!doctype html>
<html lang="zh-Hant">
	<head>
		
	</head>
	<body>
		
	</body>
</html>

語言標記不是裝飾。Pagefind 會在索引時讀取 <html lang>，依語言分開建立索引；瀏覽器初始化搜尋時，也會依目前頁面的語言載入對應索引。繁體中文網站通常可以使用 zh-Hant，但仍應用實際文章內容測試。

另外，請先單獨確認 Eleventy build 沒有錯誤。Pagefind 只能處理已經產生的靜態檔案，不能替你修好前一步的模板錯誤。

第一步：選擇 Pagefind UI 版本

Pagefind 的搜尋索引和搜尋介面是兩件事。索引先由 CLI 建立，UI 再載入 /pagefind/ 裡產生的資產。

目前常見的兩種 UI 寫法，不能直接混在一起：

Pagefind 1.4 及更早版本常用 Default UI：載入 pagefind-ui.css、pagefind-ui.js，再用 new PagefindUI(...) 初始化。
Pagefind 1.5 開始提供 Component UI：使用 pagefind-component-ui.css、pagefind-component-ui.js 和自訂元素，例如 <pagefind-modal>。

先看專案的 package.json 版本，再照對應文件操作。本文以 Pagefind 1.4 的 Default UI 示範，因為這是目前專案使用的版本。

在共用 layout 放入 CSS 與搜尋容器：

<link rel="stylesheet" href="/pagefind/pagefind-ui.css">

<div id="search"></div>

接著在 JavaScript 中載入並初始化 UI：

const pagefindScript = document.createElement('script');
pagefindScript.src = '/pagefind/pagefind-ui.js';
pagefindScript.onload = () => {
	new window.PagefindUI({
		element: '#search',
		showSubResults: false,
	});
};
document.body.appendChild(pagefindScript);

你也可以在頁面載入時直接用 <script> 載入；只有在訪客打開搜尋時才載入，則能避免每個頁面一開始都下載搜尋程式。重點是：不論採用哪種載入時機，索引尚未建立前，/pagefind/ 下的檔案都不存在，看到 404 不一定是 UI 寫錯。

第二步：告訴 Pagefind 要索引什麼

Pagefind 預設會處理頁面內容，但你可以用 data-pagefind-body 把範圍縮小，用 data-pagefind-ignore 排除固定介面：

<body>
	<header data-pagefind-ignore>
		網站導覽
	</header>

	<main data-pagefind-body>
		
	</main>

	<footer data-pagefind-ignore>
		頁尾資訊
	</footer>
</body>

這三個標記各自做一件事：

lang="zh-Hant" 提供語言資訊，讓 Pagefind 進行對應的語言處理。
data-pagefind-body 指定頁面真正要被搜尋的內容。
data-pagefind-ignore 排除導覽列、頁尾或分享按鈕，避免固定文字污染每一筆結果。

有一個容易漏掉的規則：只要網站任何頁面使用了 data-pagefind-body，沒有這個標記的頁面就不會被索引。因此，如果首頁、分類頁也要出現在搜尋結果裡，它們同樣要標記搜尋主體。

data-pagefind-ignore 是「排除元素」；它不會讓整頁消失。把它放在 header 或 footer 上，文章正文仍然會被索引。

第三步：在 Eleventy build 後建立索引

先建立網站，再把輸出目錄交給 Pagefind。使用專案已安裝並鎖定版本的 CLI，通常比每次用 npx -y 下載最新版更容易重現：

pnpm exec eleventy
pnpm exec pagefind --site _site --glob '**/*.html'

成功後，輸出目錄會出現 _site/pagefind/，裡面包含索引資料，以及 UI 需要的 JavaScript 和 CSS。Pagefind 本身沒有搜尋後端；這些檔案部署到同一個靜態網站後，瀏覽器就能載入它們。

如果想快速測試，也可以讓 Pagefind 在建立索引後提供本機靜態伺服器：

pnpm exec pagefind --site _site --glob '**/*.html' --serve

這個 --serve 是方便開發時測試的本機伺服器，不是正式環境必須部署的服務。不要直接用 file:// 開啟 HTML，因為瀏覽器的模組載入和 fetch 請求可能受到本機檔案權限限制。

第四步：把流程接進 package.json

手動跑兩個指令可以驗證概念，但很容易忘記第二個。把 Pagefind 接在 Eleventy 後面，每次 build 就會自動更新索引：

{
	"scripts": {
		"build": "NODE_ENV=production ELEVENTY_PROFILE=true pnpm exec eleventy && pnpm exec pagefind --site _site --glob \"**/*.html\""
	}
}

實際專案的 build script 可能還有清理、Vite 或其他收尾步驟；請把 Pagefind 放在「所有 HTML 都完成之後」。如果部署平台只執行 Eleventy，卻沒有執行 Pagefind，正式站自然不會憑空長出搜尋索引。

也可以在 Eleventy 的 eleventy.after 事件裡呼叫 Pagefind，但這會讓 Eleventy 設定檔同時負責建站和啟動外部程序。對多數專案而言，package.json 用 && 串接比較容易看懂、除錯，也能確保前一步失敗時不會誤把舊索引當成新成果。

繁體中文搜尋要怎麼驗收？

Pagefind 支援中文的分詞處理，但中文不像英文那樣以空白分隔；搜尋結果仍然取決於索引內容和查詢方式。這不是「加上 lang 就保證什麼都找得到」，所以請用真正的文章做測試。

部署前至少走過這份清單：

[ ] Eleventy build 成功，沒有模板或資產錯誤。
[ ] _site/pagefind/ 存在，且正式網址能載入 /pagefind/ 下的檔案。
[ ] 搜尋一個確定存在的文章標題，可以回傳結果。
[ ] 搜尋兩三個繁體中文詞組，例如「網站安全」或「靜態網站」。
[ ] 搜尋結果沒有被導覽列、頁尾或分享按鈕的固定文字洗版。
[ ] 修改文章後重新 build，結果中的摘要已更新。

若網站同時有多種語言，請讓每個頁面的 <html lang> 正確反映內容，不要全部硬寫成同一種語言。Pagefind 會依語言分開索引；標記錯誤，等於把書放進錯的書架，搜尋當然會繞遠路。

常見問題排查

搜尋框出現，卻沒有結果

先看瀏覽器 Network 面板：/pagefind/pagefind-ui.js、/pagefind/pagefind-ui.css 和索引檔是否回傳 404。再確認 Pagefind 指向的是包含 HTML 的輸出目錄，而不是專案原始碼目錄。

中文結果很少

檢查 <html lang> 是否存在且寫對，並用文章內確實出現的詞組測試。也檢查 data-pagefind-body 是否誤放在空容器，或文章所在頁面根本沒有這個標記。不要只因為終端機出現 stemming 相關提示就移除語言標記：中文搜尋仍可運作，只是 Pagefind 不會以英文詞幹還原的方式處理中文。

首頁或分類頁沒有出現在結果裡

這通常是 data-pagefind-body 的範圍規則造成的。只標記文章 layout 時，沒有標記的首頁和分類頁會被排除；在同樣希望被搜尋的頁面補上搜尋主體即可。

搜尋結果一直出現導覽列文字

將不需要搜尋的固定區塊加上 data-pagefind-ignore，刪除舊的 _site/pagefind/ 後重新 build。只改模板、不重建索引，搜尋結果不會自己更新——索引沒有讀心術，只有讀檔術。

本機測試看起來壞掉

確認不是用 file:// 開啟 HTML，也確認 Pagefind 產出的 /pagefind/ 路徑和網站部署的 base path 一致。使用 --serve 或其他靜態檔案伺服器重新測試，通常很快就能分辨是瀏覽器載入問題還是索引內容問題。

結語：先解決搜尋，再考慮升級

對大多數 Eleventy 部落格來說，第一版站內搜尋不需要資料庫。你只要：

在 layout 加入與 Pagefind 版本相符的 UI。
設定正確的 lang、data-pagefind-body 和 data-pagefind-ignore。
在每次 Eleventy build 後執行 Pagefind。
用實際的繁體中文查詢驗收。

這樣就能讓讀者搜尋已部署的文章。未來若真的需要會員權限、個人化排序或即時資料，再評估後端或託管搜尋服務；先把今天的搜尋做好，咖啡才不會冷得太有深度。

參考資料

Pagefind 官方文件：總覽、安裝與基本整合方式。
Running Pagefind：說明 --site、--serve 等 CLI 用法。
Customizing the index：說明 data-pagefind-body 與 data-pagefind-ignore。
Multilingual Search：說明 lang、多語言索引與中文分詞。
Pagefind UI Usage：說明 Default UI 的載入和初始化方式。
Eleventy Configuration Events：查閱 eleventy.after 等 Eleventy 事件。

11ty 與 Hostinger 快取怎麼設定？從 .htaccess 到更新驗收

2026-08-04T03:44:00Z

你把新文章部署上去，自己看得到最新版，讀者卻還在看昨天的內容？先別急著重跑 11ty，也別一杯接一杯咖啡地清快取。很多時候，問題不是建置失敗，而是瀏覽器、Hostinger、CDN 或 HTTP headers 還在提供舊檔案。

這篇會帶你用 11ty 建置 _site，再依檔案類型安排 HTML、CSS、JavaScript、圖片、字型和 Pagefind 搜尋資產的快取策略。你也會看到如何在 Hostinger hPanel 清除快取，以及用 curl 檢查公開網站實際回傳的 headers。快取不是壞掉的記憶體，只是它記得比你久了一點。

先記住快取原則

不要把所有檔案都快取一年。比較穩定的分法是：

HTML：短時間快取，或要求瀏覽器重新驗證，因為文章和首頁會更新。
CSS、JavaScript、圖片、字型：如果檔名包含版本號或內容指紋，可以長效快取。
Pagefind 搜尋資產：搜尋索引會隨文章更新，不能直接套用一般靜態資產的一年 TTL。

簡單說，內容頁要容易更新；URL 已經跟著內容改變的資產，才適合快取久一點。

11ty 與 Hostinger 各自負責什麼？

11ty 負責把 Markdown、模板和資產建置成 _site 裡的靜態檔案。它不會替你決定訪客的瀏覽器或 Hostinger CDN 要快取多久。

上線後的快取主要分成三層：

快取層級	作用	更新不生效時先檢查什麼
瀏覽器	減少訪客重複下載檔案	用無痕視窗測試
Hostinger 快取	減少來源站重複處理請求	hPanel 的 Clear cache 或 Cache Manager
CDN	讓訪客從較近的節點取得檔案	依 CDN 介面執行 Purge／Flush

所以，重新執行 11ty 只會更新輸出檔案，不能保證所有快取層立刻換成新版本。

部署前先確認 `_site`

在專案根目錄執行：

npx @11ty/eleventy

本專案的 pnpm run build 還會在 Eleventy 完成後執行 Pagefind，並寫入 _site/pagefind/。如果只是先檢查 Eleventy 輸出，可以執行上面的指令；正式部署則建議直接執行：

pnpm run build

接著確認 _site 裡有：

_site/index.html
最新文章的 HTML
CSS 和 JavaScript
圖片與字型
pagefind/ 搜尋資產（如果網站有使用 Pagefind）

上傳時，要把 _site 裡面的內容放到 Hostinger 的網站根目錄，常見位置是 public_html。不要把整個專案原始碼上傳到公開目錄，也不要多包一層 _site 資料夾。

依專案設定 `public/.htaccess`

本專案的 public/.htaccess 使用 Apache 的 mod_expires、mod_headers 和 mod_setenvif 管理快取與 response headers。下面是與目前設定相同的重點片段；完整檔案還包含重新導向、安全標頭、Gzip 和目錄列表設定。

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresDefault "access plus 5 minutes"
  ExpiresByType text/html "access plus 3 minutes"
  ExpiresByType text/css "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"
  ExpiresByType application/x-javascript "access plus 1 month"
  ExpiresByType image/jpeg "access plus 1 month"
  ExpiresByType image/gif "access plus 1 month"
  ExpiresByType image/png "access plus 1 month"
  ExpiresByType image/webp "access plus 1 month"
  ExpiresByType image/svg+xml "access plus 1 month"
  ExpiresByType font/ttf "access plus 1 month"
  ExpiresByType font/otf "access plus 1 month"
  ExpiresByType font/woff "access plus 1 month"
  ExpiresByType font/woff2 "access plus 1 month"
</IfModule>

<IfModule mod_headers.c>
  <FilesMatch "\.(?:html?)$">
    Header set Cache-Control "public, max-age=180"
  </FilesMatch>
  <FilesMatch "\.(?:css|js|gif|jpe?g|png|webp|svg|ico|woff2?)$">
    Header set Cache-Control "public, max-age=31536000, immutable"
  </FilesMatch>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

<IfModule mod_setenvif.c>
  SetEnvIfNoCase Request_URI "^/pagefind/" pagefind_asset
</IfModule>
<IfModule mod_headers.c>
  Header set Cache-Control "no-cache, must-revalidate" env=pagefind_asset
</IfModule>

這些設定分別做什麼？

ExpiresActive On：啟用 Apache 的過期時間設定。
ExpiresDefault "access plus 5 minutes"：沒有特別指定類型的檔案，預設快取五分鐘。
ExpiresByType text/html "access plus 3 minutes"：HTML 的 Expires 基準為三分鐘。
CSS、JavaScript、圖片和字型的 ExpiresByType：先設定為快取一個月，之後資產規則會再設定明確的 Cache-Control。
Cache-Control: public, max-age=31536000, immutable：把符合檔名規則的 CSS、JavaScript、部分圖片、圖示與 woff 字型實際設定為快取一年。
SetEnvIfNoCase Request_URI "^/pagefind/" pagefind_asset：找出 /pagefind/ 開頭的檔案。
Header set Cache-Control "no-cache, must-revalidate" env=pagefind_asset：讓 Pagefind 更新後立即重新驗證。
Strict-Transport-Security：不是檔案快取，而是告訴瀏覽器未來一年都使用 HTTPS；目前也包含 includeSubDomains。

一年快取有一個容易忽略的風險

目前的 <FilesMatch> 是按照副檔名套用一年快取，並沒有檢查檔名是否真的含有內容雜湊。因此沒有版本號的 style.css 或 app.js 也會進入一年快取。如果這些檔案在原 URL 直接更新，訪客可能長時間拿到舊版本。

另一方面，mjs、avif、ttf 和 otf 雖然有一個月的 ExpiresByType，卻不符合目前的 <FilesMatch>，不會拿到一年期的 Cache-Control。要維持一年 TTL，部署流程就必須確保資產 URL 會隨內容改變，或另外為未版本化資產加上較短的規則。

為什麼 Pagefind 需要單獨設定？

Pagefind 的檔案可能同時符合一般 JavaScript 或資產檔案規則，因此先拿到一年的長效快取。接著，env=pagefind_asset 條件會再套用重新驗證的 Cache-Control：

Cache-Control: no-cache, must-revalidate

這個例外很重要：一般資產可以快取一年，但搜尋索引不應該跟著使用同樣長的 TTL。

Header 需要 Apache mod_headers，ExpiresByType 需要 mod_expires，Pagefind 的環境變數需要 mod_setenvif。如果修改 .htaccess 後出現 500 錯誤，先還原修改，再逐段確認 Hostinger 是否支援相關模組與語法。

除了快取，`.htaccess` 還能負責哪些事情？

.htaccess 不只是快取設定檔，也可以集中管理 Apache 網站常見的伺服器規則。以下功能不一定全部都要啟用，應依網站需求和主機支援的 Apache 模組決定：

靜態網站路由：使用 mod_rewrite 管理重新導向或找不到頁面的處理方式。11ty 已經產生檔案式路由時，不要直接套用 SPA 的「全部導向 /index.html」規則，否則原本的 404 和文章路徑可能一起被煮成一鍋。
301 重新導向：將舊網址導向新網址，適合網站改版、文章改名或網址結構變更時使用。大量重定向最好由腳本產生，避免手動維護時遺漏或重複。
安全標頭：可設定 X-Frame-Options、X-Content-Type-Options 等 response headers，降低點擊劫持和 MIME 類型嗅探等風險。新增標頭前，應先確認不會影響網站嵌入或第三方服務。
Gzip 壓縮：使用 mod_deflate 壓縮 HTML、CSS、JavaScript 和 XML 等文字檔，減少傳輸量。JPEG、PNG、WebP 等通常已經壓縮，不需要再次壓縮。
目錄保護：Options -Indexes 可避免訪客直接看到沒有首頁檔案的資料夾列表。
HTTP 導向 HTTPS：使用 mod_rewrite 將 HTTP 請求重新導向 HTTPS。啟用前要先確認 SSL 憑證正常；HSTS 只會要求瀏覽器後續使用 HTTPS，不會代替 HTTP → HTTPS 的重新導向。

修改 .htaccess 前，先確認 Hostinger 支援所需的 Apache 模組與語法。建議一次只加入一個功能，修改後用 curl -I 和瀏覽器測試；若出現 500 錯誤，先還原最近一次修改，再逐段排查。

HSTS 不是檔案快取

這一行：

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

意思是瀏覽器在接下來一年內，連線到這個網站時優先使用 HTTPS。它不會決定 HTML、CSS 或圖片要存多久，因此不要把 HSTS 和 Cache-Control 當成同一種設定。

只有在 HTTPS 已經完全正常，而且所有會使用到的子網域也都能使用 HTTPS 時，才適合啟用較長的 HSTS 期限。

部署後到 hPanel 清除快取

每次部署後，依序做以下檢查：

進入 Hostinger hPanel 的網站 Dashboard，執行 Clear cache。不同方案或 hPanel 版本的選單名稱可能略有不同。
如果只想處理單一頁面，到 Advanced → Cache Manager 輸入 URL 後執行 Purge。
如果網站啟用了 Hostinger CDN，到 Performance → CDN 檢查 CDN 狀態，並依介面提供的選項清除快取。
用無痕視窗重新開啟首頁和剛更新的文章。

不要一開始只清除自己的瀏覽器快取。如果所有訪客都看到舊版本，問題更可能在 Hostinger 快取、CDN 或部署檔案，而不是單一瀏覽器。

用 `curl` 驗收 response headers

檢查首頁：

curl -I https://example.com/

檢查一個版本化資產：

curl -I https://example.com/assets/app.8f31c.css

你可以觀察 Cache-Control、Expires、ETag、Last-Modified、Age 和 Content-Type。

依本專案目前設定，首頁通常會看到三分鐘的 max-age；符合資產副檔名規則的 CSS 則可能看到一年的 max-age。Pagefind URL 則應該要求重新驗證：

curl -I https://example.com/pagefind/pagefind.js

如果重新請求時內容沒有改變，伺服器可能回傳 304 Not Modified，代表條件式快取正常運作。若 curl 已經拿到新內容，但瀏覽器仍是舊內容，再用無痕視窗、另一個網路和 DevTools Network 交叉確認。

快取設定決策表

你的情況	HTML	CSS／JS／圖片／字型	建議
文章常更新，檔名沒有版本號	`no-cache` 或短 TTL	短 TTL，例如 5–30 分鐘	先確保更新穩定，再逐步延長
CSS／JS 有內容指紋	`no-cache` 或一天	一年＋`immutable`	適合穩定的 production 靜態站
正在除錯快取問題	`no-cache`	`no-cache` 或短 TTL	驗收完成後再恢復長效快取
Pagefind 搜尋索引會更新	短 TTL	Pagefind 使用 `no-cache`；其他資產依版本策略	避免搜尋索引長時間未更新
CDN 剛啟用或剛清除	短 TTL	依 CDN 規則	等待節點更新，再用不同網路測試

這張表主要根據兩個問題決定快取時間：檔案多久會更新，以及檔案的 URL 是否會隨內容改變。

HTML 通常使用短 TTL：首頁和文章內容可能經常更新，因此使用短時間快取，讓瀏覽器較快向伺服器確認。本專案目前設定為三分鐘；no-cache 則是另一種要求使用前重新驗證的策略。
有內容指紋的靜態資產可以快取一年：例如 app.8f31c.css。CSS 或 JavaScript 更新後，檔名也會改變，瀏覽器會把它視為全新的檔案，因此適合搭配 immutable 使用一年 TTL。
固定檔名的資產應使用短 TTL：例如 style.css 或 app.js。如果內容更新但 URL 不變，長效快取可能讓訪客持續取得舊檔案；在尚未完成版本化時，可先使用 5–30 分鐘。
Pagefind 使用 no-cache：搜尋索引會隨文章更新，但 URL 通常不一定包含內容指紋，因此每次使用前都應重新驗證。
正在除錯時全部縮短 TTL：先讓 HTML、CSS 和 JavaScript 使用 no-cache 或短 TTL，確認部署與 response headers 正常後，再恢復長效快取。

要注意的是，這張表是判斷原則，不代表目前 .htaccess 已經自動檢查檔名是否含有內容指紋。目前的 <FilesMatch> 是按照副檔名設定一年快取，所以固定名稱的 style.css 或 app.js 也可能被快取一年。只有在部署流程確實會讓資產 URL 隨內容改變時，才適合使用一年 TTL 和 immutable。

常見問題

重新建置後，網站為什麼還是舊頁面？

先確認 _site 裡真的有新內容，再確認上傳的是 _site 內容，而不是原始 Markdown。接著依序檢查 Hostinger 快取、CDN 和瀏覽器，不要只重跑 11ty。

可以把所有檔案都設定成快取一年嗎？

不建議。沒有版本化的 HTML、style.css 或 app.js 可能長時間讓訪客拿到舊內容。只有 URL 會隨內容改變的資產，才適合搭配 immutable 使用一年 TTL。

為什麼 Pagefind 搜尋不到剛發布的文章？

可能是 Pagefind 索引本身沒有重新建置，也可能是 /pagefind/ 資產仍被舊快取提供。先確認部署輸出有最新索引，再用 curl -I 檢查 Pagefind URL 是否真的要求重新驗證，最後清除 Hostinger 或 CDN 快取。

改 `.htaccess` 後網站出現 500 怎麼辦？

先還原最後一次修改，確認 Hostinger 支援 mod_headers、mod_expires 和相關語法，再逐段加入設定。不要在未驗證前，直接把同一份 .htaccess 複製到其他網站。

部署驗收工具

Hostinger hPanel：用來清除網站快取、管理 Cache Manager，以及依方案管理 CDN。
curl：直接查看公開網站的 response headers，先確認伺服器實際回傳什麼，再判斷是不是瀏覽器問題。
Chrome DevTools Network：查看 Age、ETag、Cache-Control 和 response body，交叉確認不同資產是否使用預期的 TTL。

結語：先分層，再決定 TTL

11ty 快取問題的重點不是把數字設得越大越好，而是讓不同檔案採用適合自己的更新策略：

HTML 使用短 TTL，保持容易更新。
版本化 CSS、JavaScript、圖片和字型使用長效快取。
Pagefind 搜尋資產使用 no-cache，避免索引更新被卡住。
每次部署後用 hPanel、curl 和無痕視窗驗收。

完成設定後，下一步是到 Hostinger hPanel 清除快取，再用 curl -I 確認公開網站真的回傳預期的 headers。快取驗收完，再來一杯咖啡；這次咖啡和 HTML 都應該是熱的。

參考資料

Apache mod_expires 官方文件：說明 ExpiresActive、ExpiresDefault 和 ExpiresByType 如何產生快取標頭。
Apache mod_headers 官方文件：查閱 .htaccess 中設定與修改 response headers 的 Header 指令。
Pagefind Running Pagefind：說明在靜態網站建置後產生 pagefind/ 搜尋資產的流程。
Hostinger：Website caching explained：說明 hPanel Cache Manager、瀏覽器快取、伺服器快取與 CDN 的差異。

光輝咖碼

11ty vs Hugo vs Astro 怎麼選？2026 靜態站產生器決策指南

目錄

先確認：你真的需要 SSG 嗎？

三個框架一句話定位

60 秒主決策表：先圈出 1～2 個候選

規格比較表：知道 trade-off 在哪

Build 速度：別為了 benchmark 選錯框架

內容網站情境：誰比較順？

兩兩對打：你卡在誰跟誰之間？

11ty vs Hugo：極速 SSG 二選一

11ty vs Astro：JavaScript 陣營二選一

10 分鐘 hello-world：選型必做

選完框架之後的三件事

常見問題

結語：選能維護的，不是選 benchmark 冠軍

參考資料

Proton Unlimited 全產品與功能介紹（2026）：六合一隱私全家桶值得買嗎？

目錄

先講結論：Proton Unlimited 是什麼？

六大產品：解決什麼問題、什麼時候用？

Proton Mail — 取代 Gmail 的加密信箱

Proton Calendar — 取代 Google Calendar 的加密行事曆

Proton Drive — 取代 Google Drive 的加密雲端

Proton Pass — 取代 Chrome 密碼管理器

Proton VPN — 公共網路與 ISP 窺探的防護層

Proton Wallet — 自託管 Bitcoin 錢包

訂閱前先跑一輪盤點

方案與價格（2026 官方快照）

Proton Unlimited 定價（個人）

與其他個人方案快速對照

關鍵共用限制（Unlimited）

決策表：我該不該買 Proton Unlimited？

依需求選方案

依「會用到的 App 數量」粗估

Unlimited 不適合誰？

與單品加總的價值判斷

推薦工具／資源

結語

參考資料

Proton Pass 值得用嗎？2026 免費版、Plus 與 Unlimited 怎麼選

目錄

Chrome 密碼管理器夠用嗎？什麼時候該換？

Proton Pass 免費版：其實已經很完整

三種方案怎麼選？一張決策表搞定

付費前的三個自問

Free vs Plus vs Unlimited 功能對照

Hide-my-email：免費版最被低估的功能

從 Chrome 搬過來要多久？大約 15–30 分鐘

跟 Bitwarden、1Password 比，Proton Pass 適合誰？

推薦工具／資源

結語：先免費試，再依需求升級

參考資料

技術部落格怎麼留住讀者？版面、選單與頁面的設計筆記

目錄

先講結論：留存靠「下一篇」，不靠裝飾

主選單：4～5 個入口就夠

首頁：先說清楚網站定位

文章卡片：讓人 3 秒判斷值不值得點

文章頁：結尾比開頭更決定會不會留下

分類頁：不要只剩一排名字

行動版：首屏不要被選單擠爆

先做這五件，再談收藏與電子報

結語：菜單可以短，路線要清楚

參考資料

VPN 跟 HTTPS 差在哪？兩者的保護範圍怎麼比？

目錄

一句話記住：兩者保護的範圍不同

HTTPS 保護什麼？鎖頭代表什麼？

VPN 補上哪一塊？為什麼 HTTPS 夠了還有人開 VPN？

情境決策表：我現在要做的事，需要 VPN 嗎？

公共 Wi-Fi 常見情境

我要做什麼 → 怎麼連線（一頁帶走）

只有 HTTPS 夠嗎？快速對照

常見誤解：別把鎖頭或 VPN 當萬能藥

三分鐘安全檢查清單

推薦工具與資源

結語：先搞懂保護範圍，再決定要不要開 VPN

參考資料

Proton VPN 付費版評價（2026）：VPN Plus 值得訂閱嗎？