簡介JimuReport 積木報表 v1.6.6 是一款開源可視化報表設(shè)計工具面向需要快速搭建數(shù)據(jù)展示模塊的開發(fā)者、業(yè)務(wù)人員以及計算機相關(guān)專業(yè)學生。支持拖拽式設(shè)計可減少手寫代碼成本適合集成在 ERP、CRM、BI 或畢業(yè)設(shè)計等報表系統(tǒng)中。資源共 26 個文件壓縮包大小約 2.86MB核心內(nèi)容包括 Java 源碼、多種數(shù)據(jù)庫建表 SQLMySQL、Oracle、SQL Server、YAML 配置、Markdown 文檔、Dockerfile 及說明頁面便于直接部署、二次開發(fā)或?qū)W習報表引擎實現(xiàn)原理。該版本附帶的說明文檔可輔助快速上手已有 935 人學習下載。通過這份資源使用者既能獲得可運行的報表工具源碼也能參考多環(huán)境配置與數(shù)據(jù)庫腳本理解從數(shù)據(jù)采集到可視化呈現(xiàn)的完整鏈路適合做課設(shè)/畢設(shè)分析案例或企業(yè)報表模塊的起點。1. JimuReport 積木報表 v1.6.6.zip這個老版本包為什么今天還值得盤拿到 JimuReport 積木報表 v1.6.6.zip 這個包很多人第一反應(yīng)是解壓、扔進 Tomcat、在網(wǎng)頁里拖個圖表就算完事。但 v1.6.6 的價值不在那幾個可視化組件而在它把報表制作拆成了真正可復(fù)用的積木數(shù)據(jù)集、參數(shù)、圖表、布局各管一段業(yè)務(wù)人員能直接上手改樣式開發(fā)只需要守住數(shù)據(jù)源和權(quán)限。我會按落地這類開源報表工具的順序講包里裝了什么、怎么把服務(wù)跑起來、怎么做出第一張帶參數(shù)的報表、哪些位置最容易翻車。2. 看懂 v1.6.6 的報表引擎積木式設(shè)計靠哪幾個模塊撐起來很多剛從傳統(tǒng)報表工具轉(zhuǎn)過來的人會把積木報表理解成一個“在線 Excel”。其實 v1.6.6 是把報表拆成四層存儲層、數(shù)據(jù)集層、參數(shù)層、布局渲染層。你在設(shè)計器里拖出來的每一個圖表、每一個輸入框最終都會落到一張 JSON 定義里后端再拿著這張定義去反查數(shù)據(jù)源執(zhí)行 SQL算好行列輸出成 HTML、PDF 或 Excel。先把這個鏈路看明白后面調(diào)參數(shù)才不是瞎試。2.1 報表定義、數(shù)據(jù)源與系統(tǒng)表是怎么串起來的v1.6.x 這一代常見設(shè)計里報表服務(wù)自己有一套系統(tǒng)庫用來存報表定義、數(shù)據(jù)源配置、參數(shù)模板和訪問日志。我在生產(chǎn)環(huán)境里至少會看到這幾類表報表主表一條報表一行核心字段里放著設(shè)計器整份 JSON、數(shù)據(jù)源表記錄 JDBC URL、賬號、數(shù)據(jù)庫類型還有保存字典和權(quán)限相關(guān)的輔助表。系統(tǒng)庫和業(yè)務(wù)庫必須分開報表庫里只放“怎么做這張報表”的元數(shù)據(jù)業(yè)務(wù)數(shù)據(jù)永遠留在業(yè)務(wù)庫里。老式報表工具有個通病改一個字段往往要進到設(shè)計器里找那一個單元格牽一發(fā)動全身。積木報表把圖表、表格、圖片、參數(shù)框都做成獨立控件報表之間的數(shù)據(jù)源可以引用同一份配置數(shù)據(jù)集可以被多個圖表復(fù)用。這個“引用”設(shè)計就是積木二字的來源。v1.6.6 里數(shù)據(jù)源和數(shù)據(jù)集雖然也能復(fù)制但要清楚復(fù)制出來的是同一份數(shù)據(jù)源 ID 還是獨立連接串處理不好會多出好幾個占著連接的孤兒數(shù)據(jù)源這一條避坑章節(jié)會繼續(xù)講。數(shù)據(jù)源配置是連接系統(tǒng)庫和業(yè)務(wù)庫的橋梁。積木報表支持 SQL 數(shù)據(jù)源、API 數(shù)據(jù)源和 Java Bean 數(shù)據(jù)源。v1.6.6 用得最多的是 SQL 數(shù)據(jù)源因為它對團隊技術(shù)棧最沒要求DBA 寫好查詢報表開發(fā)直接引用。API 數(shù)據(jù)源適合業(yè)務(wù)數(shù)據(jù)已經(jīng)封裝成服務(wù)、不允許報表直連數(shù)據(jù)庫的公司Java Bean 數(shù)據(jù)源則是我個人最建議慎用的因為它把 Java 代碼和報表定義綁在一起升級報表版本時 Bean 類找不到是常有的事。選型上有兩條血淚經(jīng)驗。第一不要為了省事把系統(tǒng)庫也建在業(yè)務(wù)庫里否則報表跑批的時候一條慢 SQL 就能拖垮核心交易。第二數(shù)據(jù)源賬號給最小查詢權(quán)限只授 SELECT別圖省事給全部權(quán)限后面接數(shù)據(jù)權(quán)限攔截時你會感謝當年這個決定。2.2 從設(shè)計器到渲染一次報表請求的完整路徑我習慣把一張積木報表的渲染過程切成五步方便定位問題。第一步前端請求報表地址帶上報表 ID 和參數(shù)。第二步后端從報表主表讀出那張 JSON 定義校驗 token 和訪問權(quán)限。第三步按照 JSON 里的數(shù)據(jù)集配置去連接數(shù)據(jù)源執(zhí)行 SQL。第四步把查詢結(jié)果映射到布局里的每個單元格和圖表序列處理匯總、分組、分頁。第五步按輸出類型渲染HTML 走模板PDF/Excel 走導(dǎo)出組件。其中第三步最值得盯。v1.6.6 的 SQL 數(shù)據(jù)集執(zhí)行時并不是直接把整條 SQL 丟給數(shù)據(jù)庫而是先做參數(shù)替換再做一次安全校驗。這個替換是最容易出幺蛾子的地方參數(shù)沒傳、傳了字符串帶單引號、傳了百分號都會讓查詢結(jié)果和你在數(shù)據(jù)庫客戶端里跑出來的完全不一樣。下面是一份簡化后的報表 JSON 示意幫助你理解報表定義的基本結(jié)構(gòu){ reportName: 銷售日報, dataSet: { type: sql, sql: select order_date, sum(amount) as amt from t_order where order_date ${startTime} group by order_date }, chart: { type: bar, xField: order_date, yField: amt } }真正的 v1.6.6 配置層級比這個深得多組件還有坐標、顏色、聯(lián)動事件等字段。但你只要理解報表定義就是“數(shù)據(jù)源 SQL 布局 圖表”的容器排錯時先在 JSON 里找數(shù)據(jù)集 SQL再往前端找參數(shù)順序不要搞反。渲染只是前半場輸出才是坑的高發(fā)區(qū)。HTML 視圖走分頁服務(wù)端只算當前頁PDF 導(dǎo)出要把整張表算完后排版內(nèi)存占用隨行數(shù)線性上漲Excel 導(dǎo)出則分 xls 和 xlsx 兩種xls 有 65536 行上限v1.6.6 時代很多人導(dǎo)出 7 萬行數(shù)據(jù)后文件打不開就是撞了這個限制。超過 5 萬行的數(shù)據(jù)優(yōu)先考慮 xlsx 或做匯總報表別硬導(dǎo)明細。3. 把 v1.6.6 跑起來解壓部署、環(huán)境要求與啟動驗證zip 包里通常是一個可直接部署的 Web 工程v1.6.6 這代最常見的載體是 war 包加前端靜態(tài)資源。不要急著雙擊先把環(huán)境對齊否則后面報表設(shè)計器白屏、接口 404你都不知道是包的問題還是配置的問題。3.1 部署前先檢查這三樣環(huán)境我一般按三張表來核對運行環(huán)境、數(shù)據(jù)庫、網(wǎng)絡(luò)與端口。檢查項我建議的配置說明JDK1.8 及以上v1.6.6 基于 Java 8 生態(tài)不建議上 JDK 17 跑老包Web 容器Tomcat 8.5 / 9.0war 包部署最常見的方式數(shù)據(jù)庫MySQL 5.7 / 8.0系統(tǒng)庫優(yōu)先用 MySQL生產(chǎn)不建議用內(nèi)置庫字符集utf8mb4報表中文、涉及 emoji 時避免亂碼時區(qū)Asia/ShanghaiJDBC 連接串里顯式指定數(shù)據(jù)庫這步最容易漏。v1.6.x 的安裝包通常會帶建表腳本或首次啟動自動建表但自動建表依賴連接串能正常通。我習慣手動先建好庫再給報表賬號最小權(quán)限最后把連接串的時區(qū)和字符集參數(shù)寫全。給一份 JDBC 配置示例寫在 application.yml 里spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://192.168.10.20:3306/jmreport?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: jmreport_user password: 你的密碼url 里帶 serverTimezone是因為老版本 MySQL 驅(qū)動在 8.0 連接串下不指定時區(qū)會報 CST 相關(guān)錯誤characterEncoding 用 utf8mb4 而不是 utf8避免中文被截斷。driver-class-name 用 com.mysql.cj.jdbc.Driver這是 MySQL 8 驅(qū)動如果迫于歷史原因用 5.x 驅(qū)動要改成 com.mysql.jdbc.Driver同時去掉 url 里的 cj 段否則報錯方向會把人帶偏。注意v1.6.6 包里一般自帶一個內(nèi)嵌數(shù)據(jù)庫方便本機 demo但正式環(huán)境務(wù)必改用外部 MySQL。容器一旦被回收報表定義全部蒸發(fā)這不是開玩笑。3.2 解壓上傳并啟動一條命令一次確認第一步把 zip 上傳到服務(wù)器解壓到應(yīng)用目錄例如 /opt/jmreport。# 解壓到應(yīng)用目錄 mkdir -p /opt/jmreport unzip JimuReport-v1.6.6.zip -d /opt/jmreport/ # 先看解壓結(jié)果確認 war 包名和前端靜態(tài)目錄 ls -lh /opt/jmreport/先 ls 確認 war 包名和前端靜態(tài)目錄。后面訪問路徑里的上下文名以 war 包名為準如果想改成根路徑訪問把 war 包改成 ROOT.war訪問 http://IP:8080/ 即可。這是很多同事翻車的地方以為部署完訪問 /jmreport結(jié)果 404 半天其實是上下文名不一致。第二步把 war 包丟進 Tomcat。# 復(fù)制 war 包到 webapps cp /opt/jmreport/jimu.war $TOMCAT_HOME/webapps/ # 啟動 Tomcat $TOMCAT_HOME/bin/startup.sh # 實時盯啟動日志 tail -f $TOMCAT_HOME/logs/catalina.out啟動日志里看到類似“Server startup in”字樣才算起完不要看到“Started Spring”就急著訪問war 包模式下 Spring 啟動和 Tomcat 注冊是兩個時間點。首次啟動因為有初始化任務(wù)會比平時慢 30 秒左右屬正?，F(xiàn)象。第三步用 curl 確認服務(wù)真正可訪問# 探測報表首頁 HTTP 狀態(tài)碼 curl -s -o /dev/null -w %{http_code}\n http://127.0.0.1:8080/jmreport/ # 探測前端入口頁面 curl -s -o /dev/null -w %{http_code}\n http://127.0.0.1:8080/jmreport/index.html返回 200 是基礎(chǔ)如果返回 302看跳轉(zhuǎn)地址是不是登錄頁是則說明管理端開了登錄校驗如果返回 404先核對 war 包解出的上下文名和訪問路徑。我還會順手再打一次數(shù)據(jù)庫連接確認系統(tǒng)庫表已經(jīng)生成-- 確認報表主表已自動創(chuàng)建 select count(*) from jimu_report;如果這張表不存在說明自動建表沒跑成功回到 datasource 配置檢查賬號權(quán)限和 url如果表存在但 count 為 0是正常的你還沒建報表。這一步踩的人很多表沒建起來就急著改報表配置文件純屬浪費時間。4. 用 v1.6.6 做出第一張帶參數(shù)的報表從 SQL 數(shù)據(jù)集到圖表發(fā)布部署只是熱身真正上手是從“數(shù)據(jù)源→數(shù)據(jù)集→圖表→參數(shù)→發(fā)布”這條路走一遍。這一章按最小可用的方式做一張帶時間條件的銷售匯總柱狀圖再把它嵌到一個已有系統(tǒng)頁面里。4.1 建數(shù)據(jù)源并寫第一條可用的 SQL 數(shù)據(jù)集數(shù)據(jù)源在“數(shù)據(jù)源管理”里新增選 MySQL把 3.1 里那套 JDBC 連接串填進去。我通常會多做一次連接驗證點“測試連接”能通只能說明驅(qū)動和網(wǎng)絡(luò)沒問題并不代表報表執(zhí)行 SQL 沒問題。真正的工作量在寫數(shù)據(jù)集 SQL。在數(shù)據(jù)集配置頁選擇 SQL 數(shù)據(jù)源寫下面這條 SQL-- 按日匯總銷售金額時間范圍由報表參數(shù)控制 select order_date, sum(amount) as total_amt from t_order where order_date ${startTime} and order_date ${endTime} group by order_date order by order_date這里的 ${startTime}、${endTime} 不是數(shù)據(jù)庫變量是積木報表的參數(shù)占位。報表頁面渲染時前端傳兩個日期過來后端替換后再執(zhí)行。參數(shù)類型記得在參數(shù)配置里選“日期”如果不選默認按字符串處理在 MySQL 里比較日期雖然大部分情況也能出結(jié)果但遇到索引列就很容易放棄索引表一大數(shù)據(jù)就開始慢。參數(shù)還要配默認值這一點影響很大。我給開始時間配默認值“今天往前推 7 天”結(jié)束時間配“今天”。這樣業(yè)務(wù)方打開報表什么都不選也能看到最近一周數(shù)據(jù)而不是先面對一張空表。默認值在參數(shù)配置里通常可選“函數(shù)”類型或直接填日期表達式具體以你解壓出來的版本界面為準。4.2 圖表組件、參數(shù)聯(lián)動與保存發(fā)布數(shù)據(jù)集建好后報表設(shè)計器里會多出來一個可用數(shù)據(jù)集。拖一個柱狀圖組件到畫布在圖表數(shù)據(jù)配置里把 X 軸綁定 order_dateY 軸綁定 total_amt圖表的過濾條件直接引用剛才兩個參數(shù)。這里有個關(guān)鍵操作參數(shù)聯(lián)動順序要在“參數(shù)管理”里排好。開始時間和結(jié)束時間誰在上誰在下影響用戶體驗更重要的是結(jié)束時間應(yīng)該做一次最小時段校驗我一般會在數(shù)據(jù)集里再加一個判斷條件避免開始時間晚于結(jié)束時間時查出一堆負值臟數(shù)據(jù)。-- 增加起止時間自校驗防止用戶誤操作 where order_date ${startTime} and order_date ${endTime} and ${startTime} ${endTime}第三條看起來多余但在報表參數(shù)默認值和用戶手輸不一致時它能把錯誤擋在 SQL 層至少不會讓圖表畫出一條時間倒退的折線。如果你的版本在數(shù)據(jù)集層不支持這種自引用比較就放到圖表的高級過濾條件里做思路一樣。保存后報表會拿到一個 ID設(shè)計器會提供“預(yù)覽”和“發(fā)布”兩個入口。預(yù)覽鏈接通常帶 preview 參數(shù)發(fā)布鏈接是干凈的對外地址。我在實際部署里只把發(fā)布鏈接放進業(yè)務(wù)系統(tǒng)預(yù)覽鏈接只留給開發(fā)調(diào)試否則業(yè)務(wù)方看到的是一條隨時可能變化的調(diào)試態(tài)報表。4.3 用 iframe 把報表嵌進業(yè)務(wù)系統(tǒng)對 v1.6.6 來說最常見、最不容易出問題的集成方式是 iframe 嵌入。前端頁面里放一個 iframe把發(fā)布地址拼進 src同時帶上報表 token!-- 報表嵌入占位 -- iframe src/jmreport/view/1079820?token${reportToken} stylewidth:100%;height:720px;border:0; /iframereportToken 由后端接口統(tǒng)一下發(fā)。我的常見做法是在業(yè)務(wù)系統(tǒng)里加一個代理接口業(yè)務(wù)系統(tǒng)用戶登錄后后端拿著內(nèi)部賬號調(diào)一次報表服務(wù)的 token 接口拿到后拼到 iframe 地址里返回給前端。這樣業(yè)務(wù)系統(tǒng)前端不接觸報表賬號密碼報表服務(wù)端也能通過 token 時效控制訪問窗口。token 接口的調(diào)用方式不同版本略有差異v1.6.x 一般在配置里開啟“外部訪問 token 校驗”后通過報文換取 token。第一次對接時可以先用 curl 打通再封裝成服務(wù)# 換取報表訪問 token curl -X POST http://127.0.0.1:8080/jmreport/token \ -H Content-Type: application/json \ -d {clientId:你的客戶端ID,clientSecret:你的密鑰}返回報文里通常會帶一個有效期的 token有效期設(shè)成 10~30 分鐘不要設(shè)成永久。這個 token 放在 iframe 地址里會被瀏覽器歷史留下痕跡永久 token 等于把報表數(shù)據(jù)暴露在瀏覽器記錄里。5. 實戰(zhàn)避坑v1.6.6 最常見的五個翻車現(xiàn)場開源報表工具本身不難難的是生產(chǎn)環(huán)境里那些“看起來沒問題”的隱性故障。下面這五條我都在真實項目里見過你對照排查就行。5.1 報表 SQL 查不出數(shù)據(jù)百分號和單引號的轉(zhuǎn)義陷阱現(xiàn)象數(shù)據(jù)庫客戶端里跑同樣的 SQL 能查到數(shù)據(jù)放到積木報表的數(shù)據(jù)集里就返回空或者某個參數(shù)值里帶“%”時結(jié)果集數(shù)量明顯不對。原因v1.6.6 的 SQL 參數(shù)替換不是簡單的字符串拼接對單引號和百分號做了特殊處理。比如你在 where 里寫 name like %${keyword}%如果前端傳進來的關(guān)鍵字本身含有一個單引號整個語句就在替換時被拆斷了如果關(guān)鍵字里帶了 %like 的匹配范圍會被嚴重擴大看起來就是數(shù)據(jù)異常。解決參數(shù)值盡量避免用 like 拼接。我一般把模糊搜索條件寫在 SQL 里用 instr 來判斷-- 用 instr 避免 like 拼接被參數(shù)替換誤傷 select id, name from t_user where instr(name, ${keyword}) 0instr 對特殊字符的容忍度比 like 拼接高也不容易被參數(shù)替換邏輯誤傷如果業(yè)務(wù)必須用 like高級做法是先在參數(shù)配置里做一次字符轉(zhuǎn)義函數(shù)再用拼接。動手前先看一下當前版本參數(shù)替換規(guī)則的說明文檔不同小版本對轉(zhuǎn)義的處理不完全一致。5.2 保存報表時提示 token 失效或 401現(xiàn)象設(shè)計器打開后放了一會兒再拖動組件或保存彈出一個 401 或“token 過期”頁面刷新后又能正常操作。原因設(shè)計器頁面持有的訪問 token 有時間限制長時間掛在那里不操作token 到期后后續(xù)保存請求被攔截。解決調(diào)大報表服務(wù)端 token 過期時間同時在設(shè)計器前端做一個定時心跳刷新。心跳刷新不是每個團隊都愿意做折中方案是把過期時間設(shè)成和業(yè)務(wù)系統(tǒng)單點登錄會話一致比如 8 小時真正操作時如果遇到 401重新打開設(shè)計器未保存的編排會丟所以我的習慣是每完成一個區(qū)塊就點一次保存。5.3 非 MySQL 數(shù)據(jù)庫下內(nèi)置函數(shù)不兼容現(xiàn)象換到 Oracle、PostgreSQL 或達夢后數(shù)據(jù)集 SQL 里的 date_format、ifnull 報語法錯誤報表預(yù)覽 500。原因v1.6.6 原生 SQL 是圍繞 MySQL 方言打磨的數(shù)據(jù)源類型選錯會更嚴重——你在 Oracle 數(shù)據(jù)源里寫 date_format數(shù)據(jù)庫當然不認識。解決數(shù)據(jù)源配置里把數(shù)據(jù)庫類型準確選成 oracle 或 postgresql數(shù)據(jù)集盡量用原生 SQL 模式日期格式化改寫為 to_char(..., yyyy-mm-dd)空值判斷改寫為 nvl 或 coalesce。如果團隊里報表 SQL 是 DBA 統(tǒng)一維護這一點可以寫進開發(fā)規(guī)范。5.4 升級后舊報表打不開表結(jié)構(gòu)或 JSON 結(jié)構(gòu)不兼容現(xiàn)象從 v1.6.2 升到 v1.6.6老報表列表還在點進去白屏或者報表數(shù)據(jù)源列表為空但庫里明明有配置。原因這類開源報表在版本升級時系統(tǒng)表可能新增字段報表 JSON 里也可能增加組件類型。舊報表沒做結(jié)構(gòu)遷移新前端讀不到對應(yīng)字段渲染就失敗。解決升級前先備份系統(tǒng)庫再按升級說明跑增量腳本升級后不要急著覆蓋生產(chǎn)訪問地址先在測試機把歷史報表全部預(yù)覽一遍尤其是帶自定義圖表和復(fù)雜參數(shù)的。數(shù)據(jù)庫巡檢 SQL 可以這樣查-- 導(dǎo)出全部報表清單按更新時間排查異常 select id, name, update_time from jimu_report order by update_time desc;升級后第一件事就是導(dǎo)出全部報表清單逐一點開樣式最復(fù)雜的幾張確認圖表、數(shù)據(jù)集、參數(shù)都沒有丟。這個動作花不了 20 分鐘但能省掉上線后業(yè)務(wù)部門的一堆工單。5.5 跨域?qū)е略O(shè)計器白屏或接口 404現(xiàn)象報表部署在 8080業(yè)務(wù)系統(tǒng)在 8081通過業(yè)務(wù)系統(tǒng)跳轉(zhuǎn)設(shè)計器頁面框架出來了但圖表數(shù)據(jù)一直加載中F12 看到跨域報錯。原因前端資源在 8081接口在 8080跨域沒配置瀏覽器把接口請求攔了。解決給 Nginx 加一段跨域頭或者讓 Nginx 把 /jmreport 反代到后端location /jmreport/ { proxy_pass http://127.0.0.1:8080/jmreport/; add_header Access-Control-Allow-Origin * always; add_header Access-Control-Allow-Methods GET,POST,PUT,DELETE,OPTIONS; add_header Access-Control-Allow-Headers Content-Type,Authorization,token; }Access-Control-Allow-Origin 用 * 是圖省事正式環(huán)境要換成具體業(yè)務(wù)域否則任何站點都能引用你們的報表頁面。加完配置 reload 后再刷新別忘記瀏覽器緩存可能仍然命中舊響應(yīng)。6. 把 v1.6.6 用出心得的最后一件事做一次可重復(fù)的回歸驗證部署、開發(fā)、避坑都走完后我建議花半天時間做一次可重復(fù)的回歸驗證而不是“看起來能出數(shù)就算完”。我會準備一份固定參數(shù)的測試用例覆蓋基礎(chǔ)表格、帶參數(shù)查詢、日期范圍、百分號關(guān)鍵字、空值兜底、導(dǎo)出 PDF、導(dǎo)出 Excel 七類場景。每類跑完記錄行數(shù)、圖表數(shù)據(jù)和導(dǎo)出文件大小下次升級或調(diào)參同一份用例再跑一遍差異立刻現(xiàn)形。6.1 巡檢腳本兩條 SQL 加一個接口探測巡檢腳本我用兩條 SQL 加一個接口探測# 探測主報表頁是否穩(wěn)定返回 200 curl -s -o /dev/null -w %{http_code} http://127.0.0.1:8080/jmreport/view/1079820 # 探測列表接口是否正常吐 JSON curl -s http://127.0.0.1:8080/jmreport/list | head -c 500-- 統(tǒng)計系統(tǒng)庫報表數(shù)量 select count(*) as report_cnt from jimu_report; -- 找出沒有關(guān)聯(lián)報表的孤兒數(shù)據(jù)源 select d.id, d.name, d.update_time from jimu_report_data_source d left join jimu_report r on r.data_set_id d.id where r.id is null;第一條 curl 確認主報表頁面穩(wěn)定返回 200第二條 curl 看列表接口是否吐 JSON第三、四條 SQL 看系統(tǒng)庫里有沒有孤兒數(shù)據(jù)源和異常記錄。出現(xiàn)孤兒數(shù)據(jù)源時報表列表可能正常但客戶端連接數(shù)被沒用的數(shù)據(jù)源池占著時間一長就拖垮數(shù)據(jù)庫。最后留一句經(jīng)驗v1.6.6 適合中小團隊內(nèi)部運營、數(shù)據(jù)看板這類對實時性要求不高的場景別讓報表服務(wù)直連生產(chǎn)核心庫也別讓報表 SQL 做全表掃描。我每次接手新環(huán)境都先確認這兩條底線。希望幫到你。本文還有配套的精品資源點擊獲取