## Case #2: 實作 newMediaObject 的 ASP.NET 端點（伺服端）

### Problem Statement（問題陳述）
業務場景：現有平台未提供或停用 newMediaObject，導致無法透過部落格編輯器直接上傳圖片，作者必須繞道 FTP。需要實作一個可部署於 IIS 的 XML-RPC 端點，完全符合 MetaWeblog 規範，並能在現有身分系統上運作。

技術挑戰：XML-RPC 解析、Base64 位元組處理、檔案安全寫入、URL 生成、錯誤對應至 XML-RPC Fault。

影響範圍：部落格編輯器整合、上傳成功率、平台安全性與穩定性。

複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 後端缺少 XML-RPC 端點實作。
2. 未有標準化的檔案儲存與 URL 生成邏輯。
3. 認證流程未與 API 整合。

深層原因：
- 架構層面：服務端缺乏媒體服務模組。
- 技術層面：對 XML-RPC/newMediaObject 協定不熟悉。
- 流程層面：未建立 API 錯誤碼與日誌規範。

### Solution Design（解決方案設計）
解決策略：以 ASP.NET Handler 或 Web API + XML-RPC library 實作 newMediaObject；封裝驗證、儲存、URL 與錯誤轉換的服務層；撰寫單元測試與整合測試，確保相容性。

實施步驟：
1. 建立 XML-RPC 服務
- 實作細節：引用 CookComputing.XmlRpcV2，定義介面與 DTO
- 所需資源：NuGet、IIS
- 預估時間：1 天

2. 封裝媒體服務層
- 實作細節：MediaService.Save、UrlService.Build、AuthService.Validate
- 所需資源：檔案系統/雲儲存、設定檔
- 預估時間：1 天

3. 測試與部署
- 實作細節：用 Python/Live Writer 測試；IIS 站台設定
- 所需資源：測試工具、CI/CD
- 預估時間：0.5-1 天

關鍵程式碼/設定：
```csharp
public interface IMetaWeblog : IXmlRpcProxy
{
  [XmlRpcMethod("metaWeblog.newMediaObject")]
  MediaObjectInfo NewMediaObject(string blogid, string username, string password, MediaObject media);
}

public class MediaService {
  public string Save(string user, string filename, byte[] data) {
    var safe = FileNameHelper.GetSafeUniqueName(filename);
    var dir = Path.Combine(_root, user, DateTime.UtcNow.ToString("yyyy/MM"));
    Directory.CreateDirectory(dir);
    var full = Path.Combine(dir, safe);
    using var fs = new FileStream(full, FileMode.CreateNew, FileAccess.Write, FileShare.None, 81920, FileOptions.WriteThrough);
    fs.Write(data, 0, data.Length);
    return full;
  }
}

## Case #3: 用 Python 客戶端呼叫 newMediaObject 直接上傳圖片

### Problem Statement（問題陳述）
業務場景：內容團隊使用多種平台（Windows/Mac/Linux），希望用自動化腳本將素材批次上傳，並將回傳 URL 自動插入 Markdown 文章，減少來回切換工具與貼圖錯誤。

技術挑戰：正確組構 XML-RPC 請求、處理驗證、Base64 編碼、例外處理與重試機制。

影響範圍：內容生產效率、發文品質與失誤率。

複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. 缺乏可跨平台的上傳工具。
2. 手工貼圖連結容易出錯。
3. 沒有重試與可觀測性。

深層原因：
- 架構層面：未將上傳流程自動化。
- 技術層面：未提供範例與 SDK。
- 流程層面：缺少標準作業腳本（SOP）。

### Solution Design（解決方案設計）
解決策略：提供 Python 範例，封裝 newMediaObject 呼叫；加入重試、超時、日誌；將回傳 URL 直接輸出 Markdown 圖片語法，支援批次與 CI。

實施步驟：
1. 撰寫上傳腳本
- 實作細節：xmlrpc.client、讀檔、MIME 推斷
- 所需資源：Python 3.x
- 預估時間：0.5 天

2. 加入健壯性
- 實作細節：重試（指數退避）、超時、錯誤碼解析
- 所需資源：tenacity 或自寫重試
- 預估時間：0.5 天

關鍵程式碼/設定：
```python
# Python 3 - newMediaObject uploader
import mimetypes, base64, sys
from xmlrpc.client import ServerProxy, Fault, Transport

