## Case #3: 圖片資產含空白與括號導致的 Markdown 連結破圖

### Problem Statement（問題陳述）
業務場景：文章圖片檔名含空白與括號（例如 IMG_8698 (Canon PowerShot G9).jpg），在 Markdown 連結中若未正確編碼或逃脫，常導致破圖。原文圖片連結可見 %20 與括號，並疑似有額外尾碼，具有風險。
技術挑戰：正確處理 URL 編碼與 Markdown 語法，並建立資產命名規範避免問題。
影響範圍：閱讀體驗、維護成本。
複雜度評級：低

### Root Cause Analysis
直接原因：
1. 空白與括號未正確編碼或逃脫。
2. Markdown 的 () 與 URL 中 () 混淆。
3. 資產命名無規範。
深層原因：
- 架構層面：缺少資產流水線（rename/compress/check）。
- 技術層面：不熟悉 Markdown URL 編碼與逃脫。
- 流程層面：上稿缺少自動檢查。

### Solution Design
解決策略：制定「資產命名規範 + 自動化檢查 + 正確連結寫法」三件套。避免在檔名使用空白與括號；必要時正確 percent-encoding 或使用參照式連結。

實施步驟：
1. 檔名淨化與壓縮
- 細節：批次改名為 kebab-case；壓縮與產生指紋。
- 資源：bash/PowerShell、imagemin。
- 時間：0.5 天。

2. 連結語法修正與檢查
- 細節：參照式連結或以 <...> 包裹 URL；CI 破圖檢查。
- 資源：link checker。
- 時間：0.5 天。

關鍵程式碼/設定：
```markdown
<!-- 推薦：避免空白與括號；或使用參照式連結 -->
![Canon G9 作例][img1]

[img1]: /images/2008-06-04-run-pc-2008-june-issue/img-8698-canon-g9.jpg

## Case #4: 雜誌稿擠導致網址未刊的補救與發佈備援

### Problem Statement
業務場景：紙本雜誌因版面限制未刊出文末簡介與下載/ Demo 網址；原文說明因此在部落格補上 sample code 與線上 demo 連結，作為讀者落地頁。
技術挑戰：提供「可記憶、可掃描、可持續」的線上落地頁，避免讀者找不到資源。
影響範圍：讀者轉化、口碑、客服。
複雜度評級：低

### Root Cause Analysis
直接原因：
1. 紙本版面限制導致網址遺漏。
2. 連結過長不利於紙本呈現。
3. 缺少標準化的刊物→網頁銜接流程。
深層原因：
- 架構層面：沒有固定落地頁架構（如 /runpc/YYYY-MM）。
- 技術層面：未提供短網址/QR Code。
- 流程層面：出版前未核對連結呈現。

### Solution Design
解決策略：建立每期固定落地頁（短路徑）、短網址與 QR Code；所有下載與 Demo 集中於該頁。印刷只需一個短連結與 QR，並於網站保留備援鏡像。

實施步驟：
1. 落地頁模板與短連結
- 細節：/runpc/2008-06 作為索引頁，集中下載與 Demo。
- 資源：Jekyll 模板、短網址服務。
- 時間：0.5 天。

2. QR Code 與刊前校對
- 細節：產生 QR、列印測試、校對流程。
- 資源：qrcode 庫。
- 時間：0.5 天。

關鍵程式碼/設定：
```yaml
# Jekyll 版固定落地頁 Front Matter
---
layout: page
title: RUN! PC 2008-06 資源索引
permalink: /runpc/2008-06/
---
- 下載：/runpc/2008-04/2008-04.zip
- 線上試用：/runpc/2008-06/

## Case #5: 範例程式下載（ZIP）之正確 MIME、快取與完整性

### Problem Statement
業務場景：提供 .zip 下載的 sample code，需正確 Content-Type、快取策略與完整性保護，避免下載失敗、被中途變更或瀏覽器錯誤處理。
技術挑戰：伺服器預設 MIME/快取常不理想，缺少 ETag/Checksum。
影響範圍：讀者體驗、頻寬與可信度。
複雜度評級：低

### Root Cause Analysis
直接原因：
1. 未設定 application/zip 導致下載異常。
2. 無 ETag/Checksum，不易驗證完整性。
3. 快取策略不當造成更新或頻寬浪費。
深層原因：
- 架構層面：靜態資產服務未標準化。
- 技術層面：缺少檔案頭部最佳化知識。
- 流程層面：未提供檔案指紋或 Hash。

