yeonghyeon · 2026年4月15日

什麼是 JSON？寫給非開發者店主的入門指南

大家好，我是 yeonghyeon，負責 3Min API 的開發。

在上一篇 API 篇裡，我說「API 就是以約定好的位址收發約定好形狀訊息的窗口」。當時特意把「訊息的形狀」留到了後面——今天就是那塊最後的拼圖。這篇要講的，就是在器（資料庫）和通道（API）之間真正往來的「訊息」到底長什麼樣，也就是 JSON。

📚 寫給非開發者的資料基礎三部曲

資料庫 — 裝資料的器
API — 安全進出的窗口
JSON — 往來訊息的形狀（當前文章）

今天文章的目標不是「背下語法」。只要能達到「我可以把自己生意裡的一件事寫成一塊 JSON」這種感覺，就夠了。一旦有了這種感覺，以後和開發者、和 AI 對話時，彼此的語言就拉近了一大步。不需要任何前置知識。

什麼是 JSON

先看一眼辭典式的定義。維基百科把 JSON（JavaScript Object Notation）描述為「一種使用人類可讀文字來表示由屬性-值對和陣列組成的資料物件的開放標準檔案格式」。

用一句話收一下：

JSON = 按照約定的寫法，把系統之間要交換的資料記下來的一段文字，人眼也能讀得懂。

其實系統之間交換訊息的方式不止 JSON 一種，還有 XML、YAML、Protocol Buffers 等等。那為什麼今天的 Web API 幾乎都選 JSON？原因很樸素：人能看懂，程式也能看懂，兩頭都直觀。開發者用記事本打開就能讀，伺服器解析起來也很快。同時把這兩件事做好的格式，並不多見。

為什麼需要「約定好的形狀」

在前兩篇裡，我們已經有了器（DB）和通道（API）這兩樣工具。可是光有工具，資料並不會自己流起來。如果每個來到窗口的人都拿張不同的紙、隨便寫點什麼遞進去，櫃員連一件都處理不了。

所以銀行會提前準備好制式表單——存款單、取款單、匯款申請單。表單一致，櫃員才能快速核對，記錄也才能自動留下。API 也是出於一模一樣的理由：它提前把「進這個窗口的訊息應該長這樣」這條約定固定下來。把那種「形狀」寫出來的標準語法，就是 JSON。

JSON 成為事實標準之前，每個系統都自己一套訊息格式。有的用逗號分隔的一行文字，有的用層層標籤包起來的 XML，有的做一套只寫在內部文件裡的二進位格式。每接一個新的合作方，就要翻一輪文件、再寫一遍解析程式碼。JSON 成了事實標準之後，「我們用 JSON 往來吧」這一句話，就能把大部分協作啟動起來。

用 Excel 來理解 JSON

在直接看 JSON 語法之前，先從大家熟悉的 Excel 起步。想像一張 Excel 表：最上面一列是欄位名稱（商品名、數量、金額……），下面每一列代表一列就是一筆交易。

把這個結構原樣搬到 JSON，對應得非常自然：

Excel 的欄位名稱 → JSON 的鍵（key）
一格裡填的值 → JSON 的值（value）
Excel 的一列 → JSON 的一個物件（{}）
Excel 的多列 → JSON 的陣列（[]）

假設訂單表的一列長這樣：

order_id	product	quantity	amount
A-2026-0001	Château Margaux 2020	2	480000

把這一列原樣挪到 JSON 物件裡，就是這樣：

{
  "order_id": "A-2026-0001",
  "product": "Château Margaux 2020",
  "quantity": 2,
  "amount": 480000
}

名字後面一個冒號，項目之間一個逗號，外面用一對大括號包起來。規則就這麼些。這一塊就是裝了跟 Excel 一列完全相同的資訊的 JSON 物件。

那既然有 Excel，為什麼還單獨需要 JSON？差別在層級和靈活度兩處。Excel 的一個格子裡很難再塞一張表，而且列與列的欄位一旦不一致，管理馬上就亂。JSON 則可以很自然地在值的位置再放進一個物件或陣列，每一筆可能不同的選填欄位也能輕鬆裝進去。如果說 Excel 像一本「平鋪的帳本」，JSON 就像一本「需要的時候能像資料夾一樣折起來的帳本」。