class TimeoutTransport(Transport):
    def __init__(self, timeout=10):
        super().__init__()
        self.timeout = timeout
    def make_connection(self, host):
        conn = super().make_connection(host)
        conn.timeout = self.timeout
        return conn

def upload(endpoint, blog_id, user, pwd, file_path):
    with open(file_path, 'rb') as f:
        data = f.read()
    media = {
        'name': file_path.split('/')[-1],
        'type': mimetypes.guess_type(file_path)[0] or 'application/octet-stream',
        'bits': data
    }
    client = ServerProxy(endpoint, transport=TimeoutTransport(15), allow_none=True)
    return client.metaWeblog.newMediaObject(blog_id, user, pwd, media)

if __name__ == "__main__":
    endpoint, blog_id, user, pwd, path = sys.argv[1:6]
    try:
        info = upload(endpoint, blog_id, user, pwd, path)
        print(f"![alt]({info['url']})")
    except Fault as e:
        print(f"Upload failed: {e.faultCode} {e.faultString}", file=sys.stderr)
        sys.exit(1)

## Case #4: 強制 HTTPS 與憑證保護，避免明文密碼傳輸

### Problem Statement（問題陳述）
業務場景：MetaWeblog 認證多為使用者名/密碼，若端點以 HTTP 提供，憑證將以明文傳輸，存在竊聽與憑證重放風險。需要全面升級為 HTTPS 並限制不安全存取。

技術挑戰：IIS 憑證配置、Rewrite 強制跳轉、用戶端相容、舊書籤更新與憑證輪換。

影響範圍：全體作者與機器人帳號的登入安全；法規遵循。

複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 端點以 HTTP 開放，傳輸未加密。
2. 用戶端預設使用舊 URL。
3. 未有安全基準（TLS 版本/密碼套件）。

深層原因：
- 架構層面：缺乏零信任/加密預設。
- 技術層面：未配置憑證與 TLS policy。
- 流程層面：缺少憑證到期與輪換流程。

### Solution Design（解決方案設計）
解決策略：安裝可信憑證、設定 TLS1.2+、IIS URL Rewrite 強制 301 至 HTTPS、拒絕 HTTP 身分操作；發佈新端點 URL 並更新用戶端設定指南；導入密碼金庫管理帳密。

實施步驟：
1. TLS 配置與強制跳轉
- 實作細節：IIS 綁定憑證、URL Rewrite 規則
- 所需資源：公有 CA 憑證、IIS 管理工具
- 預估時間：0.5 天

2. 用戶端更新與監測
- 實作細節：公告新 URL、監控 HTTP 命中比率
- 所需資源：監控系統、文件
- 預估時間：0.5 天