### Solution Design
解決策略：設定正確 MIME、Content-Disposition、ETag/Last-Modified 與 Cache-Control；對外公布 SHA256；大檔可搭配 CDN。

實施步驟：
1. 伺服器設定
- 細節：針對 .zip 設定 MIME 與 headers。
- 資源：Nginx/Apache。
- 時間：0.5 天。

2. 完整性公示與監控
- 細節：產生 SHA256，頁面公示；監控 5xx。
- 資源：sha256sum、監控。
- 時間：0.5 天。

關鍵程式碼/設定：
```nginx
types { application/zip zip; }
location ~* \.zip$ {
  add_header Content-Disposition "attachment";
  add_header Cache-Control "public, max-age=604800, immutable";
  etag on;
}

## Case #6: 公開線上 Demo 的安全隔離與可用性

### Problem Statement
業務場景：提供線上 Demo（原文提供 demo.chicken-house.net/runpc/2008-06/），需避免濫用、保護主站、確保可用性。
技術挑戰：資源隔離、限流、錯誤處理與監控。
影響範圍：安全風險、服務穩定、品牌信任。
複雜度評級：中-高

### Root Cause Analysis
直接原因：
1. Demo 與主站資源共享。
2. 未設限流/隔離策略。
3. 缺少監控告警。
深層原因：
- 架構層面：缺乏沙箱架構。
- 技術層面：沒有反向代理與容器化部署。
- 流程層面：未定義 Demo 上線守則。

### Solution Design
解決策略：將 Demo 容器化，置於隔離網段；反向代理設限流與 WAF；以唯讀檔案系統與最小權限部署；加上監控、熔斷與自動復原。

實施步驟：
1. 容器化與權限最小化
- 細節：唯讀映像、非 root 執行、網路隔離。
- 資源：Docker、K8s/Compose。
- 時間：1-2 天。

2. 反向代理限流與監控
- 細節：limit_req、custom error、探活、告警。
- 資源：Nginx、Prometheus/Grafana。
- 時間：1 天。

關鍵程式碼/設定：
```nginx
# 限流（示意）
limit_req_zone $binary_remote_addr zone=demo:10m rate=30r/m;
server {
  location /runpc/2008-06/ {
    limit_req zone=demo burst=20 nodelay;
    proxy_pass http://demo_backend;
  }
  error_page 429 = /rate-limited.html;
}

## Case #7: 啟用留言收集讀者回饋與反垃圾策略

### Problem Statement
業務場景：原文 Front Matter 顯示 comments: true，表示開放留言；需在收集回饋與防垃圾之間取得平衡。
技術挑戰：靜態站的留言託管、垃圾過濾與隱私合規。
影響範圍：社群互動、維運成本、法遵。
複雜度評級：中

### Root Cause Analysis
直接原因：
1. 開放留言帶來垃圾訊息。
2. 靜態站需外掛留言服務。
3. 缺少明確的審核流程。
深層原因：
- 架構層面：未定義留言資料歸屬與儲存方式。
- 技術層面：未導入過濾機制（Akismet/ReCaptcha 等）。
- 流程層面：缺少審核與回應 SLO。

### Solution Design
解決策略：選擇合適的留言後端（Giscus/Utterances/Staticman/Disqus），搭配防垃圾與審核流程；在隱私條款中揭露資料處理。

實施步驟：
1. 留言後端與防垃圾
- 細節：以 Giscus（GitHub Discussions）或 Staticman 託管；加上 ReCaptcha 或審核白名單。
- 資源：第三方服務、隱私聲明。
- 時間：0.5-1 天。

2. 審核與回覆流程
- 細節：SLA（如 48 小時內回覆）、通知機制。
- 資源：Issue/Email 通知。
- 時間：0.5 天。