葡萄酒店店主的訂單單

接著上一篇的場景繼續。網路商店裡新來了一筆訂單。門市 POS 和合作餐廳也都看著同一個資料庫，中間的通道就是 API。那我們現在就看看，真正飛到這個 API 窗口的訊息到底長什麼樣。

網店給葡萄酒店的「建立訂單 API」發來這麼一塊 JSON：

{
  "order_id": "A-2026-0412",
  "customer": {
    "id": "C-00871",
    "name": "Alex",
    "email": "alex@example.com"
  },
  "items": [
    {
      "sku": "WINE-MARGAUX-2020",
      "name": "Château Margaux 2020",
      "quantity": 2,
      "unit_price": 240000
    },
    {
      "sku": "WINE-OPUS-2019",
      "name": "Opus One 2019",
      "quantity": 1,
      "unit_price": 520000
    }
  ],
  "total_amount": 1000000,
  "ordered_at": "2026-04-15T14:23:00+09:00"
}

這一塊裡頭，誰（customer）、買了什麼（items）、花了多少（total_amount）、什麼時候買的（ordered_at），全齊了。之前說的「不是平鋪帳本，是能折起來的帳本」是什麼意思，在這兒一眼就能看出來：顧客是一個帶了自己明細（姓名、信箱）的小塊，購買的商品是一份兩條的清單。如果用 Excel，這些資訊得分別記在顧客表、訂單表、訂單明細表裡；現在它們清清爽爽裝在一個信封裡。

API 窗口接到這個信封的第一件事，就是檢查它是不是「約定好的形狀」。order_id 空著、quantity 裡塞了不是數字的東西、customer 裡面少了 email——只要有任何一條不對，當場就拒收。這樣一來，資料庫裡堆起來的訂單永遠是同一個形狀，以後要拉統計、或者匯出到別的系統裡，都不會手忙腳亂。

付款完成之後，金流服務又會往葡萄酒店另一個窗口送回一塊 JSON，說「這單付款成功了」。像這種由對方系統先來告訴我們的方式，上一篇裡提過，有個專門的名字叫 Webhook。Webhook 的本文也是 JSON。請求是 JSON，回應是 JSON，通知還是 JSON。系統之間來來往往的訊息幾乎全是同一種格式——正是這一點，讓今天的網際網路跑得這麼順。

JSON 語法：鍵、值、物件、陣列

下面把語法非常簡短地梳理一下。JSON 的規則少得讓人吃驚。下面這四條記住，您就能讀懂 99% 的 JSON 了。

1) 鍵-值對 — 最小單元

最基本的，就是把「名稱」和「內容」用一個冒號串起來的一對。名稱必須用雙引號括起來。

"product": "Château Margaux 2020"

2) 值的種類 — 四種基礎 + 兩種結構

能放在「值」這個位置上的東西是定好的：

字串：用雙引號括起來的文字。例如："Alex"
數字：不加引號，直接寫。例如：480000
布林：true 或 false（不加引號）
空：null（表示「現在還沒值」）
物件：用大括號 {} 包起來的一組鍵-值
陣列：用方括號 [] 包起來的一串值

3) 物件 {} — 一束鍵-值

把幾對鍵-值用逗號拼起來，外面再套一對大括號，就是一個物件。Excel 的一列就對應這樣的一個物件。

{
  "name": "Alex",
  "email": "alex@example.com",
  "is_member": true
}

4) 陣列 [] — 相同形狀的並列

把若干個值用逗號並列起來，外面套一對方括號，就是陣列。Excel 的多列就對應這樣的一個陣列。

[
  { "sku": "WINE-MARGAUX-2020", "quantity": 2 },
  { "sku": "WINE-OPUS-2019",    "quantity": 1 }
]

接下來這一點才是真正關鍵。您大概注意到了：剛才那個陣列裡的每個元素，本身又是一個物件。值的位置，既可以再放一個物件，也可以再放一個陣列。就憑這一條遞迴規則，JSON 就能裝下任意複雜的資訊。葡萄酒店那張訂單單之所以能寫出「一單裡有好幾樣商品，每樣商品裡又有名字、數量、單價……」這種結構，靠的就是這個。