關鍵程式碼/設定：
```xml
<!-- web.config - 強制 HTTPS -->
<system.webServer>
  <rewrite>
    <rules>
      <rule name="HTTP to HTTPS" enabled="true" stopProcessing="true">
        <match url="(.*)" />
        <conditions>
          <add input="{HTTPS}" pattern="off" ignoreCase="true" />
        </conditions>
        <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" />
      </rule>
    </rules>
  </rewrite>
  <security>
    <requestFiltering allowDoubleEscaping="false" />
  </security>
</system.webServer>

## Case #5: MIME 型別與大小限制，阻擋惡意檔案

### Problem Statement（問題陳述）
業務場景：對外開放圖片上傳，若未限制型別與大小，可能被上傳可執行檔、腳本或過大檔案，造成安全事件與資源耗盡。需要在 newMediaObject 層即阻擋。

技術挑戰：準確辨識型別、雙重驗證（MIME/副檔名/魔術數）、限制大小與回應友善錯誤。

影響範圍：平台安全、儲存成本、伺服器可靠性。

複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 缺少型別白名單。
2. 未設定大小上限。
3. 沒有回應一致的錯誤碼。

深層原因：
- 架構層面：入口驗證不足。
- 技術層面：未使用魔術數檢測。
- 流程層面：缺少安全基線與測試。

### Solution Design（解決方案設計）
解決策略：建立允許清單（image/jpeg, png, gif, webp），檔案大小上限（例如 10MB），加入魔術數檢測；觸發拒絕時回傳可解析的 XML-RPC Fault。

實施步驟：
1. 實作驗證器
- 實作細節：檢查副檔名、MIME、魔術數、大小
- 所需資源：正規表示式、檔頭檢查
- 預估時間：0.5 天

2. 錯誤處理與測試
- 實作細節：自訂錯誤碼，含友善訊息
- 所需資源：單元/整合測試
- 預估時間：0.5 天

關鍵程式碼/設定：
```csharp
static readonly HashSet<string> Allowed = new(StringComparer.OrdinalIgnoreCase)
{ ".jpg", ".jpeg", ".png", ".gif", ".webp" };
const int MaxBytes = 10 * 1024 * 1024;

void Validate(MediaObject media) {
  if (media.bits == null || media.bits.Length == 0)
    throw new XmlRpcFaultException(400, "Empty file");
  if (media.bits.Length > MaxBytes)
    throw new XmlRpcFaultException(413, "File too large (max 10MB)");

  var ext = Path.GetExtension(media.name);
  if (!Allowed.Contains(ext))
    throw new XmlRpcFaultException(415, "Unsupported file type");

  // Magic numbers
  if (!ImageMagicNumberValidator.IsImage(media.bits))
    throw new XmlRpcFaultException(415, "Invalid image content");
}

## Case #6: 檔名清理與儲存路徑規劃（避免碰撞與注入）

### Problem Statement（問題陳述）
業務場景：使用者上傳的原始檔名可能包含空白、非 ASCII、危險字元，或與現有檔案同名，導致路徑注入、覆蓋與取用困難。需要統一命名與路徑策略。

技術挑戰：安全的檔名正規化、唯一命名、依時間/使用者分層儲存、跨平台相容。

影響範圍：URL 穩定性、快取命中率、維運可追溯性。

複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. 當前使用原始檔名，容易碰撞。
2. 未做字元清理，存在注入風險。
3. 儲存目錄缺少分層。

深層原因：
- 架構層面：缺乏命名規範。
- 技術層面：未使用唯一 ID/雜湊。
- 流程層面：未定版文件與檢查清單。

### Solution Design（解決方案設計）
解決策略：統一使用 slug 化的檔名 + 隨機短碼或哈希，按 user/yyyy/MM 分層；保留原名作為 metadata；確保 URL 永久有效。

實施步驟：
1. 檔名正規化
- 實作細節：移除危險字元，轉小寫，空白改為 -
- 所需資源：正規表示式
- 預估時間：0.5 天

2. 唯一命名與分層
- 實作細節：追加短 GUID 或內容哈希前綴
- 所需資源：哈希庫
- 預估時間：0.5 天