關鍵程式碼/設定：
```html
<!-- 以 Giscus 為例（Jekyll include） -->
<script src="https://giscus.app/client.js"
        data-repo="owner/repo"
        data-repo-id="..."
        data-category="Comments"
        data-mapping="pathname"
        crossorigin="anonymous" async>
</script>

## Case #8: 分類與標籤（categories/tags）提升內容可發現性

### Problem Statement
業務場景：原文使用 categories: RUN! PC 專欄文章 與 tags: .NET/ASP.NET 等。需要建立分類/標籤頁與導覽，以增加內容探索效率。
技術挑戰：自動化產生分類/標籤索引、URL 規範與 SEO。
影響範圍：流量、停留時間、跳出率。
複雜度評級：低

### Root Cause Analysis
直接原因：
1. 無標籤頁不利瀏覽。
2. 無內部連結不利 SEO。
3. 無一致命名導致重複標籤。
深層原因：
- 架構層面：缺少 IA（資訊架構）設計。
- 技術層面：未建標籤索引模板。
- 流程層面：缺乏標籤治理（同義詞合併）。

### Solution Design
解決策略：標準化分類/標籤並自動生成索引頁；在文章底部生成相關文章區塊；建立標籤詞彙表。

實施步驟：
1. 模板與索引
- 細節：標籤頁路徑 /tags/asp-net/；相關文章以共用標籤查詢。
- 資源：Jekyll Liquid。
- 時間：0.5 天。

2. 標籤治理
- 細節：標籤白名單、同義詞映射。
- 資源：資料表。
- 時間：0.5 天。

關鍵程式碼/設定：
```liquid
<!-- tags 索引模板 -->
{% for tag in site.tags %}
  <h2 id="{{ tag[0] }}">{{ tag[0] }}</h2>
  <ul>{% for post in tag[1] %}<li><a href="{{ post.url }}">{{ post.title }}</a></li>{% endfor %}</ul>
{% endfor %}

## Case #9: 導向與 404 的可觀測性與成效度量

### Problem Statement
業務場景：做了導向與落地頁，但沒有度量無法驗證成效。需量測 404、301 命中、導向鏈長度、外部點擊。
技術挑戰：靜態站結合伺服器與分析工具的觀測。
影響範圍：決策品質、SEO、維運。
複雜度評級：中

### Root Cause Analysis
直接原因：
1. 無標準化日誌與報表。
2. 未追蹤外鏈與下載。
3. 缺少導向鏈檢測。
深層原因：
- 架構層面：觀測性未納入設計。
- 技術層面：缺乏 log_format 與 parser。
- 流程層面：沒有 KPI 與例行檢視。

### Solution Design
解決策略：統一 Nginx log_format，使用 goaccess/Elastic 報表；在前端加入外鏈/下載事件；週期性導向鏈掃描與報告。

實施步驟：
1. 日誌與報表
- 細節：自訂 log_format 記錄狀態、referer、時間；goaccess 產報。
- 資源：Nginx、goaccess。
- 時間：0.5 天。

2. 事件追蹤與鏈檢測
- 細節：GA/Matomo 自訂事件；腳本檢測導向鏈。
- 資源：Analytics、Node/Python。
- 時間：0.5-1 天。

關鍵程式碼/設定：
```nginx
log_format rich '$remote_addr "$request" $status $request_time "$http_referer"';
access_log /var/log/nginx/access.log rich;

## Case #10: 多舊平台路徑模式（/columns, /post, /blogs/...）的合併策略

### Problem Statement
業務場景：Front Matter 展示多個歷史路徑前綴，顯示曾歷經不同 CMS 或路由策略。需統一至單一規範，避免重複內容與錯誤導向。
技術挑戰：路徑語意差異與歷史遺留。
影響範圍：SEO、維護成本。
複雜度評級：中

### Root Cause Analysis
直接原因：
1. 多 CMS 併存導致多前綴。
2. 設計時未留後向相容。
3. 缺少全量映射表。
深層原因：
- 架構層面：內容基底未抽象化（ID/Slug）。
- 技術層面：無標準 permalink 模型。
- 流程層面：遷移策略缺失。

### Solution Design
解決策略：建立「內容 ID → 多 permalink 模板 → 單一 canonical」的映射層；自動生成舊路徑別名頁或伺服器規則，並在 Head 設 canonical。

實施步驟：
1. 映射表建立與 canonical
- 細節：以唯一 ID（如 wordpress_postid）串起歷史路徑。
- 資源：資料導出、腳本。
- 時間：1 天。

2. 別名頁與 rewrite
- 細節：對高風險路徑生成 alias；低風險用伺服器規則。
- 資源：Jekyll、Nginx。
- 時間：1 天。

關鍵程式碼/設定：
```html
<!-- Head canonical -->
<link rel="canonical" href="https://example.com/2008/06/04/run-pc-2008-六月號/">