用三層堆疊的立體方塊呈現 JSON 階層結構的示意圖。最底層是 Nested Pairs（巢狀的鍵-值對），中間層是 Objects & Array（物件與陣列），最上層是 Root Object（最外層物件），直觀展示「小單位層層聚合成更大結構」的 JSON 遞迴階層

一句話總結一下 JSON：鍵-值是最基本的一對，可以把若干對打包成物件，也可以把若干物件並列成陣列。再加上值的位置還能再放進物件或陣列。一整套語法其實就這一句話。

JSON 都用在哪裡

除了葡萄酒店那張訂單單，JSON 其實早已深深嵌進我們的日常生活，只是不顯眼罷了：

手機 App 和伺服器之間的通訊：Instagram 的動態消息、外送 App 的店家列表、股票 App 的行情 —— 幾乎全是 JSON 在來回跑。
設定檔：VS Code 的設定，以及許多開發工具的設定檔，都是 JSON 格式。選 JSON 就是為了讓人類自己能打開、自己改。
公共資料、開放資料：政府和公家機構開放出來的資料 API，相當一部分都用 JSON 回應。
SaaS 串接和 Webhook：金流服務、物流業者、訊息平台、郵件服務發過來的通知，也都是一塊 JSON。
AI / LLM 的結構化輸出：讓 ChatGPT、Claude 這類模型「結果用 JSON 給我」，它會回傳一份可以直接拿來用的結構。JSON 同時也是 AI 與業務系統之間的共通語言。

有一件事千萬別搞錯：JSON 不是「格式隨您寫的資料」。恰恰相反。正如 Chae-won 在前一篇您的資料值得一個計畫裡強調的那樣，JSON 真正發揮作用，靠的是事先把「這個端點的 JSON 有哪些欄位」這個約定講清楚。自由的是語法，欄位設計並不自由。只要記住這個差別，圍繞 JSON 的多數誤解就會一掃而空。

到目前為止的整理 · 系列收尾

把三部曲放到一起總結一下：

第 1 篇：資料庫 — 搭了一個把業務資料以同樣形狀堆起來的器。
第 2 篇：API — 給這個器搭了一個讓外部能安全進出的通道（窗口）。
第 3 篇：JSON — 把這個窗口之間來往的訊息的形狀定了下來。

這三件事一齊到位的那一刻，您的生意第一次長出了就算人不在身邊也能自己跑的系統的雛形。網店來了訂單，一塊 JSON 經過 API 窗口進到 DB；金流服務用一塊 JSON 告訴我們結果；門市 POS 用一塊 JSON 去扣庫存。店主睡覺的時候，這些訊息也在同一套約定上悄悄地來回跑。「自動化」這三個字的真相，最後落到底就是這三個約定的組合。

更重要的是，只要把這三個概念拿穩了，以後碰到的所有新名詞（GraphQL、事件串流、MCP、AI Agent……），都不過是疊在這套骨架上的變體而已。骨架立住了，枝葉很快就會跟上。

今天就能動手試的事

既然是系列的最後一篇，今天的練習也設計成能和前兩篇連起來。一張紙、一個 AI、一個瀏覽器，就夠了。

Action 1. 把自己生意裡的一件事寫成 JSON

把您在上一篇 API 篇裡挑出來的那件事（比如：下單、登記預約、接收詢問）拿出來。把裡面涉及到的項目，一項一項挪到同一塊 JSON 裡就行。剛開始寫成平鋪的也沒關係；熟了之後，把像顧客、商品這些會「膨脹起來」的地方折成物件裡的物件。

{
  "reservation_id": "R-2026-0001",
  "customer": {
    "name": "Alex",
    "phone": "+886-9xx-xxx-xxx"
  },
  "date": "2026-05-12",
  "party_size": 4,
  "note": "希望靠窗座位"
}

這一塊，就是把「我生意裡的一件事」搬成系統能看懂的樣子的結果。開發者寫 API 規格的時候，也是從這一步開始的。

Action 2. 用 AI 和驗證網站檢查一下語法

