D3.js 的價值不只在圖表：用資料綁定組出可互動視覺化

D3.js 的價值不只在圖表：用資料綁定組出可互動視覺化

很多前端專案第一次接觸 D3.js，是因為需要一張長條圖、折線圖或地圖。但如果把 D3.js 只理解成「圖表套件」，很容易在第一個需求變複雜時失望：它不會替你選好圖表模板，也不會自動接管資料格式、版面配置與互動狀態。

D3.js 真正提供的是一組把資料轉成 Web 圖形的底層工具。官方 README 將它描述為建立在 Web 標準上的低階 JavaScript 視覺化函式庫，能使用 SVG、Canvas 與 HTML。這個定位解釋了它為什麼學習曲線不低，也解釋了它為什麼能支撐高階圖表函式庫與高度客製化的資料產品。

先看查證結果：它是活躍的實作型基礎工具

本次以 GitHub 搜尋條件 stars:>5000 pushed:>=2026-03-17 掃描候選，d3/d3 在執行時有 113,722 顆星，最近一次推送時間為 2026-05-28，符合星數與 180 天內更新條件。它不是教學清單或資源彙整，而是可安裝、可匯入的 JavaScript 函式庫。

查閱官方 repository 後，幾個事實值得分開理解：

• package.json 目前版本為 7.9.0，入口是 ESM 的 src/index.js。
• 主套件由 d3-array、d3-scale、d3-selection、d3-shape、d3-geo、d3-force 等模組組成。
• 最新 release v7.9.0 發布於 2024-03-12；近期 repository 更新則是文件修正。因此「最近有更新」不等於「近期一定有大版本發布」，選型時應分別看 commit、release 與實際依賴版本。
• 官方提供文件、範例與社群入口，真正的 API 細節應以 d3js.org 及 repository 內容為準。

這些資料也提醒我們：D3 的核心價值在成熟的模組生態與 Web 平台整合能力，不在追逐版本號。

D3 的核心心智模型：資料不是圖表設定，而是 DOM 的輸入

高階圖表套件通常讓你填入 series、xAxis 或 tooltip 設定；D3 則更接近一個資料到畫面的轉換管線：

1. 先整理資料，決定每筆資料代表什麼。
2. 用 scale 將資料空間映射到像素空間。
3. 用 shape、axis 或 geo 模組產生 SVG path、座標軸與標記。
4. 用 selection 把資料和 DOM 元素建立關係。
5. 在資料改變時，透過 enter、update、exit 或現代的 join 方式更新畫面。
6. 再把事件、transition 與互動狀態接上去。

其中最重要的不是某個 API 名稱，而是「資料驅動畫面結構」。當資料筆數增加時，程式可以建立更多元素；當資料被移除時，對應元素可以被清理；當數值改變時，既有元素可以平滑地移動到新位置。

模組化設計讓你可以只拿需要的部分

d3/d3 是一個方便使用的主套件，但它本身是許多獨立 d3-* 模組的組合。這種結構有三個實務好處。

第一，學習與除錯可以切層。資料統計問題先看 d3-array，比例尺問題看 d3-scale，路徑生成問題看 d3-shape，而不是在一個巨大的圖表元件裡猜哪個設定互相影響。

第二，應用程式可以選擇性匯入。若只需要比例尺與色彩，不一定要把整個 API 面都帶進程式；使用 bundler 時，明確匯入也有助於控制產物。

第三，高階函式庫可以把 D3 當成引擎，而不是競爭對象。它們可以負責 React 元件生命週期、預設主題與常見互動，再把 D3 的 scale、shape 或 geo 能力放在底層。

一個最小但完整的 SVG 範例

下面的例子不依賴圖表元件，直接把數值資料映射成長條圖。它刻意保留幾個重要步驟：資料、scale、selection 與 axis。

<!doctype html>
<meta charset="utf-8">
<script type="module">
  import * as d3 from "https://cdn.jsdelivr.net/npm/d3@7/+esm";

  const data = [
    { name: "A", value: 42 },
    { name: "B", value: 76 },
    { name: "C", value: 58 }
  ];

  const width = 520;
  const height = 300;
  const margin = { top: 24, right: 20, bottom: 36, left: 44 };

  const svg = d3.select("body").append("svg")
    .attr("viewBox", `0 0 ${width} ${height}`)
    .attr("role", "img")
    .attr("aria-label", "三個類別的數值長條圖");

  const x = d3.scaleBand()
    .domain(data.map(d => d.name))
    .range([margin.left, width - margin.right])
    .padding(0.2);

  const y = d3.scaleLinear()
    .domain([0, d3.max(data, d => d.value)])
    .nice()
    .range([height - margin.bottom, margin.top]);

  svg.append("g")
    .attr("fill", "#4f8cff")
    .selectAll("rect")
    .data(data)
    .join("rect")
    .attr("x", d => x(d.name))
    .attr("y", d => y(d.value))
    .attr("width", x.bandwidth())
    .attr("height", d => y(0) - y(d.value));

  svg.append("g")
    .attr("transform", `translate(0,${height - margin.bottom})`)
    .call(d3.axisBottom(x));

  svg.append("g")
    .attr("transform", `translate(${margin.left},0)`)
    .call(d3.axisLeft(y));
