光輝咖碼

PageSpeed Insights 怎麼改善？實戰教學（LCP／INP／CLS 對照表）

2026-09-01T02:00:00Z

打開 PageSpeed Insights（PSI）輸入網址，分數不理想時，下一步通常不是「再測一次祈禱變綠」，而是對照診斷項目逐項修。這篇專注在「怎麼改善」：怎麼讀 PSI 報告、三項 Core Web Vitals 該修哪裡、以及 WordPress 與靜態站都能套用的實戰 Checklist。

指標定義與實地／實驗室資料差異，可搭配閱讀 PageSpeed Insights 與 Core Web Vitals 完全指南。若你維護的是 11ty 靜態站，另可參考 11ty 網站 PSI 優化工作流。

快速參考

項目	說明
工具	pagespeed.web.dev
三項核心指標	LCP（載入）、INP（互動）、CLS（穩定）
良好門檻（p75）	LCP ≤ 2.5s、INP ≤ 200ms、CLS ≤ 0.1
先看哪個	有 CrUX 實地資料 → 以實地為準；沒有 → 用 Lighthouse 診斷找問題
常見第一刀	壓縮 LCP 圖片、補 width/height、延後第三方腳本

第一步：怎麼用 PageSpeed Insights 測試

開啟 PageSpeed Insights
輸入完整網址（建議先測首頁與流量最高的文章各一頁）
分別查看手機與電腦結果
記下三項 Core Web Vitals 的顏色（綠／橘／紅）與 Lighthouse 診斷清單

PSI 通常提供兩種資料：

類型	來源	用途
實地資料（Field Data）	Chrome 使用者體驗報告（CrUX）	反映真實使用者最近 28 天的體驗
實驗室資料（Lab Data）	Lighthouse 模擬載入	找出可能拖慢的原因與改善建議

新站或流量不足的網址可能沒有網址層級的 CrUX 資料，這時以 Lighthouse 診斷為主，並在 Search Console 觀察累積後的趨勢。一次測試的分數會波動，不要只因為某天掉到 70 分就 panic；重點是同一 URL、同一裝置類型下，改動前後的對比。

Core Web Vitals 門檻速查

指標	看什麼	良好	需要改善	不佳
LCP	主要內容多久出現	≤ 2.5 秒	> 2.5–4 秒	> 4 秒
INP	點擊後多久有回應	≤ 200 毫秒	> 200–500 毫秒	> 500 毫秒
CLS	版面是否跳動	≤ 0.1	> 0.1–0.25	> 0.25

注意：FID 已被 INP 取代。若你看到舊文還在講 FID，請以 INP 為準。

三項都達到 Good（看實地資料的第 75 百分位）才算通過 Core Web Vitals 評估。Lighthouse 變綠有助除錯，但不等於搜尋排名會立刻起飛——內容相關性與整體體驗同樣重要。

LCP 怎麼改善

LCP（Largest Contentful Paint）衡量首屏最大內容元素完成繪製的時間，常見是 hero 圖、大標題或主要文字區塊。

先在 PSI 確認 LCP 元素是哪一個，再對症下藥：

問題方向	常見原因	改善做法
伺服器慢	TTFB 過高	換主機／CDN、啟用快取、靜態化
圖片太大	LCP 是未壓縮的大圖	WebP／AVIF、responsive `srcset`、適當尺寸
發現太晚	關鍵圖被 lazy-load	首屏 LCP 圖不要 lazy；必要時 `fetchpriority="high"`
渲染阻塞	CSS／同步 JS 擋住繪製	精簡關鍵 CSS、延後非關鍵腳本

靜態站可參考 LCP 優化：首屏別 lazy-load；WordPress 可搭配圖片外掛與快取外掛，但記得先確認 LCP 元素，不要對所有圖片盲目 preload。

INP 怎麼改善

INP（Interaction to Next Paint）觀察頁面生命週期中的點擊、點按與鍵盤互動，評估從互動到下一幀繪製的延遲。

常見拖慢原因：

第三方分析、廣告、聊天 widget 佔滿主執行緒
過大的 JavaScript bundle 或長任務（> 50ms）
載入期間就綁了大量事件處理

改善方向：

延後非必要腳本（GTM、社群分享、留言系統）到 requestIdleCallback 或使用者互動後
切割長任務，避免在 click handler 裡做大量同步運算
減少第三方數量，定期審計真的還需要的 widget
用 Chrome DevTools Performance 錄製「載入中點選單」等真實流程

可參考 GTM 延遲載入降低 TBT／INP 壓力。

CLS 怎麼改善

CLS（Cumulative Layout Shift）衡量版面在載入過程中意外位移的程度。

常見原因	解法
圖片沒預留空間	為 `<img>` 設定 `width`／`height` 或 `aspect-ratio`
廣告／嵌入突然插入	預留固定高度容器
網頁字型造成跳動	`font-display: swap` 或子集化；參考字型子集化
動態插入內容	先佔位再載入，或固定容器高度

詳解可見圖片尺寸與 CLS 預防。

30 分鐘改善 Checklist

以下流程假設你有一個 WordPress 或類似 CMS 的網站；靜態站把「快取外掛」換成 build 時的圖片與資產優化即可。

時間	任務	預期效果
0–5 分	跑 PSI，記錄 LCP／INP／CLS 基線與 LCP 元素	建立對照基準
5–10 分	啟用伺服器／頁面快取	改善 TTFB
10–15 分	壓縮 LCP 圖片為 WebP；首屏圖取消 lazy	LCP 通常最明顯
15–20 分	為所有內容圖補 width/height	CLS 下降
20–25 分	延後 GTM／第三方腳本；移除未使用外掛	INP／TBT 改善
25–30 分	再跑 PSI，對比診斷變化	驗證有效改動

不要一次開滿所有「極速」選項（例如 JS/CSS 全部合併＋延遲到離譜）。分數可能變 100，但版面爆炸或追蹤失效，使用者體驗反而更差。

3 個改善案例（方向參考）

案例 1：WordPress 部落格（LCP 4.2s → 1.8s）
啟用快取 + WebP 圖片 + 移除 3 個未使用外掛，並取消 hero 圖 lazy-load。PSI 行動分數從 40 多提升到 70 多。

案例 2：電商網站（CLS 0.25 → 0.05）
為商品圖補 width/height，廣告區塊預留空間，CLS 進入綠色區間。

案例 3：11ty 靜態站（TTFB 改善 + LCP 綠燈）
CDN 部署 + 響應式圖片管道 + 關鍵字體子集化。詳細流程見 11ty PSI 優化工作流。

常見誤區

分數高就代表 SEO 一定好？

Core Web Vitals 是排名訊號之一，不是唯一因素。Brian Dean 等實驗也顯示「速度」與排名相關，但不是線性對應。優化速度是為了使用者體驗，順便滿足 Google 的體驗訊號。

自己開很快，訪客就一定快？

開發者通常有更好的網路與裝置。要以 CrUX 實地資料或 Search Console 的體驗報告為準，不要只憑本機 Lighthouse 自我安慰。

實驗室滿分 = 實地資料也會綠？

不一定。實地資料受使用者裝置、地區、網路影響。實驗室幫你找問題，實地資料才反映真實世界。

只優化首頁夠嗎？

不夠。文章頁、分類頁若 LCP 是大型內文圖，也要逐頁檢查。Search Console 的「核心網頁指標」報告會列出需要改善的 URL 群組。

其他實用工具

工具	用途
Chrome DevTools Lighthouse	本機重現問題
Web Vitals 擴充功能	即時看 LCP／INP／CLS
WebPageTest	多地點、多瀏覽器測試
Google Search Console	全站 CrUX 趨勢與問題 URL

常見問題

PageSpeed Insights 適用行動裝置嗎？
是的，PSI 分別提供手機與電腦報告，兩者都要看。

一定要懂程式才能改善嗎？
基礎項目（快取、圖片壓縮、移除外掛）不一定需要寫 code；模板層級的 LCP／CLS 修正則可能需要開發者協助。

第三方廣告會影響分數嗎？
會。廣告腳本常拖慢 INP 並造成 CLS，需預留空間並評估是否值得保留。

結語

PageSpeed Insights 改善的本質是：先量測 → 找到 LCP 元素與最長任務 → 一次改一類問題 → 再驗證。不要追逐單次滿分，而要讓真實使用者在載入、互動與閱讀時都更順。

下一步建議：

今天先測首頁 + 一篇熱門文章，記錄基線
優先處理 LCP 圖片與 CLS 的 width/height
需要完整指標解讀時，閱讀 Core Web Vitals 完全指南

參考資料

encodeURI vs encodeURIComponent：何時用哪個？

2026-08-31T03:35:00Z

網址裡出現空格、&、中文，瀏覽器常常會看不懂——就像信封地址寫「3 樓 & 4 樓」，郵差可能以為你要寄兩戶。JavaScript 有兩個長得很像的函式：encodeURI 和 encodeURIComponent。名字只差一個 Component，但用錯的後果，有時比咖啡潑在鍵盤上還難收拾。

**一句話答案：**要編碼「整條網址」用 encodeURI；要編碼「網址裡某一塊的值」（查詢參數、路徑片段）用 encodeURIComponent。不確定時，參數值幾乎永遠選後者。

encodeURI 和 encodeURIComponent 差在哪？

想像你在寫地址：

encodeURI：整條地址一起處理，但會保留 : / ? & # 這些「路標」——它們是網址結構的一部分，不能亂改。
encodeURIComponent：只處理「包裹裡的內容」，把 &、=、/ 等特殊字元全部轉成 %XX，避免破壞外層網址結構。

比較項目	`encodeURI`	`encodeURIComponent`
編碼對象	完整 URI	單一 URI 組件（參數值、路徑段等）
轉義範圍	只轉「不該出現在 URI 裡」的字元	轉義幾乎所有在 URI 有特殊意義的字元
會保留的字元	`:`、`/`、`?`、`&`、`#` 等結構符號	無（結構符號也會被編碼）
典型用途	整條網址字串需要編碼時	查詢參數的值、路徑片段、要嵌進 URL 的字串

encodeURI 是什麼時候用的？

encodeURI 適合處理已經長得像完整網址的字串，例如使用者輸入的 URL 裡有空格或中文，你要讓它變成合法 URI，但不想把 https:// 裡的 : 和 / 也編掉。

encodeURI("https://www.example.com/my page?name=John Doe");
// "https://www.example.com/my%20page?name=John%20Doe"