關鍵程式碼/設定：
```csharp
public static class FileNameHelper {
  public static string GetSafeUniqueName(string original) {
    var ext = Path.GetExtension(original)?.ToLowerInvariant() ?? "";
    var name = Path.GetFileNameWithoutExtension(original)
      .ToLowerInvariant();
    name = Regex.Replace(name, @"[^a-z0-9\-]+", "-").Trim('-');
    var token = Guid.NewGuid().ToString("N").Substring(0,8);
    return $"{name}-{token}{ext}";
  }
}

## Case #7: 上傳即自動縮圖與壓縮，優化讀取效能

### Problem Statement（問題陳述）
業務場景：文章經常嵌入大尺寸原圖，導致讀者端載入緩慢與流量高。希望在上傳時自動產生多種尺寸（thumb/medium）並壓縮，前端依需求載入。

技術挑戰：影像處理效能、品質與體積平衡、背景任務與同步回應取捨。

影響範圍：頁面載入速度、CDN 流量成本、SEO 指標。

複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 原圖尺寸過大。
2. 無自動化處理流程。
3. 前端無適配 srcset。

深層原因：
- 架構層面：缺少媒體管線。
- 技術層面：缺乏圖像處理庫整合。
- 流程層面：上傳後無自動後製。

### Solution Design（解決方案設計）
解決策略：在上傳完成後觸發縮圖與壓縮，產出多版本檔案；返回主圖 URL 與變體清單；前端使用 srcset/sizes。

實施步驟：
1. 圖像處理管線
- 實作細節：使用 ImageSharp/SkiaSharp 生成多尺寸
- 所需資源：圖像處理庫、背景工作器
- 預估時間：1-2 天

2. 前端與回應擴充
- 實作細節：回傳 variants；前端模板支援 srcset
- 所需資源：前端模板
- 預估時間：0.5-1 天

關鍵程式碼/設定：
```csharp
// 以 SixLabors.ImageSharp 為例
public ImageVariants GenerateVariants(byte[] data) {
  using var img = Image.Load(data);
  var variants = new ImageVariants();
  variants.Original = Save(img, 85, null);
  variants.Medium   = Save(Resize(img, 1280), 80, "medium");
  variants.Thumb    = Save(Resize(img, 320),  75, "thumb");
  return variants;
}

## Case #8: URL 生成與 CDN/反向代理整合

### Problem Statement（問題陳述）
業務場景：圖片直出原站造成高延遲與帶寬負荷，需要整合 CDN 或反向代理，並在 newMediaObject 回傳可快取的公開 URL。

技術挑戰：URL 生成策略、快取頭設定（Cache-Control/ETag）、CDN 來源拉取配置。

影響範圍：讀者體驗、帶寬成本、可用性。

複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 原站輸出，延遲高。
2. 缺少快取頭，CDN 命中率低。
3. URL 與儲存路徑耦合。

深層原因：
- 架構層面：內容發佈未走邊緣。
- 技術層面：快取策略缺失。
- 流程層面：回傳 URL 未考慮 CDN。

### Solution Design（解決方案設計）
解決策略：回傳以 CDN domain 組成的 URL；設定 Cache-Control、ETag；CDN 設定 Origin Pull 來源為 /media 位置；版本化參數避免舊檔快取。

實施步驟：
1. URL 與快取策略
- 實作細節：UrlBuilder 以 cdn.example.com 組 URL；強 Cache-Control
- 所需資源：設定檔、CDN 帳戶
- 預估時間：0.5-1 天

2. CDN Origin 配置
- 實作細節：將 /media 指向原站，開啟壓縮與 HTTP/2
- 所需資源：CDN 控制台
- 預估時間：0.5 天