把 Action 1 寫好的 JSON 貼進 ChatGPT、Claude、Gemini 之類的 AI 裡，用類似下面這段話請它幫忙檢查：

請幫我檢查下面的 JSON 在語法上是否正確。
看看有沒有拼字錯誤、引號、逗號、大括號或方括號是否對得上，
並用非開發者也能看懂的話，告訴我要怎麼修。

[把 Action 1 的 JSON 貼在這裡]

如果還想再用眼睛覆核一遍，把同一段 JSON 貼到 JSONLint 這種公開驗證網站裡就可以。看到綠色的 "Valid JSON"，語法這一關就算過了。哪怕只是反覆做這兩步，對 JSON 的眼力都會長得很快。

Action 3. 在自己的端點上故意把格式弄壞

上一篇 API 篇的快速入門裡，應該有不少朋友已經在 3Min API 裡做出了第一個端點。今天就請回到那個端點的詳細頁面，對著同一個端點做兩個小實驗：

改一下欄位結構 — 加一個必填欄位，或者把某個欄位改個名字，然後用新的 JSON 形狀再呼叫一次，看看能不能正常存下。
故意送一個壞掉的 JSON 過去 — 漏一個逗號，把必填欄位留空，或者把本該是數字的地方塞進文字，再呼叫一次。關鍵是要親眼看到 API 窗口是用什麼樣的錯誤回過來的。

這些回傳的錯誤訊息是什麼意思、該怎麼處理，都整理在疑難排解指南裡了。從「一看到錯誤就慌」變成「看著錯誤碼去縮小原因範圍」的那一刻，您就已經學會了跟系統對話的語言。

👉 還沒有端點？— 3 分鐘快速入門

三部曲落幕 — 接下來您想走向哪裡

讀到這裡，您手上已經握著三樣工具：裝業務資料的器、讓外部安全進出的通道、以及在通道裡來往的訊息的形狀。當然這三個主題裡，還有更深的細節可以繼續挖。但僅憑今天這個程度的理解，已經足以撐起一副骨架——讓您的生意能走到更大的 IT 生態裡去，甚至為 AI 時代做好準備。剩下的細節，等到需要的時候再往骨架上疊就行。

讀到這裡您可能會想：「這不是開發者的活兒嗎？」其實這幾年，因為 AI 的緣故，開發者和非開發者之間的邊界已經比以前模糊得多。我勸的不是您自己去寫程式，而是請您把IT 運轉的核心原理當作一種直覺收在手邊。在這種直覺之上，再借助各種好工具的力量，就會開始一個循環：做一個小端點，呼叫它一下，撞上錯誤，再改一改。這個循環一旦累積起來，「我生意裡這一塊其實也能自動化」這種念頭就會自然浮出來。這種感覺，正是把生意推向更大市場的起點。

等骨架一立，還會遇到一件挺有趣的事。您最近聽得最多的那些自動化工具，比如 n8n、Zapier、Make，打開看一眼就能發現：它們都跑在同一套API + JSON + DB骨架上。「往 Google 試算表裡加一列」不過是在呼叫 Google 提供的 Sheets API；「用 Gmail 寄信」是在呼叫 Gmail API；「往 Drive 上傳檔案」是在呼叫 Drive API。這些工具說到底，只是把大量已經公開的 API 用 JSON 串起來的仲介者。理解了這副骨架之後，同樣的工具您可以用得比以前更主動。

那當下該做什麼？我的建議是：既然已經大致看清了整條流程，就先小小地落地、跑一跑、撞一撞牆。等到規模大起來、需要變得明確，再來考慮自建系統也不遲。老實說，現在是過去從未有過的適合小步起步的時代。雲端服務、公開 API、LLM、無程式碼工具，都在為這第一步托底。

如果想對 AI 和生意之間的關係看得更寬一點，中小企業的 AI 準備——資料、API，以及現在該做的事可以作為接下來的延伸閱讀。

器、通道、訊息。在這三個約定之上，您的生意哪怕離開您的雙手，也會繼續自己走下去。感謝您一路讀完這套三部曲。

← 上一篇：什麼是 API？寫給非開發者店主的入門指南

guide api-economy basics-series