🖥️瓶頸彙整「資料庫有、畫面卻空白」怎麼排查？用工程師視角拆解：後端沒回傳欄位 vs 前端沒綁定

- 12月 20, 2025

你有沒有遇過這種超崩潰的狀況：

資料庫查得到資料
但 系統頁面上某一欄完全沒有顯示
更怪的是，其他欄位都正常，就只有某個欄位（例如「瓶頸彙整」）永遠空白

這篇文章用「完全不懂程式的人也聽得懂」的方式，把工程師會怎麼查這類問題講清楚。你不需要會寫程式，只要照著流程走，就能知道問題通常卡在哪一層。

一、先建立「資料從哪裡到哪裡」的概念

一個網頁表格能顯示資料，通常要走過這四段：

資料庫（DB）：真正放資料的地方
後端（API）：負責把資料庫資料「整理成一包」回傳給前端
前端（UI）：收到資料後，照欄位名稱放進表格
瀏覽器畫面：你看到的結果

所以「DB 有資料但 UI 沒顯示」，問題通常只會落在兩大類：

A 類：後端根本沒把那個欄位回傳給前端
B 類：後端有回傳，但前端沒有把它顯示出來（欄位名稱對不上、沒綁定、被過濾掉）

二、最常見的真兇：後端沒把欄位塞進回傳資料

很多企業系統的後端做法是這樣：

後端先從資料庫撈出一堆欄位
再「挑選」其中一些欄位，組成一個要回傳給前端的資料結構（你可以把它想成「回傳專用格式」）

如果後端工程師在組資料時漏掉某個欄位，就會變成：

資料庫有內容 ✅
但 API 回傳根本沒有那個欄位 ❌
前端當然顯示不出來（因為拿不到）

這也是最容易發生、最常被忽略的原因。

三、前端也可能有問題：欄位名稱不一致

即使後端回傳了欄位，前端仍可能顯示不出來，原因常見是：

後端叫 BOTTLE_NECK_SUMMARY
前端表格在找 BOTTLENECK_SUMMARY
或前端把欄位做了大小寫轉換、底線轉換，結果對不上

這種情況下：

API 回傳明明有欄位 ✅
但前端取值時 key 不一致 ❌
表格就會出現「整欄空白」

四、工程師會怎麼查？照這個順序最快

Step 1：先確認 DB 真的有資料（你已經做到了）

用資料庫工具查表，看到「瓶頸彙整」那欄有字，代表 DB 正常。

Step 2：看 API 回傳內容（最關鍵）

用瀏覽器的開發者工具（F12）：

打開 Network（網路）
重新按「查詢」
點開那支 API 回傳
看 Response（回傳內容）

你要找的只有一件事：

回傳 JSON 裡 到底有沒有「瓶頸彙整」那個欄位

如果沒有： 99% 是後端漏塞欄位
如果有： 才去查前端欄位名稱/綁定/過濾

Step 3：如果 API 有欄位但 UI 沒顯示

那就看前端表格的「欄位設定」是否包含這個欄位名稱，是否有轉換大小寫、底線、或欄位 mapping。

五、修正方向

5-1 後端：確保「回傳模型」一定包含瓶頸彙整欄位

(1) 回傳 DTO 必須存在該欄位

重點：API 回傳 JSON 的欄位，是由 DTO 決定的。DB 有值但畫面空，常見就是 DTO 沒這欄。


public sealed class PlanningResultDto
{
    public string SequenceNo { get; init; } = "";
    public string DealQuantity { get; init; } = "";

    // ✅ 你要顯示在 UI 的「瓶頸彙整」
    public string BottleneckSummary { get; init; } = "";

    // 其他欄位...
    public string ConstraintReason { get; init; } = "";
}

(2) 查詢結果（Entity/Raw Row）要能取到該欄位

重點：你在 ORM / SQL 查詢取回的物件，必須真的有這個欄位資料。


public sealed class PlanningResultRow
{
    public string SeqNo { get; set; } = "";
    public decimal? DealQty { get; set; }

    // ✅ DB 欄位（示意），要能讀到
    public string? BottleneckSummary { get; set; }

    public string? ConstraintReason { get; set; }
}

(3) Mapping 必須把值塞進 DTO

重點：即便查到了，如果 mapping 忘了塞，一樣等於沒回傳。