關鍵程式碼/設定：
```csharp
public string BuildCdnUrl(string relPath, string version=null) {
  var host = _config.CdnHost; // cdn.example.com
  var v = string.IsNullOrEmpty(version) ? "" : $"?v={version}";
  return $"https://{host}/{relPath.TrimStart('/')}{v}";
}

## Case #9: 錯誤處理與 XML-RPC Fault 對應（可觀測性）

### Problem Statement（問題陳述）
業務場景：用戶端需要明確得知上傳失敗原因（超大、型別不符、驗證失敗、系統錯誤），以便自動重試或提示使用者。現況錯誤訊息混亂，難以排查。

技術挑戰：將伺服端例外對應為標準 Fault Code/Message，並記錄可追溯 ID。

影響範圍：上傳成功率、客服工單量、開發者體驗。

複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. 未轉換例外為標準 Fault。
2. 訊息不一致，難以機器判讀。
3. 缺乏請求 ID。

深層原因：
- 架構層面：錯誤分類未定義。
- 技術層面：缺少全域例外攔截器。
- 流程層面：無標準追蹤字段。

### Solution Design（解決方案設計）
解決策略：建立 FaultCode 規範（400/401/413/415/500 等），在端點以 try/catch 統一轉換；回傳 message 中包含 requestId；伺服端紀錄詳細堆疊。

實施步驟：
1. Fault 標準化
- 實作細節：定義錯誤碼與訊息格式
- 所需資源：規範文件
- 預估時間：0.5 天

2. 全域攔截與日誌
- 實作細節：middleware/attribute 包裹端點
- 所需資源：日誌庫
- 預估時間：0.5 天

關鍵程式碼/設定：
```csharp
try {
  // handle upload...
} catch (AuthException ex) {
  throw new XmlRpcFaultException(401, $"Unauthorized | req={Trace.Id}");
} catch (ValidationException ex) {
  throw new XmlRpcFaultException(ex.Code, $"{ex.Message} | req={Trace.Id}");
} catch (Exception ex) {
  _logger.LogError(ex, "Upload failed {ReqId}", Trace.Id);
  throw new XmlRpcFaultException(500, $"Internal error | req={Trace.Id}");
}

## Case #10: 上傳流量的速率限制與用量配額

### Problem Statement（問題陳述）
業務場景：開放上傳 API 易遭濫用，無速率限制與配額會造成資源耗盡與成本暴增。需要對使用者或 API 金鑰進行限流與用量管控。

技術挑戰：實作 per-user/per-IP 的滑動視窗限流、配額統計、超限回應與告警。

影響範圍：平台穩定性、成本控制、公平使用。

複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 缺少限流機制。
2. 無用量統計與報表。
3. 超限沒有清晰回應。

深層原因：
- 架構層面：缺乏 API Gateway/限流中介。
- 技術層面：未用快取儲存計數器。
- 流程層面：未定義配額政策。

### Solution Design（解決方案設計）
解決策略：採用 Redis 作為計數器，實作 Token Bucket 或滑動視窗；設定每分鐘請求數與每日總量；超限回傳 429 並建議稍後重試；儀表板觀測。

實施步驟：
1. 限流器
- 實作細節：Redis INCR + EXPIRE，依使用者 ID 計數
- 所需資源：Redis
- 預估時間：1 天

2. 配額統計與告警
- 實作細節：每日彙總、告警閾值
- 所需資源：任意監控/報表
- 預估時間：1 天

關鍵程式碼/設定：
```csharp
bool CheckRateLimit(string userId, int limitPerMin=60) {
  var key = $"rate:{userId}:{DateTime.UtcNow:yyyyMMddHHmm}";
  var count = _redis.Increment(key);
  _redis.Expire(key, TimeSpan.FromMinutes(1));
  if (count > limitPerMin)
    throw new XmlRpcFaultException(429, "Too many requests");
  return true;
}

## Case #11: 大檔上傳的記憶體/請求大小治理

### Problem Statement（問題陳述）
業務場景：部分使用者上傳高解析度圖片（>10MB），造成 ASP.NET 工作集與暫存爆量，甚至回收重啟。需治理請求大小與串流寫入策略。

技術挑戰：設定 IIS/ASP.NET 限制、串流到磁碟、避免一次性緩衝。

影響範圍：服務穩定性、上傳成功率。

複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 預設 MaxRequestLength 過小或無限制導致 OOM。
2. 一次性將 base64 載入記憶體。
3. 無串流寫入磁碟。

深層原因：
- 架構層面：沒有大檔策略。
- 技術層面：缺乏 chunk/stream 處理。
- 流程層面：未定義大小上限與回應。

### Solution Design（解決方案設計）
解決策略：設定合適的 MaxRequestLength/RequestLimits；在解碼後使用 FileStream 分段寫入；限制單檔上限並回應 413。

實施步驟：
1. 限制與監控
- 實作細節：IIS Request Filtering、ASP.NET limits
- 所需資源：IIS 管理
- 預估時間：0.5 天

2. 串流寫入
- 實作細節：Buffered → Streamed 寫入，避免多重複製
- 所需資源：程式碼調整
- 預估時間：0.5 天

關鍵程式碼/設定：
```xml
<!-- web.config -->
<system.web>
  <httpRuntime maxRequestLength="15360" /> <!-- 15MB -->
