程式設計

起因是撰寫的油猴腳本使用 localStorage 存資料，到某一天發現資料怎麼存不進去了，排查才發現資料超過 5MB 了，然後就開始找有沒有其他更好的存資料方式，最後發現了瀏覽器資料庫 API——IndexedDB。 什麼是 IndexedDB?IndexedDB 是一個低階的 API，用於在瀏覽器中儲存大量結構化資料。它讓你可以在使用者端存放遠超 localStorage 的資料量（實際上限依磁碟配額決定），而且所有操作都是非同步的，不會卡住主執行緒。與 localStorage 不同，IndexedDB 可以處理更複雜的資料結構，也支援索引搜尋。 為什麼要用 IndexedDB? 儲存大量資料：相較於 localStorage 的 5MB 限制，IndexedDB 的上限由磁碟配額決定，通常是可用空間的數十趴，幾乎不會遇到瓶頸。 支援複雜資料結構：可以直接儲存和查詢 JavaScript 物件，不需要手動 JSON 序列化。 非同步操作：不會阻塞主執行緒，頁面不會因為資料操作而卡頓。 支援交易（Transactions）：確保一批操作全部成功或全部回滾，不會出現資料寫到一半...

處理程序（Process）和執行緒（Thread）是作業系統的核心概念，也是理解並行程式設計的起點。用一個生活比喻來拆解兩者的差異，往往比讀定義清楚得多。 處理程序 vs 執行緒：一個家庭的故事想像有一個家庭經營著一間小餐廳。在這個比喻中： 整個餐廳就像一個處理程序 家庭成員則是執行緒 處理程序（餐廳） 擁有自己的資源：廚房設備、座位區、食材等 有獨立的記憶體空間：存放菜單、庫存清單等資訊 啟動和關閉成本較高：開店和打烊需要較多時間和精力 執行緒（家庭成員） 共享餐廳的資源 可以快速切換任務：爸爸可以從煮菜轉去招呼客人 建立和銷毀成本較低：家庭成員可以快速加入工作或休息 多執行緒：實際跑起來是什麼樣子這個家庭實際跑起來的樣子： 並行處理： 媽媽在廚房煮菜 爸爸在前台招呼客人 哥哥負責送餐 妹妹處理結帳 資源共享：所有人共用廚房的爐子、冰箱，不需要每個人準備一套。 動態調度：前台突然湧入大批客人時，爸爸可以直接喊哥哥過來幫忙——對應執行緒在同一份共享記憶體上協作，切換成本遠低於重新開一間分店（另起一個處理程序）。 多執行緒的優缺點優點 提高系統吞吐量 改善反應...

在 JavaScript 中，我們經常需要檢查一個字串是否包含某個特定的字元或子字串。本文比較三種常用方法：indexOf()、includes() 和 filter()，涵蓋語法、可讀性、相容性與效能差異。 1. indexOf() 方法indexOf() 是最古老且支援度最廣的方法之一。 語法1string.indexOf(searchValue[, fromIndex]) 用法123const str = "Hello, World!";const hasO = str.indexOf('o') !== -1; // trueconst hasZ = str.indexOf('z') !== -1; // false 優點 相容性好，支援舊版瀏覽器 可以指定開始搜尋的位置 缺點 返回值不是布林型，需要與 -1 比較 程式碼可讀性較差 2. includes() 方法includes() 是 ES6 引入的方法，專門用於檢查字串是否包含特定子字串。 語法1string.includes(searchStrin...

Go 是 Google 於 2009 年釋出的靜態強型別語言，編譯速度快、垃圾回收輕量、內建並發原語。定位是系統程式設計與後端服務，不是「靜態語言的安全性加上動態語言的高效性」——它本質上就是靜態語言，只是刻意把複雜度壓低。 先備知識Go 不適合作為第一門語言。建議先有任何一門語言的基礎，理解變數、迴圈、函式的概念。若尚未有程式基礎，先補 Python 或 JavaScript。 安裝環境前往 go.dev/dl 下載對應平台的安裝包。安裝完成後執行： 1go version 確認輸出版本號即安裝成功。 關於 GOPATH 與 Go Modules：Go 1.11 引入 Modules，1.16 起預設啟用。現代專案用 go mod init 初始化模組，原始碼放在任何目錄都行，不再需要把程式碼塞進 $GOPATH/src。$GOPATH 仍然存在，但現在只作為模組快取（$GOPATH/pkg/mod）和已安裝工具（$GOPATH/bin）的存放位置，不需手動設定。 新建一個最小模組： 12mkdir myapp && cd myappgo mod init g...