## Case #11: 保留 wordpress_postid 以支援遷移映射與留言對應

### Problem Statement
業務場景：Front Matter 有 wordpress_postid: 102，表示曾由 WordPress 遷移。需利用此 ID 做歷史 permalink 映射，或留言/引用對應。
技術挑戰：把舊資料（留言、Pingback）與新頁關聯。
影響範圍：歷史資料完整性、SEO。
複雜度評級：中

### Root Cause Analysis
直接原因：
1. 遷移後失去舊 ID 關聯。
2. 舊 permalink 基於 ID。
3. 留言資料以 ID 綁定。
深層原因：
- 架構層面：資料模型差異。
- 技術層面：缺少遷移腳本。
- 流程層面：未定義對應策略。

### Solution Design
解決策略：在 Front Matter 中保留 wordpress_postid；用生成器自動產生舊 WordPress permalink 別名頁或伺服器映射；留言資料以此鍵匹配。

實施步驟：
1. 對應規則與生成器
- 細節：以 Ruby 外掛讀取 wordpress_postid 生成 alias。
- 資源：Jekyll Plugin。
- 時間：0.5-1 天。

2. 測試與驗證
- 細節：抽樣驗證舊連結、留言是否正確對應。
- 資源：測試腳本。
- 時間：0.5 天。

關鍵程式碼/設定：
```ruby
# Jekyll plugin（簡化示意）
Jekyll::Hooks.register :posts, :post_init do |post|
  if post.data["wordpress_postid"]
    old = "/blogs/chicken/archive/#{post.date.strftime('%Y/%m/%d')}/#{post.data['wordpress_postid']}.aspx/"
    post.data["redirect_from"] ||= []
    post.data["redirect_from"] << old
  end
end

## Case #12: 國際化（i18n）Slug 與 URL 編碼策略

### Problem Statement
業務場景：本文標題含中文（六月號），URL 需要考量可讀性與相容性（百分比編碼 vs 轉寫 slug）。
技術挑戰：搜尋引擎相容、分享體驗、伺服器/工具鏈對 Unicode 支援。
影響範圍：SEO、社群分享、工程相容性。
複雜度評級：中

### Root Cause Analysis
直接原因：
1. 部分工具對非 ASCII 支援不佳。
2. 百分比編碼不易閱讀/輸入。
3. 轉寫規則不一致。
深層原因：
- 架構層面：未定義 slug 策略。
- 技術層面：未配置 slugify。
- 流程層面：未檢查社群分享預覽。

### Solution Design
解決策略：統一定義 slug 策略（例如以英文轉寫，保留中文標題）；或雙軌制：以中文 slug 為主、英文轉寫備援，兩者互導。

實施步驟：
1. 配置 slugify
- 細節：Jekyll _config.yml 設 slugify: latin 或 default。
- 資源：Jekyll。
- 時間：0.5 天。

2. 雙軌導向
- 細節：提供 zh/ 拉丁化 slug，互相 301 至 canonical。
- 資源：伺服器規則。
- 時間：0.5 天。

關鍵程式碼/設定：
```yaml
# _config.yml
slugify: latin  # 或 default，依策略而定

## Case #13: 外部資源腐朽（Link Rot）的鏡像與監控

### Problem Statement
業務場景：原文連到 demo 子網域與下載資源；長期可能失效（域名更換、主機下線）。需鏡像與監測。
技術挑戰：外鏈健康監控、備援鏡像、使用者提示。
影響範圍：使用者信任、SEO、維運。
複雜度評級：中

### Root Cause Analysis
直接原因：
1. 外部主機壽命有限。
2. DNS/SSL 可能過期。
3. 無鏈結健康例行檢查。
深層原因：
- 架構層面：缺少資源歸檔策略。
- 技術層面：未設鏡像（GitHub Releases/Archive）。
- 流程層面：未設外鏈巡檢。

### Solution Design
解決策略：建立鏡像（GitHub Releases/Pages）、加上鏈結健康 CI；主鏈失效時顯示備援提示；重要資源以永久 DOI/存檔服務保底。

實施步驟：
1. 鏡像與指紋
- 細節：將 zip 與 demo 備份到 GitHub，公示 SHA。
- 資源：GitHub Actions。
- 時間：1 天。

2. 巡檢與替代
- 細節：週期 link-checker；失效自動開 Issue。
- 資源：CI。
- 時間：0.5 天。