空格變成 %20，但 ?、= 還在——因為它們是查詢字串的結構。問題也出在這裡：如果 name 的值本身含有 & 或 =，encodeURI 不會幫你保護這些字元，伺服器可能會誤讀參數。

encodeURIComponent 是什麼時候用的？

encodeURIComponent 把一段文字當成「要塞進網址某個位置的值」，所以特殊字元一律編碼，避免跟網址語法打架。

encodeURIComponent("name=John Doe&age=30");
// "name%3DJohn%20Doe%26age%3D30"

= 變 %3D，& 變 %26，空格變 %20。這就是為什麼組查詢字串時，每個參數的值都應該各自包一層 encodeURIComponent。

實戰：組查詢字串該怎麼寫？

下面用同一組資料示範兩種寫法：

const name = "John Doe";
const age = 30;
const url = "https://www.example.com/search";

// 方法一：整段丟進 encodeURI（查詢參數不推薦）
const badUrl = encodeURI(`${url}?name=${name}&age=${age}`);
// "https://www.example.com/search?name=John%20Doe&age=30"
// 簡單案例看起來沒事，但 name 若含 & 就會炸

// 方法二：只對參數值 encodeURIComponent（推薦）
const goodUrl = `${url}?name=${encodeURIComponent(name)}&age=${encodeURIComponent(age)}`;
// "https://www.example.com/search?name=John%20Doe&age=30"

兩種寫法在 name = "John Doe" 時結果一樣。差別在「值裡有沒有特殊字元」：

const tricky = "John & Jane";
encodeURI(`${url}?name=${tricky}`);
// "https://www.example.com/search?name=John%20&%20Jane"
// & 沒被編碼 → 伺服器可能以為有兩個參數

`${url}?name=${encodeURIComponent(tricky)}`;
// "https://www.example.com/search?name=John%20%26%20Jane"
// & 變 %26 → 安全

現代專案也可以直接用 URLSearchParams，它會幫你處理編碼，少手動拼接：

const params = new URLSearchParams({ name: tricky, age: String(age) });
const safeUrl = `${url}?${params}`;
// "https://www.example.com/search?name=John+%26+Jane&age=30"

+ 和 %20 在查詢字串裡語意相近；重點是特殊字元不會再破壞結構。

常見踩雷：什麼時候會用錯？

用 encodeURI 包查詢參數的值：參數含 &、=、# 時，網址可能被截斷或解析錯誤。
對整條網址用 encodeURIComponent：https:// 會變成 https%3A%2F%2F，瀏覽器打不開。
重複編碼：已經 %20 的字串再 encode 一次，會變 %2520，搜尋或導頁就對不上。
忘記解碼：讀取時用 decodeURIComponent 還原；URLSearchParams.get() 會自動解碼。

快速決策：我現在該用哪個？

情境	用哪個
整條 URL 有空格或中文，但結構已正確	`encodeURI`
查詢參數的 key 或 value	`encodeURIComponent`（或 `URLSearchParams`）
路徑片段（例如 `/users/王小明` 裡的名字）	`encodeURIComponent`
要把一段文字嵌進 `?q=` 後面	`encodeURIComponent`
不確定	參數值 → `encodeURIComponent`；整條 URL → `encodeURI`

網址編碼這件事，本質就是「哪些字元是地址本身，哪些只是包裹裡的內容」。記住這個分工，encodeURI 和 encodeURIComponent 就不會再讓你半夜 debug 404 了——除非你真的把咖啡打翻在鍵盤上，那 AI 也救不了。

參考資料

encodeURI() — MDN：encodeURI 保留與不保留的字元清單
encodeURIComponent() — MDN：encodeURIComponent 行為與範例
URLSearchParams — MDN：現代瀏覽器組查詢字串的建議做法
RFC 3986 — URI Generic Syntax：URI 字元集與 percent-encoding 的規格來源

Eleventy 怎麼顯示流程圖，Mermaid 的顯示和優化

2026-08-29T11:38:00Z

Mermaid 很方便：寫幾行文字，就能變成流程圖。問題是，如果每頁都把 Mermaid library 一起送到瀏覽器，讀者可能只是來看一篇文章，卻先搬一箱 JavaScript 回家。

文章中的流程圖、架構圖通常不需要訪客現場編輯或互動。這類圖適合用 Mermaid CLI 在建置前轉成靜態檔，再用 <img> 顯示——不用每頁載入 Mermaid JavaScript，Vite bundle 也不會因固定圖變胖，還能用 alt、width、height 和 <figcaption> 照顧可讀性與版面穩定。如果圖真的會跟著訪客操作即時變化，才保留瀏覽器端 Mermaid。

SVG、PNG，還是瀏覽器端 Mermaid？

先看圖的用途，不要先看工具名稱。選錯格式，就像拿海報字體去印名片：不是不能用，只是會有點委屈。

情境	建議	取捨
一般流程圖、架構圖	build-time SVG	線條與文字縮放清楚；仍要檢查文字大小與對比
固定像素圖片、社群分享、不想處理 SVG	build-time PNG	瀏覽器處理單純；放大可能變糊，檔案也可能較大
圖會因操作即時改變	瀏覽器端 Mermaid	保留互動，但要負擔下載、解析與執行 JavaScript
想把圖直接放進 HTML	build-time inline SVG	少一次圖片請求；HTML 變大，也要審查 SVG 內容

多數教學文章先選 SVG。若你的分享流程、圖片處理或內容系統更適合 PNG，也可以在同一次 build 產出 PNG。重點不是「PNG 永遠比較快」，而是不要讓每個頁面都執行整套繪圖 library。

若 Vite 出現 chunk 過大警告，先確認是不是 Mermaid 造成的。build.chunkSizeWarningLimit 預設 500 kB，只是警告門檻，調高只會讓終端機安靜，不會讓下載變快。固定圖改走 build-time 匯出；只有少數頁面需要互動圖時，再用 import('mermaid') 延遲載入並限制在需要的頁面。最後用 Network 和 Lighthouse 確認：不看圖的頁面，不應再載入 Mermaid chunk。

第一步：準備 Mermaid 原始檔

例如建立 src/diagrams/publish-flow.mmd：

flowchart TD
  A[寫文章] --> B{檢查}
  B -->|通過| C[Eleventy build]
  B -->|未通過| A
  C --> D[輸出靜態網站]

.mmd 是圖表的原始碼。它像食譜；SVG 或 PNG 才是端上桌的蛋糕。讀者通常只需要蛋糕，不需要一起下載烤箱。

第二步：用 Mermaid CLI 匯出 SVG 或 PNG

Mermaid 官方 CLI 的套件名稱是 @mermaid-js/mermaid-cli，命令名稱是 mmdc。可以全域安裝：

npm install -g @mermaid-js/mermaid-cli
mmdc -i "src/diagrams/publish-flow.mmd" -o "src/assets/diagrams/publish-flow.svg"
mmdc -i "src/diagrams/publish-flow.mmd" -o "src/assets/diagrams/publish-flow.png"

或者裝在專案內，讓本機和 CI 使用同一套依賴：

npm install --save-dev @mermaid-js/mermaid-cli
./node_modules/.bin/mmdc \
  -i "src/diagrams/publish-flow.mmd" \
  -o "src/assets/diagrams/publish-flow.svg"

mmdc 會依輸出副檔名產生 SVG、PNG 或 PDF。也可以在輸出時指定主題與透明背景：

mmdc -i input.mmd -o output.png -t dark -b transparent

網站有深色模式時要多留意：SVG 能縮放，不代表它會自動換成深色配色。需要時在 build 時產生 light／dark 兩份，或固定一套在兩種背景都看得清楚的主題。

第三步：讓 Eleventy 複製圖檔並嵌入頁面

如果圖片放在 src/assets/diagrams/，在 eleventy.config.js 加入 passthrough copy：

export default function (eleventyConfig) {
  eleventyConfig.addPassthroughCopy({
    "src/assets/diagrams": "assets/diagrams"
  });
}

這會把來源目錄複製到輸出目錄的 assets/diagrams。接著，文章或模板可以用普通 HTML 顯示圖片：

<figure class="diagram">
  <img
    src="/assets/diagrams/publish-flow.svg"
    alt="發布流程：寫文章後先檢查；通過才執行 Eleventy build，失敗則回到修改文章。"
    width="900"
    height="520"
    loading="lazy"
    decoding="async">
  <figcaption>圖一：文章從檢查到 Eleventy build 的流程。</figcaption>
</figure>

如果 Markdown 設定允許原始 HTML，直接放上面的 <figure> 即可。這裡要放的是 <img src="...">，不是 <div class="mermaid">。後者只是標記，仍需要 Mermaid JavaScript 在瀏覽器把它畫出來。

若 Markdown 會過濾 HTML，可改用 Nunjucks／WebC layout 或 shortcode 輸出同一段 HTML。不要為了繞過過濾器，就把所有內容無條件標成 safe。

alt 應描述讀者從圖中需要知道的結論或流程，不要只寫「流程圖」。如果正文已完整說明同一個流程，圖片可以用 alt=""，避免螢幕閱讀器重複朗讀——但正文不能因此消失。不要只靠顏色區分成功與失敗；把差異寫在節點文字、箭頭標籤或正文裡。

第四步：讓圖片在手機上不拆台

圖片 CSS 可以先從這個版本開始：

.diagram {
  max-width: 100%;
  margin: 2rem 0;
}

.diagram img {
  display: block;
  width: 100%;
  height: auto;
  max-width: 100%;
}