.NET Core 中的中間件（Middleware）詳解什麼是中間件？在 .NET Core 應用程式中，中間件是一系列組件，它們形成了一個請求處理管道。每個中間件都可以: 處理傳入的 HTTP 請求 處理傳出的 HTTP 回應 呼叫管道中的下一個中間件 在管道中的下一個中間件完成處理後執行某些操作 中間件的概念類似於一條組裝線，每個工人（中間件）都對產品（請求/回應）進行某些操作。 中間件的工作原理中間件在 .NET Core 應用程式中按照特定的順序執行。這個順序很重要，因為它決定了哪個中間件先處理請求，以及回應如何被處理。 工作流程如下： 當應用程式接收到 HTTP 請求時，請求進入中間件管道。 每個中間件組件可以: 執行一些操作 將請求傳遞給下一個中間件 或者短路請求（不再傳遞給後續中間件） 一旦請求到達管道的末端，它會開始返回。 回應會再次通過所有中間件，讓每個中間件有機會處理或修改回應。 這個過程可以用下面的示意圖來表示： 12Request → Middleware 1 → Middleware 2 → Middleware 3 → Applicati...

排序演算法完整指南四種排序演算法的核心差異就是複雜度與穩定性的取捨，這也是面試最常考的切入點。以下逐一拆解快速排序、選擇排序、氣泡排序、插入排序的工作原理與 JavaScript 實作。 排序演算法視覺化 快速排序 pivot 選擇排序 氣泡排序 ...

IoC（控制反轉）和 DI（依賴注入）常被混用，但兩者的層次不同：IoC 是設計原則，DI 是實現手段之一。搞清楚這個關係，才不會看到「容器」兩字就覺得是 IoC 的全部。 控制反轉 (IoC) 是什麼傳統寫法裡，程式碼自己決定何時建立依賴、用哪個實作——控制權在你的類別手上。IoC 把這個控制權交出去：由外部（框架、容器、或呼叫方）決定要注入什麼。 IoC 並不等於 DI 容器。Martin Fowler 最早定義 IoC 時，涵蓋了 Service Locator、Template Method、以及依賴注入等多種形式。DI 容器只是實現 IoC 最常見的一種工具。 IoC 帶來的實際好處： 解耦：類別依賴介面而非具體實作，替換實作時不需動到使用方。 可測試性：測試時可把真實依賴換成 mock，不需啟動整個應用程式。 可擴展性：新增實作、切換策略，不需修改現有程式碼。 這三點都源自同一個機制——類別不再自己 new 依賴，而是被動接受注入。 依賴注入 (DI) 的注入方式DI 的核心想法：不在類別內部建立依賴物件，改由外部傳入。 注入方式有三種，但在 .NET 內建 DI...

水平置中看似基礎，但選錯方法往往要多加幾行補丁才能修正。以下五種寫法各有適用條件，選之前先確認目標元素是行內還是區塊、有無固定寬度、父容器是否允許改動。 1. text-align: center作用在父容器，讓其中的行內元素或行內區塊元素水平置中。 123.parent { text-align: center;} 文字、<span>、<img>、display: inline-block 的元素都吃這個規則；display: block 的子元素不受影響。如果要置中的是區塊元素，這條沒用。 2. margin: auto把區塊元素的左右邊距都設為 auto，瀏覽器會平均分配剩餘空間。 1234.child { width: 300px; margin: 0 auto;} 不想寫死寬度的話，可以用 width: fit-content，寬度跟著內容走，同樣能置中： 1234.child { width: fit-content; margin: 0 auto;} 兩種寫法的前提一...

在 Vue.js 生態系統中，Pinia 是目前官方推薦的狀態管理函式庫。不過，當我們透過 Pinia 儲存資料時，這些資料究竟放在哪裡？本文拆解 Pinia 的運作原理，以及它如何處理資料儲存。 Pinia 的核心概念Pinia 把應用程式的狀態切成獨立的「store」，每個 store 負責管理一塊特定的狀態。這種設計讓狀態管理更模組化，也比較容易維護。 定義一個 store 的基本寫法： 12345678910111213import { defineStore } from 'pinia'export const useCounterStore = defineStore('counter', { state: () => ({ count: 0, name: 'guest', }), actions: { increment() { this.count++ }, },
...

在 Vue.js 的狀態管理領域，Pinia 和 Vuex 是兩個主要的選擇。兩者解決的問題相同，但設計理念和使用方式有顯著差異。本文逐項比較它們的差異，幫你判斷哪個更適合手邊的專案。 1. 起源與發展Vuex Vuex 是 Vue.js 的官方狀態管理函式庫，於 2015 年發布。 遵循 Flux 架構，設計初衷是處理大型複雜應用的狀態管理。 Pinia Pinia 由 Vue 核心團隊成員 Eduardo San Martin Morote 開發。 最初作為 Vuex 5 的概念驗證而建立，後來發展成獨立專案。 Vue 3 發布後，Pinia 迅速獲得社群青睞，最終成為 Vue 官方推薦的狀態管理方案。 2. 核心概念Vuex Store：單一狀態樹，作為應用的唯一資料來源。 State：存儲應用的響應式狀態。 Getters：從 store 派生出的狀態。 Mutations：用於修改狀態的同步函式。 Actions：可包含非同步操作的函式，用於提交 mutation。 Modules：將 store 拆分成模組，每個模組擁有自己的 state、mutation、act...