今日目標
正式進入專案的第二階段（Phase 2）！今天我們不寫 Code，而是要來進行深度的技術選型探討：分析 JasperReports / iText 原生繪圖與 HTML 轉 PDF 的技術差異，了解為什麼現代企業級醫療報表紛紛轉向 Web 技術排版。

核心概念：醫療報表的排版痛點
醫療資訊系統（HIS）的健檢報告往往具備以下特徵：

1. 結構複雜：包含病患基本資料（表頭）、各種檢驗數值（超長跨頁表格）、醫師總評（長篇文字）甚至心電圖或圖表。
2. 長度高度動態：每個病患做的檢查項目數量不同，有些報告只有 2 頁，有些高達 20 頁。
3. 醫療法規與視覺要求：跨頁時必須保留表頭欄位名稱（不然醫生不知道那行數字是血糖還是血脂），特定異常數值必須精準標紅。

面對這樣的需求，後端工程師通常面臨兩種技術選型：「原生 PDF 繪製套件」 vs 「HTML/CSS 渲染轉檔」。

技術選型對決：原生繪圖 vs 網頁轉檔

1. 傳統派：Java 原生繪製套件（以 iText / JasperReports 為例）
   過去十幾年，Java 開發者最常使用的就是這類套件。它們的運作原理是建立一塊虛擬的畫布，然後用程式碼去「畫」出文字跟線條。
   痛點 1：座標計算地獄
   工程師必須精算 X 與 Y 座標。例如 document.addText("姓名：張三", x: 100, y: 750)。一旦業務單位說：「姓名欄位可以往右挪 2 公分嗎？」，你可能要重新計算整頁的座標並重新編譯程式。
   痛點 2：動態表格跨頁極難處理
   當一個表格不知道何時會換頁時，要在每一頁精準切斷並補上表頭，邏輯寫起來極度痛苦。
   痛點 3：字型依賴與授權風險
   伺服器上必須安裝中文字型檔（如標楷體），否則產出直接變亂碼。此外，iText 後期版本採用 AGPL 嚴格開源授權，在商業與企業內部系統中使用有較高的法務風險。

2. 現代派：HTML/CSS 網頁轉檔（Thymeleaf + Gotenberg）
   這也就是我們本次鐵人賽採用的架構。我們將資料綁定到 HTML 上，用 CSS 排版，最後交給瀏覽器核心（Chromium）去「列印」成 PDF。

   優勢 1：降維打擊的排版能力
   前端發展了二三十年的排版技術（Flexbox、CSS Grid），拿來對付報表簡直是降維打擊。不管是置中對齊、響應式佈局還是圓角表格，CSS 幾行程式碼就能搞定。
   優勢 2：所見即所得（WYSIWYG）
   開發時，你只需要打開瀏覽器就能直接預覽報表長相，不用每次改版面都要重啟後端伺服器跑一次 PDF 產生流程。
   優勢 3：完美解決動態長度與跨頁
   瀏覽器天生就知道怎麼處理長內容換頁。我們只要利用 CSS 屬性（例如 display: table-header-group），瀏覽器就會自動在列印換頁時幫你補上表格的表頭！

總結來說，雖然傳統的 Java 原生繪圖套件具備在單一行程內運行的輕量優勢，但其寫死座標的排版方式往往導致開發除錯緩慢且難以處理動態跨頁表格；相比之下，Thymeleaf 結合 Gotenberg 的轉檔方案雖然增加了維護 Docker 微服務的架構成本，卻能徹底釋放現代網頁標準（HTML/CSS）的排版潛力，帶來所見即所得的極速開發體驗與完美無痛的跨頁支援，是現代複雜醫療報表排版的最佳解方。

心得
曾經看過學長姐為了刻一份有動態表格的 PDF，在 Java 裡面寫了上千行的座標運算，最後還因為伺服器少裝了一個中文字型，交件前一晚產出來的報告全是方塊豆腐字，直接崩潰。

這也是為什麼我們在 Day 3 要先用 Docker 把 Gotenberg 準備好的原因。雖然架構上多了一個微服務，但它把「排版邏輯」跟「業務邏輯」完美解耦了。

釐清了這項核心優勢後，明天（Day 7）我們就要正式把 Thymeleaf 樣板引擎引入 Spring Boot，開始撰寫我們的醫療報表 HTML 版型了！