.diagram figcaption {
  margin-top: 0.5rem;
  color: var(--muted, #666);
}

width 和 height 要填輸出圖片的實際像素尺寸。瀏覽器可以先依比例保留空間，降低圖片載入時內容跳動；如果比例填錯，反而可能失真或預留錯誤空間。

寬流程圖在手機上常見兩種結果：

圖縮到看不清楚：改成較短的縱向流程。
圖不能再縮：提供原尺寸圖片連結，讓讀者自行放大查看。

如果有不同寬度或解析度版本，再考慮 <picture> 和 srcset。不要把一張超大 PNG 無條件送給所有裝置。

上線前檢查清單

[ ] .mmd 與輸出的圖片都有納入版本控制，或 build 能穩定重建。
[ ] mmdc 固定在專案 dev dependency，避免 CI 和本機產出不同。
[ ] 輸出路徑與 <img src> 在開發伺服器、正式站與子路徑部署都正確。
[ ] Light／dark mode 下文字與背景都有足夠對比。
[ ] build 後確認不看圖的頁面沒有載入 Mermaid chunk。

結語

固定圖先匯出，互動圖才在需要時載入 Mermaid。下一次新增 Mermaid 圖時，用 mmdc 產出 SVG 或 PNG，放進 Eleventy 的 passthrough asset，再用帶有 alt、尺寸和圖說的 <figure> 顯示。先改一張圖，再看 build 與 Network 數據。

參考資料

Mermaid CLI 官方 README — 官方 CLI 安裝、mmdc 參數，以及 SVG／PNG／PDF 輸出。
Mermaid CLI 官方文件入口 — Mermaid CLI 文件入口。
Eleventy Passthrough File Copy — addPassthroughCopy 的來源與輸出路徑。
Vite Build Options — chunkSizeWarningLimit 的預設值與用途。
MDN：<figure> — figure、figcaption 與語意結構。
MDN：HTML images — img、alt 與圖片可及性。
MDN：Understanding and setting aspect ratios — 圖片尺寸與版面空間預留。

什麼是 PHP？入門指南：用途、市占與 vs Node.js／Python

2026-08-29T00:00:00Z

PHP（PHP: Hypertext Preprocessor） 是一種在伺服器端執行的開源腳本語言，主要用來產生動態網頁。瀏覽器收到的是 PHP 執行後的 HTML；資料庫查詢、登入驗證、表單處理，多半在伺服器上完成，不會把原始碼直接送到使用者電腦。

「PHP 已死」這句話聽了十多年，但 W3Techs 在 2026 年仍顯示約 70.5% 的已知伺服器端語言網站使用 PHP；WordPress 約佔全站 41.2%。若你的目標是架站、維護 CMS 或接 Laravel 後端，PHP 仍是務實選項。

快速參考

項目	說明
PHP 是什麼	伺服器端腳本語言，在伺服器產生 HTML 再送給瀏覽器
常見用途	WordPress／Drupal、電商、REST API、表單與檔案處理
還值得學嗎	架站、CMS、Laravel 路線 → 是；AI／資料科學主力 → 優先 Python
vs Node.js	PHP 強在 CMS 生態；Node 強在即時 API 與 JavaScript 全端
怎麼開始	Herd 或 `php -S` + PHP 新手入門

PHP 的用途：工程師實際在做什麼？

PHP 工程師的典型工作包含：

後端業務邏輯、資料庫設計與查詢
REST API、Webhook、第三方服務整合
WordPress 主題／外掛，或 Laravel／Symfony 應用
效能調校、資安（XSS、CSRF、SQL Injection）與部署維運

實務技能組合：

PHP 8 + Composer 依賴管理
SQL（MySQL／MariaDB／PostgreSQL）
HTTP、REST、基本資安
Git
至少一種框架或 CMS（Laravel 或 WordPress）

職涯方向可往資深後端、全端、技術主管或接案維護站發展。台灣職缺可在 104 等平台搜「PHP」「Laravel」「WordPress」比對當下行情。

最小範例：5 分鐘跑起來

<?php
echo '<h1>Hello PHP</h1>';

存成 index.php，用內建伺服器執行：

php -S localhost:8000

開啟 http://localhost:8000 就是最小的動態網頁。

和瀏覽器 JavaScript 的差別：

	PHP	瀏覽器端 JavaScript
執行位置	伺服器	使用者裝置／瀏覽器
典型工作	資料庫、權限、API、產生 HTML	互動、動畫、SPA
部署	虛擬主機／VPS／容器皆常見	隨頁面下載

JavaScript 也能在後端跑（Node.js），所以「語言名稱 ≠ 前後端」；PHP 則主要以網站後端與伺服器端腳本為人熟知。

為什麼還有人用 PHP？

市占與生態

伺服器端語言：PHP 約 70.5%（W3Techs，2026-08）
CMS：WordPress 約佔全站 41.2%（W3Techs，2026-08）

這些是會每日變動的調查數字，分母是「被 W3Techs 辨識出來的網站」，不是整個網路的戶口普查。市占高不代表「最適合每個專案」，但代表主機支援、外掛、教學、接案需求都還在。

主機與上線成本

許多虛擬主機提供 PHP 與資料庫，部署傳統網站不必先組一整套應用程式平台。延伸：免費 SSL、Herd 本機環境。

現代 PHP 已不是「把 HTML 跟邏輯攪在一起」

PHP 8 系列加入 Named arguments、Union types、Attributes、Readonly 等現代語法。主流框架（Laravel、Symfony）搭配 Composer，讓大型專案比較容易維持結構。

什麼時候不該硬選 PHP

即時協作、WebSocket 重度應用 → 可優先評估 Node.js
資料科學、機器學習主力 → 通常優先 Python
純靜態內容、極致效能與低維護 → 靜態網站生成器／11ty

PHP vs Node.js vs Python：怎麼選

面向	PHP	Node.js	Python（Django／Flask）
架站／CMS	WordPress 生態成熟	常需自組或採 Headless	可，常見於 Django 等框架
共享主機支援	常見	取決於主機商	取決於主機商
即時應用	可做，非傳統強項	強	中
AI／資料分析	弱	中	強
學習曲線（網站）	低～中	中（非同步思維）	中
常見使用情境	CMS、傳統網站、後端	JavaScript 全端、即時服務	資料處理、後端、AI 原型

實務建議：

要維護或客製 WordPress、接中小企業站 → 學 PHP
要做 SPA + API、即時功能 → Node.js（或 PHP API + 前端框架）
要做資料管線、AI 原型 → Python，網站可另選

PHP 8.x 你該知道的新特性

PHP 8.0–8.3

Named arguments、union types、match、attributes
Constructor property promotion
Readonly properties／classes
#[\Override]（8.3）

PHP 8.4–8.5 值得關注

依 PHP 8.5 官方發布公告：

Pipe operator |>：把巢狀呼叫改成由左到右的資料流
內建 URI extension：依 RFC 3986／WHATWG 解析 URL
clone() 搭配屬性更新：方便 readonly／value object 的 with-er 模式
#[\NoDiscard]：提醒呼叫端不要忽略重要回傳值

<?php
$result = $input
	|> trim(...)
	|> strtolower(...)
	|> htmlspecialchars(...);

正式環境升級前，請對照框架支援與 PHP 官方支援版本表。PHP 7 已不在支援清單內，正式環境應規劃升級到 PHP 8.x。

怎麼開始：環境與學習路徑

本機環境

平台	建議
macOS	Herd（最省事）或 Homebrew `brew install php`
Windows	Herd for Windows
只要試玩	官方二進位 + `php -S`

五分鐘動態網頁範例

<?php
declare(strict_types=1);

$name = $_GET['name'] ?? '訪客';
?>
<!DOCTYPE html>
<html lang="zh-Hant">
<head>
	<meta charset="UTF-8">
	<title>Hello</title>
</head>
<body>
	<h1>你好，<?= htmlspecialchars($name, ENT_QUOTES, 'UTF-8') ?></h1>
</body>
</html>

重點習慣：

開啟 declare(strict_types=1);
輸出到 HTML 前做跳脫（防 XSS）
密碼用 password_hash()／password_verify()

建議學習順序

語法與陣列 → PHP 新手入門練習
類別與物件 → Class／Object、存取修飾符
例外處理 → try catch
依賴管理 → Composer
設計原則 → SOLID
選一條產品路：WordPress 外掛／主題，或 Laravel 專案

常見問題

Q：PHP 是什麼語言？
A：開源的伺服器端腳本語言，專為網頁開發設計，在伺服器執行後產生 HTML 等內容送給瀏覽器。

Q：現在才學 PHP 會不會過時？
A：若目標是架站、WordPress、中小企業維護或 Laravel，PHP 仍是合理選項。若目標是 AI 研究，通常應以 Python 為主。

Q：一定要先學完 OOP 才能碰 WordPress 嗎？
A：不必。可先做主題／小外掛建立回饋，再回頭補物件導向。

Q：和靜態站怎麼選？
A：內容少、更新不頻繁、要極致速度與低維護 → 靜態站（本站即 11ty）。要後台、會員、大量編輯者 → PHP／CMS 仍合理。

結語

學 PHP 的理由很務實：生態還在、主機選擇多、WordPress／Laravel 仍有大量使用情境，語言本身也持續更新到 8.5。先掌握「伺服器端動態網頁」這個心智模型，再依目標選 CMS 或框架，比糾結「哪種語言最潮」有用。

下一步：

裝好環境（Herd 或 Homebrew）
跑完 10 個 PHP 練習
決定路線：WordPress 實戰，或 Laravel 入門

參考資料

TypeScript 入門教學：零基礎快速上手（tsc 安裝＋tsconfig 速查）

2026-08-29T00:00:00Z

TypeScript 是 JavaScript 的語法超集：合法 JS 幾乎都能放進 .ts 檔，同時多了型別系統與編譯期檢查，讓錯誤在寫程式時就被抓出，而不是等到使用者按下按鈕才尖叫。瀏覽器與 Node.js 最終仍執行 JavaScript，所以 .ts 通常要先經 TypeScript 編譯器（tsc） 轉成 JS 再執行——型別資訊留在開發階段，不會原封不動出現在輸出檔裡。

這篇帶你在 macOS 完成 TypeScript 入門全流程：安裝 Node.js、tsc 安裝、tsconfig.json 設定、編譯第一支程式，並比較 Node.js、ts-node、Playground、Deno 與 Bun 幾種常見執行方式。

快速參考

項目	說明
TypeScript 是什麼	JS 超集 + 靜態型別檢查，輸出仍是 JavaScript
tsc 安裝	`npm install --save-dev typescript`，執行用 `npx tsc`
tsconfig 初始化	`npx tsc --init` 產生 `tsconfig.json`
編譯專案	`npx tsc` → 輸出到 `dist/`；只檢查型別：`npx tsc --noEmit`
不想裝環境	TypeScript Playground 線上試寫
Node.js 安裝	Homebrew 教學的 `brew install node`，或官方下載
替代執行環境	ts-node（開發腳本）、Deno／Bun（內建 TS 支援）

TypeScript 是什麼？

一句話：TypeScript = JavaScript + 型別。它不是把 JS 重新發明一遍，而是在你熟悉的語法上加上型別註記、interface、泛型等工具，並由 tsc 在編譯時檢查型別是否一致。

實務上，多數團隊會把 .ts 編譯成目標環境能跑的 JS（例如 ES2022），再交給 Node.js 或打包工具處理。好處是重構時編譯器會提醒你哪裡漏改，IDE 也能提供更準確的自動完成——比靠 console.log 考古快多了。

建立 TypeScript 開發環境

先裝 Node.js，再在專案內安裝 TypeScript。把 tsc 裝在專案裡（而非全域），版本比較好固定，也比較不會遇到「在我電腦明明可以」的經典劇情。

安裝 Node.js

從 Node.js 官方網站下載，或用 Homebrew：

brew install node

確認可用：

node --version
npm --version

安裝 TypeScript（tsc）

建立專案並初始化：

mkdir typescript-demo
cd typescript-demo
npm init -y

把 TypeScript 裝成開發依賴——這就是 tsc 安裝的標準做法：

npm install --save-dev typescript

pnpm 使用者：

pnpm add --save-dev typescript

專案內的 tsc 不會自動變成全域命令，請透過 npx（或 pnpm exec）執行：

npx tsc --version

初始化 `tsconfig.json`

tsconfig.json 告訴編譯器要處理哪些檔案、輸出什麼格式的 JS。執行：

npx tsc --init

入門可先採用這份精簡設定：

{
	"compilerOptions": {
		"target": "ES2022",
		"module": "NodeNext",
		"moduleResolution": "NodeNext",
		"strict": true,
		"outDir": "dist"
	},
	"include": ["src/**/*.ts"]
}

重點三項：

target：輸出的 JavaScript 語法版本
module / moduleResolution：依 Node.js 現代模組規則解析
strict: true：開啟嚴格型別檢查，編譯期能抓出更多問題

實際專案會依 Node 版本與建置工具調整；上面這份適合作為現代 Node.js 的入門起點。

寫出並編譯第一支 TypeScript 程式

建立 src/hello.ts：

const message: string = 'Hello, TypeScript!';

console.log(message);

編譯：

npx tsc

輸出會依照 tsconfig.json 放到 dist/。執行產生的 JS：

node dist/hello.js

若把字串傳給需要數字的函式，tsc 會在編譯時報錯——這就是型別檢查的價值，比執行時才發現少掉幾根頭髮。

`tsc` 常用指令

指令	用途
`npx tsc`	依 `tsconfig.json` 編譯整個專案
`npx tsc --noEmit`	只檢查型別、不產生輸出（適合 CI）
`npx tsc src/hello.ts`	編譯單一檔案（可能不完全套用專案設定）

正式專案建議讓 tsconfig.json 管理編譯範圍，執行不帶檔名的 npx tsc，行為最一致。

執行 TypeScript 的幾種方式

完成編譯後，最單純的路線是 Node.js 跑輸出的 JS。也有適合不同情境的工具——重點不是哪個最潮，而是哪個適合你的專案。

使用 Node.js

Node.js 執行的是 JavaScript。入門建議先 tsc 編譯再執行：

npx tsc
node dist/hello.js

使用 ts-node

ts-node 讓你在開發時直接執行 .ts 檔，適合快速測試與腳本；正式部署仍依專案建置流程：

npm install --save-dev ts-node typescript
npx ts-node src/hello.ts

TypeScript Playground

不想裝任何東西？TypeScript Playground 是線上沙盒，可貼程式碼、看型別錯誤與編譯結果。先在 Playground 把概念煮熟，再搬回專案，通常比直接在正式環境亂加鹽安全。

Deno

Deno 內建 TypeScript 支援，不需先跑 tsc：

// hello.ts
console.log('Hello from Deno!');

deno run hello.ts

Deno 是獨立執行環境，請依官方文件安裝，不要用 npm install -g 取代。

Bun

Bun 同樣能直接執行 .ts：

// hello.ts
console.log('Hello from Bun!');

bun run hello.ts

Bun 也是獨立執行環境，不是用 pnpm add bun -g 取得的 npm 套件。

常見 FAQ

TypeScript 跟 JavaScript 有什麼差別？

TypeScript 在 JavaScript 語法上加入型別系統；合法 JS 通常也是合法 TS。差別在開發階段多了型別檢查，執行時仍是 JavaScript。

需要全域安裝 `tsc` 嗎？

不需要。在專案內 npm install --save-dev typescript，用 npx tsc 即可。全域安裝容易造成版本不一致，團隊協作時尤其麻煩。

`tsconfig.json` 的 `strict` 要開嗎？

入門建議開 strict: true。一開始型別錯誤多一點，但長期能避免更多隱性 bug。若遷移舊 JS 專案，可暫時關閉部分選項，再逐步收緊。

用 Homebrew 可以裝 TypeScript 嗎？

Homebrew 適合裝 Node.js（brew install node），TypeScript 則建議用 npm／pnpm 裝在專案裡。這樣每個專案能鎖定自己的 typescript 版本，CI 與本機行為也一致。

Deno 或 Bun 還需要 `tsc` 嗎？

Deno 與 Bun 能直接執行 .ts，開發腳本時很方便。但若你要產出給 Node.js 或瀏覽器用的 JS、或需要嚴格控制輸出格式，仍建議用 tsc（或 esbuild、swc 等建置工具）編譯。

接下來可以學什麼？

你已完成 TypeScript 入門的基本流程：

安裝 Node.js 與專案內的 TypeScript
用 tsconfig.json 設定編譯行為
用 tsc 檢查並輸出 JavaScript
視情境選擇 Node.js、ts-node、Deno 或 Bun

下一步可學基本型別、函式型別、interface、泛型，以及在既有 JS 專案中逐步加入 TypeScript。先從能讓程式更好理解的型別開始，不必一口氣把整本手冊吞下去——那樣連編譯器都會替你噎到。

參考資料

TypeScript 官方網站：語言介紹與最新文件
TypeScript Handbook：型別系統與語言功能教學
TypeScript tsconfig.json 參考：編譯器選項查詢
Node.js 官方下載：Node.js 安裝方式
Deno 安裝文件
Bun 安裝文件

TOC（Table of Contents）是什麼？文章目錄做法＋SEO 實務（WordPress／11ty）

2026-08-29T00:00:00Z

TOC（Table of Contents，文章目錄） 是把章節標題變成頁內連結的導覽區塊，讓讀者先看地圖、再跳到需要的段落。長文沒有目錄，讀者就得一路往下捲，像在網頁裡玩「找不同」——不同的是重點到底藏在哪裡。

這篇讀完，你會知道 TOC 對閱讀體驗與 SEO 能幫多少、如何用原生 HTML 做出穩定錨點，以及靜態網站、JavaScript 和 WordPress 各自適合什麼做法。

快速參考

項目	說明
TOC 是什麼	章節標題的頁內導覽清單，通常連到 `#錨點`
對 SEO 有幫助嗎	沒有保證加分；清楚的標題結構 + 可爬取的 `<a href>` 才是重點
靜態站（11ty）	建置時產生 HTML，本站用 `[[toc]]`
動態站	JS 掃描 H2/H3，或 WordPress TOC 外掛
必備條件	每個目標標題有唯一 `id`，TOC 的 `href` 與之對應

TOC 對讀者與 SEO 各幫什麼？

讀者體驗（主要價值）

一份好的 TOC 至少有三個用途：

讓讀者快速掃過文章範圍，判斷內容是否值得讀
讓讀者直接跳到需要的章節，少滑幾個螢幕
讓讀者複製 網址#錨點，把特定段落分享給別人

SEO：務實版

Google 沒有保證「加入 TOC 就會排名更高」。比較可靠的做法：

用一個 H1，再用 H2、H3 分出章節
使用真正的 <a href="#section-id">，而不是只有 JavaScript 點擊
連結文字描述目標內容，不要全部叫「點這裡」

Google 文件指出，通常需要有 href 的 <a> 元素，搜尋系統才容易擷取連結。搜尋結果是否顯示頁內跳轉連結，仍由系統自動判斷，不能手動保證。

另外，頁內跳轉（jump link）和 sitelinks 不是同一件事。Google 已於 2024 年 11 月 21 日起移除搜尋結果中的 sitelinks search box，但這不等於一般 sitelinks 或頁內錨點消失。

先把標題和錨點做好

TOC 只是導航，不會替混亂的內容結構打掃房間。實作前先確認：

一篇文章有一個主要 H1
大章節用 H2，小節用 H3，層級不要從 H2 突然跳到 H4
每個目標標題都有唯一且穩定的 id
TOC 的 href 必須和目標標題的 id 完全相同

<article>
	<h1>文章標題</h1>
	<nav aria-label="文章目錄">
		<ol>
			<li><a href="#intro">簡介</a></li>
			<li><a href="#setup">開始實作</a></li>
		</ol>
	</nav>
	<section id="intro">
		<h2>簡介</h2>
		<p>這裡是文章簡介。</p>
	</section>
	<section id="setup">
		<h2>開始實作</h2>
		<p>這裡是實作內容。</p>
	</section>
</article>

id 不能在同一頁重複。若兩個標題都叫「結語」，產生器需處理碰撞，例如輸出 結語 和 結語-1。

三種 TOC 實作方式

方式	適合情境	優點	注意
A. 建置時靜態產生	11ty、Hugo、Astro	無 JS 依賴、SEO 友善、版面穩定	需在建置流程設定
B. JavaScript 動態掃描	SPA、需摺疊／高亮目前章節	互動彈性高	不應成為唯一導航來源
C. WordPress 外掛／區塊	WP 部落格	免寫 code	慎選，避免載入過多腳本

A. 建置時產生靜態 TOC（11ty）

Markdown 內文放標記：

[[toc]]

建置工具讀取標題，輸出 HTML 清單與錨點。本站 [[toc]] 由 markdown-it-table-of-contents 處理，目前設定只列出 H2。H3 會出現在正文，但不會自動列進目錄——這是建置設定，不是 Markdown 的宇宙定律。

B. JavaScript 動態掃描標題

適合需要摺疊目錄、標示目前章節的頁面。建議用 createElement 而非 innerHTML，避免把標題文字當 HTML 解析：

<nav id="table-of-contents" aria-label="文章目錄">
	<h2>目錄</h2>
	<ol id="toc-list"></ol>
</nav>

const tocList = document.querySelector('#toc-list');
const headings = document.querySelectorAll('article h2');
const usedIds = new Set();

headings.forEach((heading, index) => {
	let id = heading.id || `section-${index + 1}`;
	let suffix = 1;

	while (usedIds.has(id)) {
		id = `${heading.id || `section-${index + 1}`}-${suffix}`;
		suffix += 1;
	}

	heading.id = id;
	usedIds.add(id);

	const item = document.createElement('li');
	const link = document.createElement('a');
	link.href = `#${id}`;
	link.textContent = heading.textContent;
	item.append(link);
	tocList.append(item);
});

若內容在這段程式執行後才載入，需把建立目錄的時機放到內容完成後。

C. WordPress 外掛或區塊

選外掛時先看：

能否排除不想出現的標題（如「參考資料」）
輸出是否為真正的 <a href="#...">
能否處理重複標題並產生唯一 ID
手機版是否容易操作，且不載入不必要的腳本

發布前檢查清單

[ ] H1、H2、H3 層級符合內容結構
[ ] 每個 TOC 連結都有 href="#..."，目標標題有唯一 id
[ ] 目錄文字和目標標題一致
[ ] 靜態站優先建置時輸出；JS 只負責增強
[ ] 目錄容器有 nav 和 aria-label
[ ] 手機版容易收合或掃讀
[ ] 已實際點過每個連結，也測過重新整理後的 #錨點

常見問題

TOC 一定要放在文章最前面嗎？

長文通常放在引言後最方便掃描；桌面版也可固定在側欄。重點是目錄在 HTML 中真實存在，且連結能直接跳到內容。

中文標題的 `id` 怎麼產生？

可用中文 ID、拼音或其他穩定 slug。重點是規則穩定、結果不重複，且 TOC 與標題共用同一套規則。本站允許中文 slug，TOC 與標題 ID 共用自訂 slugify。

要不要把 H3 也放進目錄？

看文章長度。小節很多時，H3 會讓目錄變成另一篇文章；小節較少時，列出 H3 能幫助定位。本站目前只輸出 H2；若要 H3 目錄，需調整建置設定。

TOC 會不會和外掛衝突？

可能。最常見是兩個工具同時替標題產生 ID，導致連結失效。建議由單一工具負責 ID，建置後檢查 HTML 是否有重複 ID。

結語

TOC 的核心價值：讓讀者更快找到重點，也讓頁面結構更容易被理解。靜態站優先選建置時產生的原生 HTML；需要高亮、摺疊時再讓 JavaScript 上場；WordPress 則慎選外掛。

延伸閱讀：11ty 入門、PageSpeed 與 Core Web Vitals。

參考資料

Tab Manager Plus 教學：Chrome 分頁管理終極指南

2026-08-29T00:00:00Z

你是不是也有過這種經驗：只是想找一個分頁，卻得在分頁列裡滑到天荒地老，最後連自己要找什麼都忘了？分頁開太多時，瀏覽器的工作列看起來就像咖啡店打烊前的桌面——每一杯都像重要的，但沒人知道哪一杯是你的。

這篇會介紹兩款 Chrome 分頁管理擴充功能：Tab Manager Plus 與 Tab Manager Auto。讀完後，你會知道它們各自適合什麼情境、能處理哪些工作，以及如何選擇；不必再用「關掉全部分頁，靠記憶重新開始」這種有點悲壯的整理法。

先認識 Chrome 的分頁整理方式

在開始比較擴充功能前，先釐清問題會比較好。Chrome 本身已經支援分頁群組，可以替群組命名、選顏色、收合分頁，也能把分頁拖進群組。若你只需要偶爾整理幾個主題，內建功能可能已經夠用。

但當你同時開著工作、研究、購物和一堆「等等再看」的分頁時，手動拖曳就會變成另一種工作。這時，擴充功能的價值在於幫你快速找到分頁，或按照規則自動整理。

Tab Manager Plus for Chrome：快速找回分頁

它適合什麼情境？

Tab Manager Plus 的核心工作很直接：把目前開啟的分頁與視窗集中列出，讓你用標題或網址搜尋，而不是一直在分頁列裡左右滑。Chrome Web Store 的說明也把「快速尋找分頁、查看所有視窗、找出重複分頁、限制每個視窗的分頁數」列為主要功能。

換句話說，它比較像一個「分頁搜尋器」，而不是替你決定所有分頁要怎麼生活。這種工具很適合習慣自己分類、但不想自己找分頁的人。

主要功能

集中查看：一次查看目前視窗中的分頁與視窗，少一點盲目搜尋。
搜尋標題與網址：開啟管理介面後直接輸入關鍵字，縮小結果範圍。
標記重複分頁：找出重複頁面後，再決定要保留、移動或關閉哪些分頁。
批次管理：依商店說明，可選取多個分頁，進行移動、建立或刪除等操作。
限制分頁數量：可以設定每個視窗的分頁上限；達到限制後，擴充功能會依其設定處理後續分頁。
隱身模式支援：這不是安裝後就自動開啟的功能。需要到 Chrome 的擴充功能管理頁，針對該擴充功能開啟「允許在無痕模式中使用」。

如果你的痛點是「我明明開過，但它現在在哪裡」，Tab Manager Plus 通常比自動分組更對症。它不會替你安排人生，只負責把分頁叫到你面前——這已經比很多會議主持人可靠了。

Tab Manager Auto：讓分頁按網域自動分組

它的整理方式

Tab Manager Auto 的方向不同。根據 Chrome Web Store 的功能說明，它會依分頁的來源網域自動分組，也能把最近使用的分頁排到該群組較前面的位置，並允許使用者自訂分組。

想像你開了 GitHub、文件網站和幾個測試頁面。你不必每次都手動拖曳，工具會嘗試依照網域把相關分頁集合起來。分頁終於學會排隊了，只是它不會幫你買咖啡。

主要功能

依網域分組：相同來源網域的分頁會被安排到同一組。
依最近使用狀態排序：商店說明指出，最後使用的分頁會被移到所屬群組較前的位置。
自訂群組：除了自動整理，也可以建立自己的分頁群組。

這款工具適合「我不想每天整理，但希望分頁至少不要散落各處」的人。不過，自動化不代表永遠符合你的工作習慣；如果不同專案使用同一個網域，最後仍可能需要手動調整。

Tab Manager Plus 與 Tab Manager Auto 怎麼選？

兩款工具不是誰一定比較強，而是解決的問題不同。先問自己：「我最常浪費時間在找分頁，還是整理分頁？」

需要搜尋與控制：選 Tab Manager Plus

分頁很多，常常找不到某一頁。
需要跨多個視窗搜尋與移動分頁。
想自己決定哪些分頁要保留或關閉。
偶爾才整理一次，不希望工具一直改變分頁配置。

需要自動分組：選 Tab Manager Auto

你常同時開啟同一網站的多個分頁。
希望分頁依網域自動集合。
可以接受偶爾檢查自動分組結果。
想把手動拖曳的時間交給工具處理。

兩者一起用可以嗎？

技術上可以同時安裝，但不代表一定要同時啟用所有自動功能。Tab Manager Auto 負責按規則整理，Tab Manager Plus 負責搜尋與批次管理；如果兩者同時修改分頁位置，結果可能和你的預期不同。

建議先安裝一款，使用幾天後再決定是否需要另一款。擴充功能越多不一定越有效率，瀏覽器不是自助餐盤，拿太多最後只會端不穩。

使用前的兩個提醒

第一，安裝擴充功能前，請查看它要求的權限與開發者資訊，只安裝你信任的工具。Chrome 官方也提醒，擴充功能可能需要讀取或變更你造訪網站上的資料，因此權限不是可以一路按「同意」帶過的小字。

第二，若要在無痕模式使用擴充功能，請開啟 chrome://extensions，找到擴充功能並進入「詳細資料」，再打開「允許在無痕模式中使用」。無痕模式不會讓擴充功能自動獲得這項權限；而且無痕視窗的工作階段資料也有不同的保存規則，別把它當成普通視窗的隱形斗篷。

結語

如果你最常說的是「那個分頁到底在哪裡」，先試 Tab Manager Plus；如果你更想要「分頁自己按網域排好」，可以試 Tab Manager Auto。也可以先使用 Chrome 內建的分頁群組，確認自己的整理習慣後，再決定是否需要擴充功能。

分頁管理的目標不是把分頁列整理得像樣品屋，而是讓你下一次找資料時，真的找得到。整理完記得喝口咖啡——分頁可以自動分組，咖啡目前還不會。

參考資料

Tab Manager Plus for Chrome｜Chrome Web Store：查閱擴充功能列出的搜尋分頁、重複分頁、視窗管理與分頁限制等功能。
Tab Manager Auto｜Chrome Web Store：查閱依來源網域自動分組、最近使用分頁排序與自訂分組的功能說明。
安裝及管理擴充功能｜Google Chrome 說明：查閱安裝擴充功能、檢查權限，以及開啟無痕模式使用權限的步驟。
管理 Chrome 中的分頁｜Google Chrome 說明：查閱 Chrome 內建分頁群組、命名、收合與同步等功能。

Statamic 教學：Flat-file CMS 入門 vs WordPress／11ty

2026-08-29T00:00:00Z

WordPress 功能很多，這是優點，也是有時讓人打開後台就先想泡咖啡的原因。如果你想要一個能用控制面板管理內容、又能把內容和模板放進 Git 的 CMS，Statamic 值得認真看一眼。它把 CMS 的方便，和檔案型工作流程放在同一張桌上——咖啡則放旁邊，避免灑到 YAML。

這篇會帶你認識 Statamic 的 flat-file 模式、用 Laravel Herd 建立本機環境，接著做出首頁、文章集合、文章列表與可重複使用的模板片段。讀完後，你也會知道它和 WordPress、11ty 的定位差在哪裡，以及什麼情況適合選它。

Statamic 是什麼？

Statamic 是建立在 Laravel 上的內容管理系統。它預設使用 flat-file 模式：內容、設定與模板可以用 YAML、Markdown、Antlers 模板等檔案管理，而不是一開始就要求你準備資料庫。

「檔案型」不代表它只有編輯器。Statamic 仍然提供控制面板、內容集合、欄位藍圖、路由和模板系統；需要時，也能改用資料庫儲存。這種設計的重點，是先讓專案保持簡單，等需求真的長大再決定資料儲存方式。

換句話說，Statamic 不是把 CMS 藏在資料庫裡，而是讓你可以在控制面板和程式碼編輯器之間自由切換。內容可以給編輯者管理，結構和模板則可以交給 Git 追蹤。這比在資料庫裡尋找某段設定，少一點考古，多一點開發。

外掛與 Starter Kits

Statamic 有外掛與 Marketplace，可以依專案需求增加功能。不過，選外掛前仍然要先確認相容版本、維護狀態和授權方式；「有外掛」不等於「所有外掛都該裝」。外掛裝太多，網站會像咖啡加了十種糖漿：不是不能喝，但已經忘記原本是什麼味道。

Starter Kits 是什麼？

Starter Kits 是預先準備好的網站起點，通常包含內容結構、模板、樣式和功能。它們比較像「可以繼續修改的專案骨架」，不是 WordPress 那種套上去就結束的主題。每個 Kit 可以有自己的內容模型與設計，因此使用前要先看清楚它包含哪些檔案和功能。

第一次使用時，建議先從空白專案開始。你會比較清楚每一個集合、欄位和模板從哪裡來；熟悉後，再用 Starter Kit 加速重複性高的專案。

先準備本機開發環境

Statamic 的官方文件把 Laravel Herd 列為 macOS 和 Windows 初學者的推薦路徑。Herd 會協助準備 PHP、Composer 和本機 Web 伺服器，省下手動拼裝開發環境的步驟。

如果你已經有 PHP 和 Composer，也可以直接使用 Statamic CLI。這篇先採 Herd 路線，因為少一點環境設定，就多一點時間看網站真的跑起來。

使用 Laravel Herd

安裝 Herd 後，把專案放進 Herd 管理的目錄，再安裝 Statamic CLI：

composer global require statamic/cli

接著建立一個新專案。這個指令會啟動設定精靈，讓你選擇空白網站或 Starter Kit，並建立第一位管理者：

cd ~/Herd
statamic new try-statamic

完成後，Herd 會把專案提供在類似以下的本機網址：

http://try-statamic.test

控制面板則位於 /cp：

http://try-statamic.test/cp

看到首頁和登入畫面，就代表基本環境完成。接下來不急著安裝十個套件，我們先做一個最小的內容流程。

認識首頁與 Antlers 模板

Statamic 的預設首頁模板位於 resources/views/home.antlers.html。副檔名中的 .antlers.html 很重要：它告訴 Statamic 這是一個要由 Antlers 解析的模板，不是原封不動送出的 HTML。

最小的首頁可以先這樣寫：

<h1>歡迎光臨我的 Statamic 實驗站！</h1>

{{ content }}

{{ content }} 會放入目前頁面的內容。模板儲存後重新整理頁面，就能看到結果。Antlers 使用雙大括號，看起來像鬍子；如果模板開始長出真的鬍子，通常是熬夜太久，不是語法功能。

Layout 負責共同外框

網站的共同結構通常放在 resources/views/layout.antlers.html，例如 HTML 外框、導覽列、頁尾和資產引用。頁面模板產生的內容，會插入 {{ template_content }} 的位置：

<!doctype html>
<html lang="{{ site:short_locale }}">
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>{{ title ?? site:name }}</title>
</head>
<body>
    {{ template_content }}
</body>
</html>

你可以把 Layout 想成相框：每一頁的內容會變，外框則可以共用。這樣修改頁尾時，不必逐頁複製貼上，少一次複製，也少一次「為什麼只有這頁沒有更新」的偵探劇。

建立部落格的內容集合

在 Statamic 裡，Collection 是一組有共同結構的內容，例如文章、產品或作品集。建立 blog 集合後，文章項目會依集合設定儲存；flat-file 模式下，你可以在專案內直接找到並編輯這些 Markdown 檔案。

先規劃一個簡單的部落格：

title：文章標題
date：發布日期
author：作者
content：正文
featured_image：精選圖片

欄位不是越多越專業。先從讀者真的需要的資料開始，之後再透過 Blueprint 增加欄位。

產生文章模板

建立集合時，Statamic 可以協助產生基本模板，例如：

resources/views/blog/index.antlers.html
resources/views/blog/show.antlers.html

前者用來顯示文章列表，後者用來顯示單篇文章。若你的專案版本或設定產生了不同的檔案名稱，請以實際產生的檔案為準；模板路徑是專案設定的一部分，不要只靠截圖猜路徑。

設定日期與網址

發布日期不是每個網站都必須顯示的欄位，但部落格通常需要它來排序和呈現文章資訊。網址則由 Collection 的 route 設定決定，建議一開始保持簡單，確定內容模型後再設計更複雜的 URL。

顯示文章列表

建立第一篇文章後，就可以用 Collection Tag 讀取 blog 集合。下面的例子把最多五篇文章列在首頁：

<h1>{{ title }}</h1>
{{ content }}

<ul>
    {{ collection:blog limit="5" }}
        <li>
            <a href="{{ url }}">
                <span>{{ title }}</span>
                <time>{{ date }}</time>
            </a>
        </li>
    {{ /collection:blog }}
</ul>

collection:blog 會讀取 blog 集合，limit="5" 則限制輸出數量。這裡的 blog 是集合 handle，不是隨便取的裝飾文字；handle 打錯時，模板通常不會替你把咖啡端過來。

部落格索引頁

在 Pages 集合建立一個部落格頁面，將它設為文章列表使用的模板。resources/views/blog/index.antlers.html 可以重用前面的 Collection Tag：

<h1>{{ title }}</h1>
{{ content }}

{{ collection:blog limit="5" }}
    <a href="{{ url }}">{{ title }}</a>
{{ /collection:blog }}

單篇文章頁

單篇文章模板則負責顯示標題、日期、作者與正文：

<article>
    <h1>{{ title }}</h1>
    <p>Published on {{ date }} by {{ author:name }}</p>
    {{ content }}
</article>

{{ content }} 是文章正文，{{ author:name }} 則是讀取作者資料的寫法之一；實際欄位名稱要和你的 Blueprint 一致。

把重複內容抽成 Partial

文章列表會同時出現在首頁和索引頁。若兩邊都直接複製同一段模板，日後改一個 HTML class 就要改兩次，久了會養出兩份長得很像、脾氣卻不同的程式碼。

在 resources/views/blog/ 建立 _listing.antlers.html，底線是常見的 partial 命名約定：

<ul>
    {{ collection:blog limit="5" }}
        <li>
            <a href="{{ url }}">{{ title }}</a>
        </li>
    {{ /collection:blog }}
</ul>

頁面中再引用它：

{{ partial:blog/_listing }}

Partial 是可重用的模板片段，不是完整頁面。把列表集中管理後，首頁和索引頁就能共享同一份輸出邏輯。

加上導覽列

如果網站有 Pages 集合，可以使用 Nav Tag 產生導覽：

<nav>
    {{ nav from="pages" include_home="true" }}
        <a href="{{ url }}">{{ title }}</a>
    {{ /nav }}
</nav>

把這段放進 Layout，所有套用該 Layout 的頁面就能共用導覽列。樣式可以之後再加，先讓資料流動起來；CSS 不會因為等五分鐘而生氣，但你可能會。

用 Blueprint 增加精選圖片

Blueprint 用來定義集合或頁面的欄位。你可以在 blog 集合的 Blueprint 增加 featured_image，選擇適合圖片資產的欄位型別，並限制單篇文章的圖片數量。

設定欄位時，請分清楚「顯示名稱」和「Handle」。模板會使用 Handle，例如 featured_image。圖片的替代文字也應該在內容編輯時填好，讓無法看見圖片的讀者仍然知道它代表什麼。

在文章模板中輸出圖片時，欄位的實際回傳格式會受 Blueprint 和資產設定影響。最基本的概念如下：

<img src="{{ featured_image }}" alt="{{ featured_image:alt }}">

如果專案使用資產陣列或需要圖片轉換，請依官方 Assets 文件和實際欄位輸出調整模板，不要直接照抄一段不符合資料格式的範例。

Statamic、WordPress 與 11ty 怎麼選？

三者都能拿來做網站，但解決的問題不同：

Statamic：適合需要控制面板、內容集合、欄位藍圖，又希望內容與設定能以檔案管理的團隊。它建立在 Laravel 上，前端可以使用 Antlers，也能依專案選擇其他做法。
WordPress：適合想快速使用成熟後台、佈景主題和外掛生態的使用者。彈性很高，但網站的實際行為會取決於佈景主題、外掛和主機環境。
11ty：適合偏好 Markdown、Git 和靜態輸出的開發者。它是靜態網站產生器，不是內建內容編輯控制面的 CMS；需要多人後台時，通常要另外整合服務。

Statamic 的 flat-file 模式和 11ty 都重視檔案與版本控制，但使用感不同：11ty 偏向建置時把內容產生為靜態檔案；Statamic 則保留 CMS 的管理介面和動態應用程式能力。選擇時先問自己：編輯者需要後台嗎？內容是否需要複雜欄位？部署流程和團隊習慣是哪一種？

適合誰使用？

Statamic 適合以下情境：

內容團隊需要控制面板，但開發團隊想用 Git 管理內容結構和模板。
專案需要自訂 Collection、Blueprint、路由和前端設計。
團隊熟悉 Laravel、PHP 或希望沿用 Laravel 的開發方式。
想從 flat-file 開始，未來再依規模評估資料庫或 Headless 架構。

如果你只想寫幾篇 Markdown，並且不需要後台，11ty 可能更直接。如果你希望安裝主題、調整設定後立即上線，WordPress 的現成生態可能更省力。Statamic 的自由度很高，但自由度也代表你需要自己做一些決定；它不是「完全不用想」的 CMS，而是「可以決定要怎麼想」的 CMS。

結語

Statamic 的核心魅力，不只是「不用資料庫」這一句話，而是把 CMS、檔案型內容、版本控制和 Laravel 開發流程接在一起。從 CLI 建立專案，設定 Collection，再用 Antlers 和 Partial 組出頁面，你可以逐步理解每一層，而不是一次吞下一整套黑盒子。

先做一個小部落格，確認內容模型和模板邏輯，再考慮外掛、Starter Kit、圖片處理或部署。網站開發像手沖咖啡：水溫、比例和流程都重要，但第一杯先喝得下去，比研究半天濾杯角度更重要。

參考資料

Statamic Quick Start Guide：官方快速入門流程，涵蓋安裝、首頁、Collection 與模板。
Install Statamic with the CLI：官方 CLI 安裝需求與 statamic new 建站流程。
Install Statamic with Laravel Herd：官方 Herd 本機環境安裝說明。
Core Concepts：官方說明 flat-file 模式、內容管理與架構取捨。
Collections：官方說明 Collection、Entry 儲存方式與路由。
Antlers Templates：官方 Antlers 模板語法、檔案位置與 Layout 說明。
Starter Kits Overview：官方說明 Starter Kits 和 WordPress themes 的差異。

SOLID 原則 PHP 實戰：五大設計原則速查 + 設計模式對照

2026-08-29T00:00:00Z

寫程式不難，難的是半年後回頭看，還敢不敢改自己的程式碼。當一個類別同時算薪水、寫資料庫、寄信，甚至順便幫你煮咖啡，需求一變就會像耳機線一樣打結。這時候，SOLID 原則可以當一張設計地圖。

這篇會用 PHP 範例帶你理解 SOLID 的五個原則：它們各自想解決什麼問題、怎麼拆出比較健康的設計，以及什麼時候不必硬套。讀完後，你應該能看出程式碼「哪裡開始變胖」，也知道該從哪裡下刀。

SOLID 速查表

字母	原則	白話	違反時的症狀
S	Single Responsibility	一個類別只有一個改變的理由	改 A 功能卻壞 B 功能
O	Open/Closed	對擴充開放、對修改封閉	每加需求就改核心類別
L	Liskov Substitution	子類別可替換父類別	繼承後行為不一致
I	Interface Segregation	介面要小而專	被迫實作用不到的方法
D	Dependency Inversion	依賴抽象，不依賴具體	高層直接 new 低層實作

延伸閱讀：PHP 類別入門 · PHP 設計模式系列

SOLID 是什麼？

SOLID 是五個物件導向設計原則英文名稱的首字母：

S — Single Responsibility Principle（單一職責原則）
O — Open/Closed Principle（開放封閉原則）
L — Liskov Substitution Principle（里氏替換原則）
I — Interface Segregation Principle（介面隔離原則）
D — Dependency Inversion Principle（依賴反轉原則）

它們不是 PHP 的語法，也不是一份「照著做就永遠正確」的檢查表，而是幫助你降低耦合、控制變動範圍的思考工具。換句話說，SOLID 的重點不是把類別拆到像樂高散落一地，而是讓每個變動有比較清楚的落點。

S：單一職責原則（SRP）

單一職責原則常被簡化成「一個類別只做一件事」。這句話方向沒錯，但還不夠精準。Robert C. Martin 對 SRP 的經典說法是：一個模組應該只有一個「改變的理由」。

這裡的「職責」不是方法數量，而是誰會要求它改變。薪資規則由人資提出修改、資料庫格式由後端提出修改、畫面格式由前端提出修改；如果三種需求都集中在 Employee，它就背了太多不同的改變理由。

容易失控的寫法

class EmployeeService
{
	public function calculateSalary(Employee $employee): int
	{
		return $employee->baseSalary() + $employee->bonus();
	}

	public function save(Employee $employee): void
	{
		// 寫入資料庫
	}

	public function renderProfile(Employee $employee): string
	{
		// 組合 HTML
		return '<p>' . $employee->name() . '</p>';
	}
}

這個類別現在知道薪資規則、資料儲存和 HTML。任何一項需求變更，都可能碰到同一個檔案。類別不是不能有三個方法，而是這三個方法的變動原因彼此無關。

讓職責各就各位

class SalaryCalculator
{
	public function calculate(Employee $employee): int
	{
		return $employee->baseSalary() + $employee->bonus();
	}
}

class EmployeeRepository
{
	public function save(Employee $employee): void
	{
		// 將員工資料寫入資料庫
	}
}

class EmployeeProfileRenderer
{
	public function render(Employee $employee): string
	{
		return '<p>' . $employee->name() . '</p>';
	}
}

拆開後，薪資規則、儲存方式與顯示格式各自有清楚的責任邊界，也比較容易單獨測試。SRP 不是「每個類別只能有一個 public method」，而是「不要把不同的變動原因綁在一起」。

O：開放封閉原則（OCP）

開放封閉原則是：軟體實體應該對擴充開放，對修改封閉。意思不是原始碼永遠不能改，而是當你新增一種行為時，最好能透過新增實作來完成，避免反覆修改已經穩定的核心流程。

`if` 越長，咖啡越苦

假設結帳服務用條件判斷處理每種折扣：

function discountFor(string $memberType, int $amount): int
{
	if ($memberType === 'regular') {
		return 0;
	}

	if ($memberType === 'vip') {
		return (int) ($amount * 0.1);
	}

	if ($memberType === 'staff') {
		return (int) ($amount * 0.3);
	}

	return 0;
}

剛開始只有兩種會員，看起來很方便。等到加入生日折扣、活動折扣、合作夥伴折扣，這個函式就會變成一條需要小心穿越的 if 迷宮。迷宮本身沒有錯，但維護它通常不會讓人心情變好。

將變動的規則抽成策略

interface DiscountPolicy
{
	public function discountFor(int $amount): int;
}

final class VipDiscount implements DiscountPolicy
{
	public function discountFor(int $amount): int
	{
		return (int) ($amount * 0.1);
	}
}

final class StaffDiscount implements DiscountPolicy
{
	public function discountFor(int $amount): int
	{
		return (int) ($amount * 0.3);
	}
}

final class Checkout
{
	public function __construct(
		private DiscountPolicy $discountPolicy,
	) {
	}

	public function total(int $amount): int
	{
		return $amount - $this->discountPolicy->discountFor($amount);
	}
}

新增折扣規則時，可以新增另一個 DiscountPolicy 實作，Checkout 不必跟著修改。這就是常見的 Strategy（策略）做法，也是 OCP 的一種實現方式。

不過，OCP 不代表每一個小函式都要先抽介面。尚未出現變動點時過度抽象，反而會增加理解成本。先觀察真正會變的地方，再決定要不要抽象，通常比較務實。

L：里氏替換原則（LSP）

里氏替換原則要求：如果程式碼期待的是某個父型別或介面，那麼換成它的子型別或實作後，原本的正確性與使用方式仍然成立。

重點不是「有 extends 就算繼承成功」，而是子類別必須遵守父類別對外做出的契約。若父類別承諾「呼叫 withdraw() 會扣款」，子類別就不能突然改成「遇到某種帳戶就丟出不支援例外」，否則呼叫端就得先猜對方是哪一種物件。

會讓呼叫端踩雷的繼承

class Bird
{
	public function fly(): void
	{
		// 飛行
	}
}

class Penguin extends Bird
{
	public function fly(): void
	{
		throw new LogicException('企鵝不會飛');
	}
}

function letBirdFly(Bird $bird): void
{
	$bird->fly();
}

letBirdFly() 接受 Bird，照它的契約自然會呼叫 fly()。傳入 Penguin 後卻必定失敗，代表這個繼承關係只是在語法上成立，在行為上卻不成立。

讓抽象符合真正能力

class Animal
{
}

interface Flyable
{
	public function fly(): void;
}

class Sparrow extends Animal implements Flyable
{
	public function fly(): void
	{
		// 飛行
	}
}

class Penguin extends Animal
{
	// 企鵝是動物，但不是 Flyable
}

這裡不是把企鵝排除在鳥類之外，而是避免對「會飛」做出錯誤承諾。設計抽象時，先問「這個型別真的能保證什麼行為？」比先問「它是不是某某的子類別？」更重要。

I：介面隔離原則（ISP）

介面隔離原則主張：不要讓使用者依賴它用不到的方法。這裡的使用者可以是實作介面的類別，也可以是呼叫該介面的其他程式碼。

一個什麼都管的介面

interface Worker
{
	public function code(): void;

	public function test(): void;

	public function cook(): void;

	public function clean(): void;
}

如果 Developer 只需要寫程式與測試，卻被迫實作 cook() 和 clean()，介面就太胖了。更麻煩的是，介面新增一個方法時，所有實作者都可能被迫同步修改。

拆成能組合的小介面

interface Coder
{
	public function code(): void;
}

interface Tester
{
	public function test(): void;
}

final class Developer implements Coder, Tester
{
	public function code(): void
	{
		// 寫程式
	}

	public function test(): void
	{
		// 執行測試
	}
}

小介面讓依賴關係更精準，也讓類別可以用組合表達能力。介面不是自助餐，不需要把所有方法都端上桌；端太多，最後通常只會剩下沒人想吃的抽象。

D：依賴反轉原則（DIP）

依賴反轉原則有兩層意思：

高層模組不應直接依賴低層模組；兩者都應依賴抽象。
抽象不應依賴細節；細節應依賴抽象。

高層模組是業務規則，例如「註冊使用者」；低層模組則可能是 MySQL、檔案系統或第三方 API。業務規則不需要知道資料是存在哪一台資料庫，才能完成自己的工作。

把具體資料庫寫死

class MySqlUserRepository
{
	public function save(string $email): void
	{
		// 寫入 MySQL
	}
}

class RegisterUser
{
	private MySqlUserRepository $repository;

	public function __construct()
	{
		$this->repository = new MySqlUserRepository();
	}

	public function handle(string $email): void
	{
		$this->repository->save($email);
	}
}

RegisterUser 自己建立 MySqlUserRepository，所以測試時很難替換成記憶體版本，未來改用其他儲存方式也得修改業務類別。

讓高層依賴抽象

interface UserRepository
{
	public function save(string $email): void;
}

final class MySqlUserRepository implements UserRepository
{
	public function save(string $email): void
	{
		// 寫入 MySQL
	}
}

final class RegisterUser
{
	public function __construct(
		private UserRepository $repository,
	) {
	}

	public function handle(string $email): void
	{
		$this->repository->save($email);
	}
}

現在 RegisterUser 只依賴 UserRepository 這個抽象，具體實作透過建構子注入。測試時可以傳入一個測試用 repository；正式環境則傳入 MySqlUserRepository。這通常也被稱為依賴注入，但要注意：依賴注入是達成解耦的一種手法，DIP 是設計原則，兩者不是同義詞。

SOLID 與設計模式怎麼分？

SOLID 是設計時的原則；設計模式則是針對常見問題整理出的解法。兩者可以互相呼應，但不是一對一的配對表。

原則	常見呼應方式	重點
SRP	Facade、Repository	把不同變動原因分開
OCP	Strategy、Decorator	新增行為時減少修改核心
LSP	多型、合約測試	子型別遵守抽象契約
ISP	小型角色介面	只依賴真正需要的能力
DIP	Dependency Injection、Factory	高層依賴抽象

例如，Factory 解決的是「物件怎麼建立」，Singleton 解決的是「限制實例數量」。它們都可能出現在某個遵循 DIP 的設計裡，但使用 Singleton 不會自動讓程式變得 SOLID；全域狀態該難測，還是會難測。

實務上怎麼使用 SOLID？

SOLID 最適合拿來處理「已經看見的變動」與「正在造成痛苦的耦合」，不適合當成開工前的儀式。你可以用下面幾個問題做快速檢查：

這個類別是否同時受到不同角色的需求影響？如果是，回頭看 SRP。
每次新增類型都要修改同一串條件判斷嗎？如果是，考慮 OCP。
子類別是否需要丟出「這個方法我不支援」的例外？如果是，檢查 LSP。
類別是否被迫實作或依賴一大堆用不到的方法？如果是，看看 ISP。
業務邏輯是否直接 new 出資料庫、郵件服務或第三方 SDK？如果是，考慮 DIP。

最後也別忘了 YAGNI：還沒有需求、沒有變動跡象時，先寫清楚簡單的程式碼，通常比預先蓋一座抽象城堡更好維護。SOLID 的目標是降低變更成本，不是增加類別數量。類別多到需要地圖才能找到入口，那就不是 SOLID，是迷宮設計。

總結

SOLID 五原則可以濃縮成一句話：讓程式碼的責任清楚、變動可控、依賴可替換，並且讓抽象真正符合它承諾的行為。

你不需要一次重寫整個專案。下一次看到超長類別、巨型 if、不自然的繼承，先挑一個最痛的地方改善，跑測試，再觀察設計是否更容易理解。好的設計通常不是一杯咖啡喝完突然出現，而是每次修改少一點心驚膽跳。

常見 FAQ

SOLID 一定要五個全用嗎？

不用。SOLID 是思考工具，不是開工 checklist。先從最痛的地方（通常是 SRP 或 DIP）下手即可。

SOLID 和設計模式衝突嗎？

不衝突。設計模式是具體解法，SOLID 是設計方向。例如 Factory 常配合 DIP 使用，但 Singleton 濫用可能違反 SRP。

小專案也要 SOLID 嗎？

小腳本、一次性工具不必。當程式碼會被多人維護、需求會持續變動時，SOLID 的投報才明顯。

參考資料

The Single Responsibility Principle — Robert C. Martin：說明 SRP 的「一個改變理由」觀點。
The Open Closed Principle — Robert C. Martin：介紹 OCP 與擴充、修改之間的取捨。
Liskov Substitution Principle — Wikipedia：整理里氏替換原則的正式定義與背景。
PHP 手冊：物件介面：查閱 PHP 介面的宣告與實作規則。
PHP 手冊：建構子與解構子：查閱範例中建構子注入所使用的 PHP 物件語法。

PHP class 與 object 入門：類別、物件、$this 實戰教學

2026-08-29T00:00:00Z

PHP class（類別） 是建立 object（物件）的藍圖，定義屬性與方法；object 則是用 new 依照 class 產生的實例，各自保存自己的資料。物件導向（OOP）把相關的資料和操作資料的程式碼放在一起，讓程式不必像咖啡店的桌面一樣，什麼東西都堆在同一區。

這篇用簡單範例帶你理解 class、object、屬性、方法、$this 與封裝。讀完後，你應該能看懂基本 OOP 程式，並開始設計小型類別。

快速參考

概念	說明
class	定義物件應有的屬性與方法（設計圖）
object	用 `new ClassName()` 建立的實例（成品）
屬性（property）	物件的資料，如 `$book->title`
方法（method）	物件的行為，如 `$book->describe()`
`$this`	在方法內代表「目前這個物件」
封裝	用 `private`／`protected` 限制外部直接改資料

class 與 object 差在哪？

生活化比喻：class 像設計圖，object 像依照設計圖做出來的成品。

Cake 類別描述蛋糕有哪些資料（口味、尺寸）和能做什麼（烘烤）。依照它建立的巧克力蛋糕和草莓蛋糕，是兩個不同的 object。

class：定義物件應有的屬性和方法
object：class 建立出來的實例，擁有自己的資料
實例化：用 new 依照 class 建立 object 的過程

建立第一個 class

<?php

class Cake
{
	public $flavor;
	public $size;

	public function bake()
	{
		echo '正在烘烤 ' . $this->flavor . ' 口味的蛋糕。';
	}
}

flavor、size 是屬性，保存物件資料
bake() 是方法，描述物件行為
$this 代表「目前正在呼叫這個方法的物件」

用 `new` 建立 object

$chocolateCake = new Cake();
$chocolateCake->flavor = '巧克力';
$chocolateCake->size = '大';

$chocolateCake->bake();

箭頭 -> 用來存取物件的屬性或方法。同一個 class 可以建立多個彼此獨立的 object：

$chocolateCake = new Cake();
$chocolateCake->flavor = '巧克力';

$strawberryCake = new Cake();
$strawberryCake->flavor = '草莓';

$chocolateCake->bake();  // 巧克力
$strawberryCake->bake();  // 草莓

實戰範例：Book 與 Bookshelf

<?php

class Book
{
	public $title;
	public $author;

	public function describe()
	{
		return $this->title . '，作者：' . $this->author;
	}
}

$book = new Book();
$book->title = '哈比人';
$book->author = 'J. R. R. 托爾金';

echo $book->describe();

describe() 透過 $this 取得目前物件的資料，不必另外傳入 $book。

物件組合：一個 object 管理多個 object

<?php

class Bookshelf
{
	public $books = [];

	public function addBook(Book $book)
	{
		$this->books[] = $book;
	}

	public function listBooks()
	{
		foreach ($this->books as $book) {
			echo $book->describe() . PHP_EOL;
		}
	}
}

$bookshelf = new Bookshelf();
$bookshelf->addBook($book);
$bookshelf->listBooks();

Bookshelf 的 books 陣列放著多個 Book object——這就是物件組合（composition）。

封裝與可見性

前面用 public，代表類別外也能直接讀寫。實務上通常限制外部直接改資料：

修飾符	類別內	子類別	類別外
`public`	✅	✅	✅
`protected`	✅	✅	❌
`private`	✅	❌	❌

<?php

class Book
{
	private $title;

	public function setTitle($title)
	{
		$this->title = $title;
	}

	public function getTitle()
	{
		return $this->title;
	}
}

$book = new Book();
$book->setTitle('哈比人');

echo $book->getTitle();

這就是封裝：把資料和操作規則放在一起，限制外部直接碰觸內部狀態。詳細對照見存取修飾符。

常見問題

Q：class 和 object 一定要一起用嗎？
A：class 是定義，object 是執行時的實例。沒有 new 建立 object，class 只是規格，不會自己跑起來。

Q：$this 和 self 差在哪？
A：$this 指向目前物件實例；self 指向類別本身（常用於靜態成員）。初學先掌握 $this 即可。

Q：什麼時候該用 OOP？
A：當多組資料和函式明顯屬於同一種「事物」時——例如訂單、使用者、書籍。簡單腳本不必硬套 class。

Q：下一步學什麼？
A：存取修飾符 → try catch → Composer → SOLID。

結語

PHP OOP 的核心詞彙：

class 定義屬性與方法
object 是 class 的實例
new 建立 object
$this 在方法內代表目前物件
封裝透過可見性控制資料存取

當程式裡有許多互相關聯的資料和函式時，問自己：「這些是不是屬於同一種事物？」如果是，就可能是設計 class 的好時機。

光輝咖碼

PageSpeed Insights 怎麼改善？實戰教學（LCP／INP／CLS 對照表）

快速參考

目錄

第一步：怎麼用 PageSpeed Insights 測試

Core Web Vitals 門檻速查

LCP 怎麼改善

INP 怎麼改善

CLS 怎麼改善

30 分鐘改善 Checklist

3 個改善案例（方向參考）

常見誤區

分數高就代表 SEO 一定好？

自己開很快，訪客就一定快？

實驗室滿分 = 實地資料也會綠？

只優化首頁夠嗎？

其他實用工具

常見問題

結語

參考資料

encodeURI vs encodeURIComponent：何時用哪個？

目錄

encodeURI 和 encodeURIComponent 差在哪？

encodeURI 是什麼時候用的？

encodeURIComponent 是什麼時候用的？

實戰：組查詢字串該怎麼寫？

常見踩雷：什麼時候會用錯？

快速決策：我現在該用哪個？

參考資料

Eleventy 怎麼顯示流程圖，Mermaid 的顯示和優化

目錄

SVG、PNG，還是瀏覽器端 Mermaid？

第一步：準備 Mermaid 原始檔

第二步：用 Mermaid CLI 匯出 SVG 或 PNG

第三步：讓 Eleventy 複製圖檔並嵌入頁面

第四步：讓圖片在手機上不拆台

上線前檢查清單

結語

參考資料

什麼是 PHP？入門指南：用途、市占與 vs Node.js／Python

快速參考

目錄

PHP 的用途：工程師實際在做什麼？

最小範例：5 分鐘跑起來

為什麼還有人用 PHP？

市占與生態

主機與上線成本

現代 PHP 已不是「把 HTML 跟邏輯攪在一起」

什麼時候不該硬選 PHP

PHP vs Node.js vs Python：怎麼選

PHP 8.x 你該知道的新特性

PHP 8.0–8.3

PHP 8.4–8.5 值得關注

怎麼開始：環境與學習路徑

本機環境

五分鐘動態網頁範例

建議學習順序

常見問題

結語

參考資料

TypeScript 入門教學：零基礎快速上手（tsc 安裝＋tsconfig 速查）

快速參考

目錄

TypeScript 是什麼？

建立 TypeScript 開發環境

安裝 Node.js

安裝 TypeScript（tsc）

初始化 tsconfig.json

寫出並編譯第一支 TypeScript 程式

tsc 常用指令

執行 TypeScript 的幾種方式

使用 Node.js

使用 ts-node

TypeScript Playground

Deno

Bun

常見 FAQ

TypeScript 跟 JavaScript 有什麼差別？

需要全域安裝 tsc 嗎？

tsconfig.json 的 strict 要開嗎？

初始化 `tsconfig.json`

`tsc` 常用指令

需要全域安裝 `tsc` 嗎？

`tsconfig.json` 的 `strict` 要開嗎？

Deno 或 Bun 還需要 `tsc` 嗎？

中文標題的 `id` 怎麼產生？

`if` 越長，咖啡越苦