Ray Liu's Blog

前言2026 年 10 月的這波安全更新，Go 的重點落在 TLS 憑證信任。CVE-2026-111943 對應標準函式庫 crypto/x509 的緊急修補：驗證憑證鏈時，拒絕信任與本次事件相關的中繼 CA 金鑰。官方要求立即升級至 Go 1.26.10 或 1.27.3，漏洞資料庫編號為 GO-2026-6809。Go 發布公告、Go 漏洞資料庫 如果你維護的是 Go API、Webhook、SSO 整合、反向代理或 CLI，這次需要一路追到實際執行的二進位檔。一般 Go 應用會將用到的標準函式庫程式碼編進產物；更新建置機上的 Go 之後，還要重新編譯、發布並替換正式環境中的舊程序，才能套用這段驗證邏輯。 查核日期：2026-10-22，台灣時間 UTC+8。 本文依 Go 官方公告、CVE／Go 漏洞資料庫、公開修補程式碼及業者公告整理。文中的盤點情境與指令供讀者套用，未針對實際服務執行漏洞利用或連線測試。封面為 AI 生成的概念插畫，以鈷藍信任鏈及被移除的琥珀色共同金鑰連結呈現修補意象。 一、先釐清日期與版本：10/21 建檔，修正版已先發布安全新聞裡...

前言2026 年 10 月 21 日，除了 PHP 的緊急安全更新，Node.js 也釋出新版本，處理 10 項漏洞：4 項 High、3 項 Medium、3 項 Low。最高等級為 High，其中 CVE-2026-111497 涉及 Brotli 解碼器的越界寫入，官方列出的影響包含遠端程式碼執行（Remote Code Execution，RCE）。Node.js 官方安全公告 對維運與後端團隊來說，應先確認實際執行的版本，再看程式用到哪些功能。接收外部壓縮資料、呼叫外部 HTTP／HTTPS 服務、使用自訂啟動快照，以及依賴 Permission Model 限制檔案操作，是這篇要逐一說明的盤點方向。 查核日期：2026-10-22，台灣時間 UTC+8。 本文解讀 10 月 21 日的官方公告、發布紀錄與公開修補程式碼；程式碼檢閱與利用重現是不同層次的證據，本文未執行漏洞 PoC。封面為 AI 生成的概念插畫，以折疊材料越過檢查框呈現邊界檢查的意象。 一、先確認更新版本：22.23.4、24.22.1、26.12.1本次三條受支援分支都已有安全版本。若仍使用本...

前言2026 年 10 月 21 日晚間，pixiv、Niconico、BASE 與多款日本遊戲陸續出現緊急維護公告。這波異動的重要背景，是 PHP 發布兩個重大漏洞的安全更新：CVE-2026-109618 與 CVE-2026-109619，研究團隊將相關問題稱為 PHP2Shell。PHP 官方確認，它們可能讓未登入的攻擊者在受影響伺服器上執行程式碼。本文會整理漏洞原理、更新範圍與各站公告。PHP 官方公告、Wiz 研究報告 先補上最容易過時的一項消息：pixiv 已公告於日本時間 10 月 21 日 23:30，也就是台灣時間 22:30，結束緊急維護。 原先預告的「維護到隔天凌晨」已經有更新；停站與恢復時間都應以官方後續公告為準。pixiv 維護完成公告 資料截點：2026-10-21 22:53，台灣時間 UTC+8。 相當於日本時間 2026-10-21 23:53（UTC+9）。本文網站維護表統一使用日本時間，預定結束時間不代表實際恢復時間。封面為 AI 生成的概念插畫，描繪服務暫停後修補共用元件，並非事件現場或遭駭證據。 一、今晚發生什麼事？先掌握嚴重程...