關鍵程式碼/設定：
```yaml
# GitHub Actions：每週鏈結巡檢（示意）
on:
  schedule: [{cron: "0 0 * * 0"}]
jobs:
  linkcheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npx linkinator https://example.com -r --timeout=10000

## Case #14: 發佈狀態與預覽管線（published: true）

### Problem Statement
業務場景：Front Matter 有 published: true。需建立草稿→審核→發佈的安全管線，避免未準備好之內容曝光。
技術挑戰：多環境（本機/預覽/正式）一致性。
影響範圍：內容品質、風險控管。
複雜度評級：低

### Root Cause Analysis
直接原因：
1. 無預覽環境。
2. 無審核門檻。
3. 不當曝光。
深層原因：
- 架構層面：缺少分支策略與環境隔離。
- 技術層面：未利用 published/draft 機制。
- 流程層面：無審核清單。

### Solution Design
解決策略：以 Git 分支建立預覽站（PR 觸發），主分支才部署正式；以 published/draft 控制；審核清單含鏈結健康、圖片、SEO。

實施步驟：
1. 預覽環境
- 細節：PR 頁面自動部署到 preview.example.com。
- 資源：GitHub Actions/Netlify/Vercel。
- 時間：0.5-1 天。

2. 審核清單與自動檢查
- 細節：Lint/link check/SEO 檢查。
- 資源：CI。
- 時間：0.5 天。

關鍵程式碼/設定：
```yaml
# _config.yml
defaults:
  - scope: {path: ""} 
    values: {published: true}

## Case #15: 影像資產優化與命名規範

### Problem Statement
業務場景：圖片檔名含機型與空白，檔案未壓縮可能較大。需建立命名規範與壓縮流程。
技術挑戰：品質與大小平衡、指紋與快取。
影響範圍：頁面載入速度、SEO、流量成本。
複雜度評級：低

### Root Cause Analysis
直接原因：
1. 原始相機檔名不友善。
2. 未壓縮與尺寸調整。
3. 無快取指紋。
深層原因：
- 架構層面：缺少資產流水線。
- 技術層面：不熟圖片最佳化。
- 流程層面：無發佈前檢查。

### Solution Design
解決策略：以 pipeline 進行壓縮、生成多尺寸與指紋檔名；以 CDN 提供自動轉碼（WebP/AVIF）與快取。

實施步驟：
1. 壓縮與指紋
- 細節：imagemin、sharp 生成多尺寸；檔名加 hash。
- 資源：Node 工具鏈。
- 時間：0.5-1 天。

2. 模板改寫
- 細節：<picture> 與 srcset。
- 資源：模板引擎。
- 時間：0.5 天。

關鍵程式碼/設定：
```html
<picture>
  <source type="image/avif" srcset="/images/img-8698.avif">
  <source type="image/webp" srcset="/images/img-8698.webp">
  <img src="/images/img-8698.jpg" alt="Canon G9 作例" loading="lazy">
</picture>

## Case #16: 直達最終頁的單跳 301，移除導向鏈

### Problem Statement
業務場景：歷史上可能有多層導向（/post → /columns → 新頁），導致 SEO 稀釋與延遲。需將導向扁平化為「單跳」。
技術挑戰：找出鏈路並調整規則避免副作用。
影響範圍：SEO、延遲、維護。
複雜度評級：中

### Root Cause Analysis
直接原因：
1. 多次遷移累積導向。
2. 規則疊加未整理。
3. 覆蓋順序錯誤。
深層原因：
- 架構層面：缺少導向收斂策略。
- 技術層面：缺少鏈路掃描。
- 流程層面：無定期清理。

### Solution Design
解決策略：建立導向圖譜，找出鏈路並調整規則使舊路徑直接 301 至最終頁；以自動化掃描防止回歸。

實施步驟：
1. 掃描與圖譜
- 細節：以 curl -I -L 或自製腳本輸出 num_redirects。
- 資源：腳本。
- 時間：0.5 天。

2. 規則調整與回歸
- 細節：更新 map/regex；加入 CI 驗證。
- 資源：Nginx/CI。
- 時間：0.5 天。

關鍵程式碼/設定：
```bash
# 輸出導向次數
curl -I -L -s -o /dev/null -w "%{url_effective} %{num_redirects}\n" \
"https://example.com/post/RUNPC-2008-06.aspx/"