</script>

這段程式沒有呼叫「建立長條圖」的單一函式。scaleBand 負責類別位置，scaleLinear 負責數值到像素的映射，selection.data(...).join(...) 負責把資料對應到 rect，axis 模組則把比例尺轉成可讀的刻度。每個視覺元素的產生規則都在程式中可見。

互動的關鍵：更新資料，而不是重畫整個頁面

當資料會隨時間、篩選器或使用者操作改變，D3 的優勢會更明顯。可以把新資料重新交給 selection，然後只更新需要變化的屬性：

function update(data) {
  const bars = svg.selectAll("rect")
    .data(data, d => d.name)
    .join(
      enter => enter.append("rect").attr("fill", "#4f8cff"),
      update => update,
      exit => exit.transition().style("opacity", 0).remove()
    );

  bars.transition()
    .attr("x", d => x(d.name))
    .attr("y", d => y(d.value))
    .attr("height", d => y(0) - y(d.value));
}

真正的產品程式還需要同步更新 scale domain、座標軸、標籤與提示框，但責任邊界很清楚：資料更新觸發視覺狀態更新，而不是把所有 HTML 粗暴地重建一次。這種模型很適合時間序列、地理探索、網絡圖與需要連續動畫的分析介面。

D3 不會替你解決的事

D3 的自由度也是成本，導入前要把以下責任算進工程設計。

版面與響應式

你需要自己處理 viewBox、容器尺寸、文字碰撞、窄螢幕策略與 resize。固定畫布能很快做出 demo，但不代表它能直接進入產品。

可及性

SVG 元素不是自動可及的。應補上適當的 role、aria-label、文字替代、鍵盤操作與足夠的色彩對比；互動圖表還要考慮螢幕閱讀器如何理解目前選取狀態。

框架生命週期

在 React、Vue 或 Svelte 中，D3 適合負責計算與繪圖，但不應無意間和框架同時管理同一批 DOM。常見做法是讓框架管理容器與資料流，再讓 D3 在明確的 ref 或 mount 範圍內管理 SVG 內部。

效能

大量節點不一定適合 SVG。當元素數量很大、互動以像素為主，應評估 Canvas 或 WebGL；D3 仍可負責 scale、資料處理與事件座標轉換，但渲染層可以換掉。

什麼時候選 D3，什麼時候不要選？

適合使用 D3 的情境包括：

• 視覺語法不是標準長條圖、折線圖或圓餅圖，而是需要自訂布局。
• 互動方式是產品核心，例如刷選、縮放、拖曳、時間動畫或地理投影。
• 團隊願意維護資料轉換、DOM 更新、可及性與測試。
• 需要把 D3 的底層模組嵌入另一個前端元件或繪圖引擎。

不適合直接從 D3 開始的情境包括：

• 只需要幾張固定樣式圖表，且交付時間比客製化更重要。
• 團隊沒有前端 SVG／Canvas 基礎，也沒有維護視覺化基礎元件的計畫。
• 需要完整的表格替代、匯出、主題與互動規範，卻不想自行建立這些產品能力。

這時可以先採用較高階的 charting library，再視需求局部使用 D3 模組。D3 的價值不在於所有畫面都親手刻，而在於當預設抽象層不夠用時，提供一個可拆解、可組合的底層。

導入建議：先固定資料契約，再決定繪圖方式

實作 D3 專案時，我會建議依序做四件事：

1. 先定義圖表輸入資料的 schema，包含缺失值、時間格式、單位與排序規則。
2. 把資料清理與視覺映射分開，避免 scale 裡混入商業邏輯。
3. 用一個靜態 SVG 版本確認座標、標籤與可及性，再加入 transition 和事件。
4. 為 update(data) 寫測試或至少保留幾組固定 fixture，涵蓋空資料、單筆資料、極端值與重複 key。

這樣做的好處是，即使未來把 SVG 換成 Canvas，資料契約與 scale 測試仍然可以保留。

結語：把 D3 當成視覺化的組合語言

D3.js 的學習成本，來自它拒絕把複雜問題藏在一個圖表設定物件後面；它要求開發者理解資料如何進入 DOM、數值如何映射成幾何、互動如何改變狀態。換來的則是極高的控制力，以及能和 Web 標準、前端框架與其他渲染技術組合的彈性。

如果你的需求只是快速交付一張標準圖表，選高階函式庫通常更合理；如果你正在打造需要探索、解釋與互動的資料介面，D3 值得被視為一套視覺化組合語言，而不只是另一個圖表套件。

查證來源

• d3/d3 repository
• D3 官方文件
• D3 v7.9.0 release
• d3/d3 最新文件修正 commit