前言DeepSeek 在 2026 年 10 月 17 日推出 DeepSeek-V4.1-Flash-1017，是 9 月 V4.1 Flash 的更新版。這次發布的主題是「Wish-Driven Programming（願望驅動編程）」：官方說法是把一個完整專案交給模型，由它自己規劃、產生、檢查再修正到可交付的成果。官方釋出的示範涵蓋 3D 建模、網頁遊戲與 Godot 引擎重製，訴求是「講出願望，模型完成開發」。官方發布說明 同一天 DeepSeek 也開放自研的 Search 與 Fetch API，讓 Agent 能自行搜尋網頁並讀取正文。這篇整理截至 2026 年 10 月 17 日 的官方資訊，包含這次改了什麼、基準數據怎麼看、API 與收費的變化，以及導入時要留意的地方。 官方把這次更新形容為效能與成本之間的 Pareto 改良（Pareto improvement）：基準表現更好，同時縮短任務執行時間、減少輸出長度。但這些數字主要來自 DeepSeek 自己的測試，實際效益仍取決於你用的 Agent 框架、任務類型與執行設定，不能直接當成團隊的成效保證。 ...

前言在 Laravel 專案裡，如果一百個後台列表都有相似的篩選、排序與分頁，我們可能會建立一個共用 Repository，讓大家從同一個入口取資料。轉到 C# 後，卻常看到另一種建議：直接使用 EF Core，把查詢條件抽成 IQueryable<T> 擴充方法。兩邊都在解決重複程式碼，差異到底在哪裡？ 類似的疑問也會出現在 Middleware、Service Provider、Model、Event 與 Validation。熟悉 Laravel 的經驗很有用，但遷移時需要重新確認三件事：這個元件負責什麼、活多久，以及在哪個時機真正執行工作。 這篇以 ASP.NET Core 與 EF Core 為核心，整理這些概念的對應與實務取捨。 本文依 2026-10-16 查閱的 Laravel 13.x、ASP.NET Core 10 與 EF Core 官方文件整理。C# 程式碼是聚焦概念的片段，省略完整型別、DI 註冊與錯誤回應整合，未建立或執行完整範例專案；版本特有行為會另外註明。 一、先用職責對照，避免只翻譯名稱有些概念十分接近，有些則需要拆成幾個元件...

前言假設今天要用 C# 寫一套訂單後端，包含建立訂單、查詢、付款狀態更新與取消訂單。採用三層架構，可以從 Controller → Service → Repository 開始；採用 DDD，可能會出現 Application、Domain、Infrastructure；採用垂直切片，又會變成 Features/Orders/Cancel。光看目錄，很難判斷這些選擇在實際開發上差在哪裡。 這篇固定使用同一套 ASP.NET Core API、EF Core 與 PostgreSQL，以「取消訂單」比較三種寫法，再把需求改成「多個入口共用規則」「與付款同時發生」「取消後要發送通知」，觀察程式碼與責任如何變動。比較集中在專案內部的設計、開發與維護成本。 本文的「垂直架構」指 Vertical Slice Architecture，垂直切片架構。程式碼為說明責任配置的核心片段，省略 DI、完整型別、EF 對應與例外轉譯，沒有建立或執行三套可重現的 C# 範例專案；文中的選型是依情境提出的工程判斷。 一、先釐清：這三個名稱關注的事情不同三層、DDD 與垂直切片可以放在一起討論，...

前言「把一部分查詢搬去 MongoDB，真的會比較快嗎？」「Cassandra、ScyllaDB 為什麼能存那麼多聊天訊息？」「NoSQL 是不是為了效能，接受寫入成功後資料還會消失？」這幾個問題其實連在一起：資料庫用什麼方式組織資料，以及它回覆成功時，到底承諾了什麼。 這篇從實際選型出發，先整理各類資料庫擅長的工作，再深入 MongoDB、Cassandra、ScyllaDB 與 Discord 的遷移案例，最後回到資料遺失、讀寫一致性和 CQRS（命令與查詢職責分離）讀模型。重點是找出哪個工作負載值得換工具，以及換了之後要承擔哪些責任。 先分清楚：資料模型、交易保證與擴展方式NoSQL 是一個範圍很廣的分類，包含文件、鍵值、寬列、圖等不同模型。**ACID 描述交易的原子性、一致性、隔離性與持久性，和是否使用 SQL 是不同維度。**例如 MongoDB 支援單文件原子操作，也支援跨文件與分片叢集的交易，不能直接把它歸類成「沒有交易保證」。MongoDB 原子性與交易 同樣地，「有多台機器」也可能代表不同事情：有些副本是保存相同資料、分擔讀取；有些分片則各自保存不同資料、...