public static class PlanningResultMapper
{
    public static PlanningResultDto ToDto(PlanningResultRow row, IFormatProvider fmt)
        => new PlanningResultDto
        {
            SequenceNo = row.SeqNo,
            DealQuantity = (row.DealQty ?? 0m).ToString("N0", fmt),

            // ✅ 關鍵：把 DB 值帶到 API 回傳
            BottleneckSummary = row.BottleneckSummary ?? "",

            ConstraintReason = row.ConstraintReason ?? ""
        };
}

(4) API 層：避免「欄位被序列化規則改名」造成前端對不上

有些專案會設定 JSON 命名規則（例如 C# BottleneckSummary → JSON bottleneckSummary），你要確保前端吃的是同一套規則。


// 例：ASP.NET Core 設定全站 camelCase（示意）
services.AddControllers()
    .AddJsonOptions(o =>
    {
        o.JsonSerializerOptions.PropertyNamingPolicy = JsonNamingPolicy.CamelCase;
    });

工程師檢查點：

你前端到底在找 BottleneckSummary、bottleneckSummary 還是 BOTTLENECK_SUMMARY？
後端序列化規則會不會把 key 改掉？

5-2 前端：欄位 key 必須與 API 回傳一致（包含大小寫 / 底線 / 駝峰）

(1) 用「集中管理」的欄位定義，避免散落在 template 裡


type ColumnDef = { key: string; title: string };

export const columns: ColumnDef[] = [
  { key: "sequenceNo", title: "SEQ_NO" },
  { key: "dealQuantity", title: "成交數量" },
  { key: "bottleneckSummary", title: "瓶頸彙整" }, // ✅ 要跟 API JSON 一致
  { key: "constraintReason", title: "成交瓶頸" },
];

(2) 若你專案有做「轉大寫 / 正規化 key」，就要保證 mapping 完整

很多系統會把後端回傳 key 做 normalize（例如全轉大寫），那就要保證「瓶頸彙整」那個 key 也被包含、且對應到正確的欄位。


function normalizeKey(k) {
  return String(k).trim().toUpperCase();
}

function normalizeRow(row) {
  const out = {};
  for (const [k, v] of Object.entries(row)) {
    out[normalizeKey(k)] = v;
  }
  return out;
}

// ✅ 你的欄位定義也要一致採同一規則
const headers = [
  { key: "SEQUENCENO", title: "SEQ_NO" },
  { key: "DEALQUANTITY", title: "成交數量" },
  { key: "BOTTLENECKSUMMARY", title: "瓶頸彙整" }, // ✅
];

工程師檢查點：

你到底是「直接用 API 的 key」還是「先 normalize 再用」？
兩者只能選一套，不然一定會出現某些欄位空白。

5-3 最後驗證：用「合約檢查」確保前後端欄位永遠不會漏

(1) 後端：加一個欄位存在性檢查（僅開發/測試環境）


// 示意：在組 DTO 前檢查必要欄位是否為 null（或 row 欄位不存在）
if (row.BottleneckSummary is null)
{
    // 你可以記錄 log，快速知道是 DB 沒值還是 query 沒撈到
}

(2) 前端：載入後立即檢查 Response keys


console.log("response keys:", Object.keys(data?.[0] ?? {}));
if (!("bottleneckSummary" in (data?.[0] ?? {}))) {
  console.warn("API 回傳缺少 bottleneckSummary，請檢查後端 DTO/Mapping/序列化命名");
}

5-4 一句話總結修正方向

後端：DTO 要有欄位 + Mapping 要塞值 + JSON 命名規則要確認
前端：欄位 key 要跟 API 回傳完全一致（含大小寫/底線/駝峰），若有 normalize 就要前後一致
驗證：用 Network/Console 檢查 response 是否真的含該欄位

六、你可以用一句話跟同事/供應商說清楚問題

如果你要快速把問題講清楚（工程師聽得懂、又不會太激進），可以這樣說：

「資料庫表裡瓶頸彙整是有值的，但畫面整欄空白。初步判斷可能是 API 回傳欄位缺漏或前端欄位 key 對不上。建議先檢查 API response 是否包含該欄位，再比對前端表格欄位 mapping。」

七、常見加速排查的小技巧

先查 API，再查前端：因為「API 沒回傳」比「前端沒顯示」更常見
用比對法：拿「正常顯示的欄位」跟「空白欄位」比，看 API 是否都有回傳
避免猜：不要只看 DB，很多人卡在 DB 查到就以為沒問題，實際上問題在 API 層

結語

「資料庫有、畫面沒有」這種 bug，幾乎都是前後端資料交接處出問題。
只要照著本文的流程：

DB
API response （最重要）
前端欄位 mapping

基本上就能快速定位是哪一層漏了。

搜尋此網誌

小小大大學