</system.web>
<system.webServer>
  <security>
    <requestFiltering>
      <requestLimits maxAllowedContentLength="15728640" /> <!-- 15MB -->
    </requestFiltering>
  </security>
</system.webServer>

## Case #12: 上傳事件日誌與審計追蹤

### Problem Statement（問題陳述）
業務場景：需追蹤誰在何時上傳了什麼檔案、來源 IP、結果如何，支援問題追查與合規審計。現況日誌不全或分散。

技術挑戰：結構化日誌、關聯 requestId/userId、從應用到儲存全鏈路記錄。

影響範圍：資安審計、客服支援、法遵。

複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. 日誌無結構化，難搜尋。
2. 缺 requestId/userId。
3. 無統一存放與保留策略。

深層原因：
- 架構層面：缺集中式日誌。
- 技術層面：未導入 logger 與 schema。
- 流程層面：保留期與查詢方式未定義。

### Solution Design（解決方案設計）
解決策略：以 Serilog/NLog 輸出 JSON 日誌，紀錄 userId、fileName、size、ip、result、reqId；集中到 ELK/Grafana Loki；建立查詢範本與保留策略。

實施步驟：
1. 結構化日誌
- 實作細節：以 logger.ForContext 豐富欄位
- 所需資源：Serilog、Sink
- 預估時間：0.5 天

2. 集中式儲存與查詢
- 實作細節：ELK/Loki 管道與索引
- 所需資源：日誌平臺
- 預估時間：1 天

關鍵程式碼/設定：
```csharp
_logger
  .ForContext("UserId", user)
  .ForContext("FileName", media.name)
  .ForContext("Size", media.bits?.Length ?? 0)
  .ForContext("Ip", HttpContext.Current?.Request.UserHostAddress)
  .ForContext("ReqId", Trace.Id)
  .Information("Upload {Result}", "Success");

## Case #13: 與舊流程相容的 FTP 過渡策略與自動匯入

### Problem Statement（問題陳述）
業務場景：部分舊工具或作者仍依賴 FTP，上線 newMediaObject 後短期內無法全面切換。需要過渡策略：保留 FTP 一段時間並自動匯入/轉連結。

技術挑戰：監控 FTP 目錄、將新檔移轉到媒體儲存、生成統一 URL、避免重複與競態。

影響範圍：使用者體驗、資料一致性、維運成本。

複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 舊編輯器不支援 newMediaObject。
2. 作者習慣未改。
3. 缺自動匯入機制。

深層原因：
- 架構層面：單一上傳入口未完成。
- 技術層面：缺目錄監控與去重。
- 流程層面：沒有遷移計畫與期限。

### Solution Design（解決方案設計）
解決策略：建立 FTP 掃描器，定期將 FTP 上的新增檔移入媒體庫並產生標準 URL；在後台提示改用 API；設定停用時程。

實施步驟：
1. 監控與匯入
- 實作細節：掃描檔案、檢查哈希去重、移動與回寫 URL 清單
- 所需資源：計畫性工作（Windows Task/Hangfire）
- 預估時間：1-2 天

2. 溝通與停用
- 實作細節：公告時程與替代方案
- 所需資源：文件/公告
- 預估時間：0.5 天

關鍵程式碼/設定：
```powershell
# PowerShell - 每 5 分鐘掃描 FTP 根目錄
$src="D:\ftp\uploads"; $dst="D:\app\media\legacy"
Get-ChildItem -Path $src -File | ForEach-Object {
  $hash = (Get-FileHash $_.FullName -Algorithm SHA256).Hash.Substring(0,12)
  $newName = "$hash$($_.Extension.ToLower())"
  Move-Item $_.FullName (Join-Path $dst $newName)
  # 將新 URL 寫入匯入清單供應用讀取
}