前言假設要做同一套會員與訂單 API：有路由、驗證、ORM、資料庫連線、Redis 快取與 JSON 回應，分別用 Go、C#、Java、Node.js、PHP 實作。在功能一樣、部署成容器的前提下，哪一種比較省記憶體？哪一種容易在高流量下卡住？正式環境又要多照顧哪些地方？ 我的選型起點是：**重視精簡常駐服務，先評估 Go；重視複雜業務與持續吞吐，評估 C#、Java；以 TypeScript 整合服務，評估 Node.js；快速交付商業 CRUD，評估 Laravel，並把 FPM 與 Octane 分開看。**接下來把這些判斷放進同一個專案比較，說明背後的 CPU、記憶體與執行模型差異。 比較基準：同樣功能、相同資源與相同達標條件本文比較的是 Linux 容器中的後端 API。JavaScript／TypeScript 都以 Node.js 執行後端來看；C# 使用現代 ASP.NET Core。PHP 則分成傳統 PHP-FPM 與 Laravel Octane，因為兩者的請求生命週期不同。 先定義一套共同的微服務規格，避免拿精簡 JSON endpoint 和完整訂...

前言Claude Code 不只是能讀取程式碼、呼叫終端機的 AI 工具。把專案規範、依路徑載入的規則、可重複執行的 Skills，以及環境變數與 Hooks 設定好之後，它才能在不同專案裡穩定使用正確的建置方式、編輯習慣和工具權限。 這篇整理 Claude Code 的幾種設定方式，並釐清一個容易搞混的問題：**.claude/rules/ 裡的 Rule 是提示 Claude 的 Markdown 指令，不能直接設定 Shell 環境變數。**本文依 Anthropic 官方文件截至 2026 年 10 月 14 日 的內容撰寫；Claude Code 仍在持續更新，實際可用欄位請以官方文件及本機版本為準。 封面為 AI 生成的概念插畫，呈現專案指令、路徑規則、工作流程與執行環境之間的關係。 先建立設定的心智模型Claude Code 有多種可調整的層次。它們看起來都像「設定」，實際上作用不同：有的提供上下文，有的改變程式的執行環境，有的在特定事件發生時執行程式。 機制 主要用途 載入或執行方式 CLAUDE.md 專案架構、慣例、常用命令等持續適用的背景 進...

前言AI 寫的文字有辦法被辨識嗎？OpenAI 在 2026 年 10 月 5 日公布文字浮水印技術 textGrain：它不會在句子裡插入看得見的標記，而是在生成時讓選字帶有統計訊號，再由偵測器判斷文字是否含有這種訊號。OpenAI 公告 這項消息和歐盟《AI Act》的生成內容透明度規範有關，但「偵測到浮水印」不能直接證明誰寫了文章，也不能證明整篇都由 AI 產生。本文以 2026 年 10 月 6 日為準，說明 textGrain 的基本原理、OpenAI 公布的測試結果，以及實際使用時需要保留的判斷空間。 封面為 AI 生成的概念插畫，用紙帶與隱約出現的規律符號表現統計浮水印；不是 OpenAI 產品畫面，也不是 textGrain 的演算法圖。 文字浮水印和一般 AI 偵測器有什麼不同？一般 AI 文字偵測器通常會根據輸出文字的特徵，估算內容由模型生成的可能性。textGrain 則在生成文字時，把訊號放進選字的統計關係中，之後再由配套的偵測器尋找訊號。 這有點像在紙張中混入肉眼看不見的纖維。一般偵測器只能從文章外觀猜測來源；浮水印則需要生成端先嵌入訊號，偵測...