## Case #14: 跨用戶端相容性測試（Live Writer/MarsEdit 等）

### Problem Statement（問題陳述）
業務場景：不同部落格編輯器對 newMediaObject 的實作差異可能導致相容性問題（含 MIME、認證、回傳欄位大小寫）。需建立測試矩陣確保主流客戶端可用。

技術挑戰：自動化相容性測試、差異化處理與快速回報。

影響範圍：整體上線成功率、客服負擔。

複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 客戶端行為不一致。
2. 回傳欄位大小寫差異導致解析失敗。
3. 認證與 TLS 支援差異。

深層原因：
- 架構層面：缺正式兼容測試。
- 技術層面：缺測試腳本與容器化客戶端。
- 流程層面：缺回歸標準。

### Solution Design（解決方案設計）
解決策略：建立測試矩陣（客戶端 x 檔案型別 x 認證/TLS 組合），以 Python 腳本與手動工具混合測試；建立兼容性備忘錄。

實施步驟：
1. 測試腳本與案例
- 實作細節：用 Python 驗證關鍵行為；紀錄差異
- 所需資源：腳本、測試帳號
- 預估時間：1 天

2. 手動工具測試
- 實作細節：Live Writer/MarsEdit 發文貼圖
- 所需資源：測試環境
- 預估時間：0.5-1 天

關鍵程式碼/設定：
```bash
# 測試矩陣樣例（bash + python）
clients=("python" "wlw" "marsedit")
files=("a.jpg" "b.png" "c.webp")
for c in "${clients[@]}"; do
  for f in "${files[@]}"; do
    python test_upload.py --client "$c" --file "$f" --tls "1.2"
  done
done

## Case #15: 使用者溝通與遷移計畫（FTP 停用與文件更新）

### Problem Statement（問題陳述）
業務場景：平台從 FTP 過渡到 newMediaObject，需要一份清晰的遷移計畫：時間表、操作指南、常見問題、回退方案與停用節點，確保用戶順利切換。

技術挑戰：跨部門溝通、文件產出、通知節奏、使用者回饋收集與追蹤。

影響範圍：所有作者與管理員、客服工作量。

複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. 使用者對新流程不熟悉。
2. 工具設定差異造成上手障礙。
3. 無清晰停用時程。

深層原因：
- 架構層面：缺少變更管理流程。
- 技術層面：文件與樣例不足。
- 流程層面：無分階段推進策略。

### Solution Design（解決方案設計）
解決策略：發布遷移公告（T0），提供設定指南與腳本；T+14 停止新建 FTP 帳號；T+30 限縮、T+45 完全停用；全程收集回饋與迭代文件。

實施步驟：
1. 文件與教學
- 實作細節：圖文版設定指南、常見錯誤碼表
- 所需資源：文件平台
- 預估時間：0.5-1 天

2. 節點與通知
- 實作細節：站內信/郵件三階段通知、儀錶板提示
- 所需資源：通知服務
- 預估時間：0.5 天

關鍵程式碼/設定：
```text
遷移節點：
- T0：開放 newMediaObject；公告 + 教學
- T+14：停發 FTP 新帳號；保留既有
- T+30：FTP 只讀；啟動自動匯入
- T+45：FTP 完全停用