接手過老式j(luò)spservlet項目的人應(yīng)該都有同感一個客戶關(guān)系管理系統(tǒng)看著不復(fù)雜真動起手來卻發(fā)現(xiàn)客戶、商機、跟進、審批、報表、權(quán)限這些模塊盤根錯節(jié)牽一發(fā)動全身。最近我剛好把一套用了好幾年的SSH老系統(tǒng)整體遷移到SpringBoot上順手用ECharts把銷售漏斗和業(yè)績報表重做了一遍技術(shù)棧就是標題里這套java springboot echarts freemarker layui maven mysql。整個過程從工程搭建到核心模塊落地再到打包部署排查踩了不少坑今天完整復(fù)盤一下給準備自研CRM或者接手SpringBoot項目的朋友一個可參考的藍本。整個項目不是簡單套個增刪改查框架而是要把銷售日常真正用起來。下面我按項目的實際推進順序來拆解從業(yè)務(wù)設(shè)計、技術(shù)選型到模塊實現(xiàn)、數(shù)據(jù)庫優(yōu)化再到部署排查每一塊都會講清楚為什么這么選、怎么做以及實踐里容易翻車的位置。1. CRM項目的業(yè)務(wù)拆解與技術(shù)選型邏輯1.1 業(yè)務(wù)需求拆解不要把CRM做成一個客戶列表很多團隊一提CRM第一反應(yīng)就是把客戶信息表格化做幾個頁面能增刪改查再導(dǎo)個Excel就算完事。這種系統(tǒng)上線以后大概率沒人用因為它只解決了“記錄”問題沒有解決“推進”問題。一個能給銷售帶來真實幫助的CRM至少要包含三條業(yè)務(wù)主線客戶資料沉淀客戶基本信息、所屬行業(yè)、客戶分級、來源渠道、下次跟進時間。重點不是字段多而是要讓銷售一打開客戶詳情就能判斷“這個人值不值得繼續(xù)投入精力”。商機階段推進從初步接觸到需求確認、方案報價、商務(wù)談判、贏單/輸單。每個階段要有狀態(tài)字段、預(yù)計成交金額、預(yù)計成交日期這樣銷售管理層才能從數(shù)據(jù)里看出哪些單子有風(fēng)險。跟進過程留痕誰在什么時候通過什么方式電話、拜訪、微信跟進過哪個客戶聊了什么下一步計劃是什么。這部分最容易被忽視但恰恰是后續(xù)復(fù)盤客戶流失原因的關(guān)鍵。除此之外老板關(guān)心的報表也不能省每個銷售的量、成交率、漏斗轉(zhuǎn)化率、月度回款趨勢這些數(shù)據(jù)如果全靠人工匯總Excel系統(tǒng)就失去了意義。我當(dāng)時設(shè)計的時候把業(yè)務(wù)模塊拆成了五張核心主表外加日志、部門、用戶表整體上采用一個“客戶-聯(lián)系人-商機-跟進”的一對多樹形結(jié)構(gòu)。數(shù)據(jù)模型理順之后后面的代碼才是水到渠成的事否則一邊寫代碼一邊改表結(jié)構(gòu)返工成本非常大。1.2 技術(shù)選型SpringBootFreeMarkerLayui這套老牌組合為什么還值得用技術(shù)選型上我仔細考慮過要不要上前后端分離最后放棄VueSpringBoot的組合選回了FreeMarkerLayui。原因很簡單團隊規(guī)模不大沒有專職前端銷售系統(tǒng)又強依賴服務(wù)端渲染的快速迭代能力。SpringBoot負責(zé)整體框架這一點沒有懸念它對Spring生態(tài)的整合幾乎零配置內(nèi)嵌Tomcat讓開發(fā)環(huán)境不用再單獨裝服務(wù)器。選FreeMarker而不是JSP核心是JSP在SpringBoot里支持得比較別扭特別是jar包部署時JSP的編譯和訪問總會出現(xiàn)莫名其妙的404而FreeMarker天然適合模板渲染語法干凈對Java對象直接訪問屬性前端同事配合起來阻力也小。Layui在這個項目里是作為后臺管理UI使用的。它基于jQuery組件成熟表格、表單、彈層、分頁都有現(xiàn)成封裝?，F(xiàn)在前端框架五花八門但企業(yè)后臺系統(tǒng)的場景下Layui這種“不需要node環(huán)境、不折騰構(gòu)建工具”的方案依然很能打一套JS文件引入即可用特別適合服務(wù)端渲染架構(gòu)。ECharts的定位是數(shù)據(jù)可視化。CRM里面最常見的圖表是漏斗圖商機階段轉(zhuǎn)化和折線圖業(yè)績趨勢ECharts對這類場景支持特別完善配置項直觀圖表交互細膩而且是完全本地化的開源項目沒有外網(wǎng)依賴。MySQL負責(zé)所有業(yè)務(wù)數(shù)據(jù)落地Maven負責(zé)依賴管理和構(gòu)建。這套組合最適合的是中小型企業(yè)內(nèi)部管理系統(tǒng)人力有限、上線周期短、不需要過度設(shè)計又能保證代碼結(jié)構(gòu)清晰、后續(xù)可維護。2. 工程初始化與SpringBoot核心配置2.1 Maven工程結(jié)構(gòu)設(shè)計與POM依賴管理項目剛?cè)胧值谝徊绞莿?chuàng)建Maven工程。這里我不建議一上來就搞微服務(wù)多模塊拆分CRM這種體量一個spring-boot-maven-plugin打出的可執(zhí)行jar包就能搞定所有功能多模塊只會增加維護成本。我在pom.xml里核心引入了這么幾個依賴這里直接貼一段簡化版parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent properties java.version1.8/java.version /properties dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-freemarker/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.1/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdcom.alibaba/groupId artifactIddruid-spring-boot-starter/artifactId version1.2.20/version /dependency dependency groupIdcom.github.pagehelper/groupId artifactIdpagehelper-spring-boot-starter/artifactId version1.4.7/version /dependency /dependencies幾個細節(jié)值得注意。第一是SpringBoot版本我特意選了2.7.x而不是3.x因為3.0開始強制JDK17而且很多舊版三方組件兼容性踩坑嚴重很多小團隊生產(chǎn)環(huán)境還在JDK8直接上3.x會異常痛苦。第二是mysql-connector-j這個新坐標老版本的com.mysql.cj.jdbc.Driver驅(qū)動名依然可用如果需要反編譯排查底層驅(qū)動行為新坐標對應(yīng)jar包結(jié)構(gòu)更清晰。第三是PageHelper分頁插件CRM列表頁的搜索分頁是剛需自己手寫limit計算工作量不大但容易疏忽total數(shù)用插件能把精力集中在業(yè)務(wù)SQL上。2.2 application.yml中的關(guān)鍵配置與連接參數(shù)SpringBoot的配置集中在application.yml里我用多環(huán)境配置管理默認開發(fā)環(huán)境、生產(chǎn)環(huán)境通過啟動參數(shù)切換。數(shù)據(jù)庫連接這塊配置直接決定了系統(tǒng)穩(wěn)定性重點看這幾項server: port: 8080 servlet: context-path: /crm spring: datasource: type: com.alibaba.druid.pool.DruidDataSource url: jdbc:mysql://localhost:3306/crm_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver druid: initial-size: 5 min-idle: 5 max-active: 20 max-wait: 60000 time-between-eviction-runs-millis: 60000 validation-query: SELECT 1 freemarker: template-loader-path: classpath:/templates suffix: .ftl cache: false charset: UTF-8 mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.crm.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl這里有幾個我踩過的大坑單獨說。數(shù)據(jù)庫URL里的useSSLfalse一定要加上否則高版本MySQL驅(qū)動默認開啟SSL握手碰到自簽名證書會直接報錯明明賬號密碼對卻連不上庫。serverTimezone務(wù)必指定我一開始漏了啟動報“The server time zone value”的錯加上Asia/Shanghai才消停。allowPublicKeyRetrievaltrue這個參數(shù)很多新項目會碰到特別是用MySQL 8.0以上配合caching_sha2_password認證方式時不加這個參數(shù)驅(qū)動會拒絕通過非SSL通道獲取公鑰啟動能過但第一次查詢連接就閃斷。FreeMarker的cache:false在開發(fā)調(diào)試階段必須關(guān)掉否則每次改模板都要重啟服務(wù)才能看到效果。生產(chǎn)環(huán)境記得改回true否則性能會受很大影響。MyBatis的駝峰映射也要打開數(shù)據(jù)庫字段是create_timeJava屬性是createTime映射規(guī)則打開后就不用寫一堆繁瑣的resultMap了。2.3 FreeMarker模板與Layui靜態(tài)資源的整合方式FreeMarker模板放在src/main/resources/templates下Layui的css、js文件放在src/main/resources/static下SpringBoot默認會把這些資源映射出去。一個容易踩的坑是如果把Layui的layui.js放在templates目錄下頁面訪問會404因為templates目錄默認不對外暴露靜態(tài)資源必須走static。我習(xí)慣把公共布局抽成獨立ftl片段比如header.ftl、sidebar.ftl、footer.ftl再用FreeMarker的include指令引入這樣每個功能頁面只需要關(guān)心自己的主體內(nèi)容#include common/header.ftl div classlayui-container #-- 主體內(nèi)容區(qū)域 -- /div #include common/footer.ftl變量渲染時有個細節(jié)如果后端傳值為nullFreeMarker默認會直接報錯而不是輸出空字符串。我用兩種方式處理一是在模板里給變量加默認值比如${customer.phone!-}二是在application中配置spring.freemarker.settings.classic_compatibletrue兼容空值輸出。不管哪種都不要讓一個null值把整個頁面拖崩。3. 核心業(yè)務(wù)模塊的設(shè)計與實現(xiàn)3.1 登錄認證、用戶權(quán)限與Session管理登錄認證這塊我選的是比較傳統(tǒng)的Session方案SessionId種在Cookie里攔截器統(tǒng)一校驗沒有引入JWT。原因很實際CRM的用戶量不大幾十到幾百人Session方案夠用且實現(xiàn)簡單JWT解決的是無狀態(tài)和跨域問題但會帶來會話失效不好控制、密鑰管理復(fù)雜的問題對內(nèi)部系統(tǒng)反而增加負擔(dān)。密碼存儲一定不能明文我用的方案是MD5加鹽鹽值固定一串隨機字符串注冊時加密入庫登錄時用同樣算法加密比對。MD5現(xiàn)在不是最安全的但對內(nèi)部系統(tǒng)足夠如果安全要求更高可以替換成BCrypt做法類似。攔截器實現(xiàn)思路是定義一個HandlerInterceptorpreHandle方法里檢查當(dāng)前請求的Session是否存在loginUser對象。沒有就跳轉(zhuǎn)到登錄頁。SpringBoot中注冊攔截器要繼承WebMvcConfigurer接口Configuration public class WebConfig implements WebMvcConfigurer { Autowired private LoginInterceptor loginInterceptor; Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(loginInterceptor) .addPathPatterns(/**) .excludePathPatterns(/login, /doLogin, /static/**, /favicon.ico); } }這里最關(guān)鍵的細節(jié)是白名單靜態(tài)資源路徑一定要排除否則頁面壓根加載不了CSS和JS。我在一開始就漏了static放行登錄頁丑得沒法看排查半天才發(fā)現(xiàn)是攔截器把layui文件全給攔住了。Session對象里我建議只放用戶ID、用戶名、部門ID、角色標識這些輕量信息千萬別把整個用戶對象塞進去用戶表字段一多Session會膨脹而且用戶資料更新后舊的Session數(shù)據(jù)不會自動同步容易造成權(quán)限判斷陳舊。3.2 客戶列表、分頁搜索與多條件查詢的實現(xiàn)套路客戶列表是CRM系統(tǒng)信息密度最高的頁面。我實現(xiàn)它時用PageHelper插件完成物理分頁配合動態(tài)SQL處理搜索條件。先看Controller層接口RequestMapping(/customer/list) public String list(RequestParam(defaultValue 1) Integer page, RequestParam(defaultValue 10) Integer limit, CustomerQuery query, Model model) { PageHelper.startPage(page, limit); ListCustomer list customerMapper.selectByCondition(query); PageInfoCustomer pageInfo new PageInfo(list); model.addAttribute(pageInfo, pageInfo); model.addAttribute(query, query); return customer/list; }關(guān)鍵點在Mapper的XML里條件是否生效要用if標簽動態(tài)拼接不能靠字符串硬拼SQL那是SQL注入的重災(zāi)區(qū)。例如按客戶名模糊搜索姓名可能為空就需要select idselectByCondition resultTypecom.example.crm.entity.Customer SELECT id, name, phone, industry, level, owner_id, next_contact_time FROM customer where if testkeyword ! null and keyword ! AND (name LIKE CONCAT(%, #{keyword}, %) OR phone LIKE CONCAT(%, #{keyword}, %)) /if if testownerId ! null AND owner_id #{ownerId} /if if testlevel ! null and level ! AND level #{level} /if /where ORDER BY create_time DESC /select分頁插件一個容易出問題的地方是PageHelper.startPage之后必須緊跟第一條查詢語句中間不能有其他MyBatis查詢和邏輯處理否則分頁會串到別的SQL上。我剛開始寫的時候在startPage和Mapper調(diào)用之間加了一個日志查詢結(jié)果列表頁每次都查出來全表數(shù)據(jù)還特別慢。多條件查詢頁面上我用了Layui的form組件搜索按鈕觸發(fā)table.reload把表單數(shù)據(jù)作為參數(shù)提交。后端返回的是HTML頁面就不用table.reload那套了直接讓form提交GET請求保持URL可讀可分享更適合服務(wù)端渲染的形態(tài)。3.3 商機階段流轉(zhuǎn)與跟進記錄的落地方案商機是銷售漏斗的數(shù)據(jù)基礎(chǔ)設(shè)計上它必須掛在客戶之下又有獨立的階段狀態(tài)。我在數(shù)據(jù)庫表里設(shè)計了幾個關(guān)鍵字段stage階段、amount預(yù)計金額、expect_deal_date預(yù)計成交日期、probability贏單概率。階段用數(shù)字編碼1到6分別對應(yīng)初次接觸、需求確認、方案報價、商務(wù)談判、贏單、輸單這個枚舉放在代碼里統(tǒng)一管理避免前后端各維護一份。頁面上的商機看板按階段分列展示每一列是一個Kanban卡片。實現(xiàn)上不需要特復(fù)雜的技術(shù)后端按階段分組查詢前端用Layui的柵格布局排開拖拽流轉(zhuǎn)我用的是前端form select切換階段提交后由后端更新stage和probability。狀態(tài)流轉(zhuǎn)這里一定要做校驗比如從“初次接觸”跳轉(zhuǎn)到“贏單”就不合理我加了一個簡單的階段順序校驗攔截器保證數(shù)據(jù)邏輯完整。跟進記錄做成時間線樣式與客戶詳情頁并列展示。每次跟進的類型、內(nèi)容、下次跟進時間、創(chuàng)建人都要記錄。代碼里就是一張follow_up表的多表插入關(guān)鍵點是插入后要更新customer表的next_contact_time字段否則銷售永遠不知道自己下一次該聯(lián)系誰。這個聯(lián)動我一開始沒做后續(xù)跑了一段時間數(shù)據(jù)后發(fā)現(xiàn)很多沒有下次跟進時間的客戶躺在列表里銷售根本想不起來還有這些待辦這就是典型的數(shù)據(jù)孤島問題。3.4 ECharts報表模塊從SQL聚合到前端可視化的完整鏈路報表模塊是這個系統(tǒng)里最出效果的部分。我做了三個核心圖表月度業(yè)績趨勢折線圖、銷售個人業(yè)績排行柱狀圖、商機階段漏斗圖。后端接口不做模板渲染而是返回JSON數(shù)據(jù)。比如漏斗圖接口按商機表里的stage分組統(tǒng)計數(shù)量SQL很簡單SELECT stage, COUNT(*) AS cnt FROM business_opportunity WHERE del_flag 0 GROUP BY stage ORDER BY stageController把查詢結(jié)果封裝成Map用ResponseBody注解直接吐JSON。前端頁面通過Ajax拿到數(shù)據(jù)后組裝成ECharts的series數(shù)據(jù)格式調(diào)用setOption渲染。這里有一個每次都會踩的坑ECharts實例如果已經(jīng)渲染過一次第二次setOption時舊數(shù)據(jù)不會自動清掉。我在漏斗圖上調(diào)了好久發(fā)現(xiàn)切換時間范圍后柱子高度對不上因為新舊數(shù)據(jù)疊加了。解決方法是每次請求前調(diào)用chart.clear()或者在setOption時設(shè)置notMerge參數(shù)為true。$.get(/report/funnel, function (resp) { var chart echarts.init(document.getElementById(funnelChart)); chart.clear(); chart.setOption({ series: [{ type: funnel, left: 10%, width: 80%, data: resp.data, label: { show: true, formatter: : {c} } }] }); });圖表容器div的寬高一定要顯式設(shè)置很多剛接觸ECharts的人把容器寫成百分比高度外層父div沒有高度最后渲染出來圖表是扁的。我在報表頁面里給每個圖表容器都設(shè)了固定高度實測500px左右比較合適。4. 數(shù)據(jù)庫表結(jié)構(gòu)與性能優(yōu)化實戰(zhàn)4.1 CRM核心表結(jié)構(gòu)設(shè)計思路數(shù)據(jù)庫設(shè)計是整個系統(tǒng)穩(wěn)定性的地基我把核心表結(jié)構(gòu)列出來可以作為一個自己動手建庫時的參考模板?？蛻舯鞢REATE TABLE customer ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL COMMENT 客戶名稱, phone VARCHAR(20) COMMENT 聯(lián)系電話, industry VARCHAR(50) COMMENT 行業(yè), level TINYINT COMMENT 客戶等級 1-3, owner_id BIGINT COMMENT 負責(zé)人用戶ID, next_contact_time DATETIME COMMENT 下次跟進時間, del_flag TINYINT DEFAULT 0 COMMENT 刪除標記, create_time DATETIME, update_time DATETIME, KEY idx_owner (owner_id), KEY idx_next_contact (next_contact_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;商機表、跟進表在結(jié)構(gòu)上類似都會冗余一個customer_id外鍵和多一個del_flag邏輯刪除標記。用邏輯刪除而不是物理刪除對銷售數(shù)據(jù)尤其重要客戶雖然可能被標為無效但歷史數(shù)據(jù)還需要追溯分析真從庫里刪掉后續(xù)做統(tǒng)計就斷層了。所有表的主鍵用BIGINT自增字符集用utf8mb4而不是utf8原因是utf8在MySQL里最多3個字節(jié)存不了emoji和生僻字。銷售填客戶備注的時候可能帶個表情符號如果是utf8會直接報錯?；A(chǔ)的表結(jié)構(gòu)設(shè)計不想多說但這兩個坑我見到太多人踩過了。4.2 最容易出問題的SQL與索引優(yōu)化CRM系統(tǒng)的查詢模式相對固定優(yōu)化重點就在幾個高頻列表頁。我最常做的優(yōu)化是給外鍵和查詢條件字段建索引像customer表的owner_id、next_contact_time都加了索引。模糊搜索要特別注意。LIKE ‘%關(guān)鍵詞%’這種寫法會導(dǎo)致索引失效全表掃描?？蛻袅繘]上十幾萬的時候問題不大但數(shù)據(jù)一旦膨脹一個不帶條件的列表查詢能把數(shù)據(jù)庫CPU打滿。折中的辦法是如果確實需要模糊搜索把范圍限定在20萬行以內(nèi)強制走索引更合理的方案是引入專門的全文索引但小項目我一般建議保持簡單先把高頻搜索條件做成下拉選擇減少模糊匹配的觸發(fā)頻率。另一個大坑是深分頁。銷售使用系統(tǒng)半年后客戶表可能幾十萬行翻到第1000頁時limit 9000,10會導(dǎo)致MySQL掃描前9000行后丟棄特別浪費I/O。我用它替換成基于最大主鍵的查詢方式SELECT * FROM customer WHERE id #{lastId} ORDER BY id ASC LIMIT 10這種“上一頁最后一條記錄的ID”游標分頁方式在數(shù)據(jù)量大時性能提升非常明顯頁面交互改成“加載更多”而不是跳頁。對CRM這種業(yè)務(wù)用戶真的需要看到很深的分頁嗎我實測下來幾乎沒人會翻到第100頁之后。所以游標分頁完全夠用還有利于前端做無限滾動。4.3 連接池配置、事務(wù)控制與數(shù)據(jù)一致性問題CRM業(yè)務(wù)里涉及多表聯(lián)動的場景很多比如新增跟進記錄的同時要更新客戶的下次跟進時間這兩條SQL必須在一個事務(wù)里否則就會出現(xiàn)“記錄了跟進但客戶的待辦時間沒變”這種不一致問題。SpringBoot里最簡單的方式就是給Service方法加Transactional注解默認遇到RuntimeException就回滾。我項目里統(tǒng)一定義了業(yè)務(wù)異常繼承RuntimeException這樣事務(wù)在業(yè)務(wù)校驗失敗時也能正確回滾。連接池這塊我用的Druid除了作為連接池它的監(jiān)控頁面還能看到慢SQL統(tǒng)計對排查性能問題極有幫助。在application.yml里配置好druid的stat filter和web-stat filter后瀏覽器訪問/druid/index.html就能看到每個SQL的執(zhí)行時間。我給客戶列表頁做優(yōu)化的時候就是靠監(jiān)控頁發(fā)現(xiàn)慢SQL才定位到索引缺失的問題。事務(wù)隔離級別我用了默認的REPEATABLE_READMySQL InnoDB引擎下基本沒問題。需要注意的一點是長事務(wù)要避免如果一個事務(wù)里做了大量查詢或者分批插入會持有持鎖時間過長并發(fā)一高就容易死鎖。我的習(xí)慣是事務(wù)只包裹必要的寫操作查詢邏輯放在事務(wù)方法外面完成。5. 打包部署與生產(chǎn)環(huán)境問題排查5.1 Maven多環(huán)境打包與可執(zhí)行jar部署開發(fā)完成之后就是構(gòu)建部署。SpringBoot項目用Maven打包非常簡單核心命令是mvn clean package -Dmaven.test.skiptrue如果需要指定生產(chǎn)環(huán)境配置使用profile參數(shù)mvn clean package -Dmaven.test.skiptrue -Pprod對應(yīng)pom.xml里配置多套profile每套profile指定不同的application-{env}.yml。我實際部署時沒用Docker直接在服務(wù)器上跑jar啟動命令是nohup java -jar crm-system.jar --spring.profiles.activeprod /data/logs/crm.log 21 這里有兩個容易忽略的點一是nohup一定要配合使用不然SSH斷開后進程就沒了二是日志重定向最好落到獨立文件方便出問題時用grep定位異常。生產(chǎn)環(huán)境我建議在啟動參數(shù)里增加-Xms和-Xmx把堆內(nèi)存上下限定成一樣避免JVM動態(tài)擴容引起性能波動比如-Xms512m -Xmx512mCRM這種中小系統(tǒng)給512M到1G完全夠了。5.2 從開發(fā)到上線的高頻報錯速查表我整理了這份項目里遇到的高頻問題列表按現(xiàn)象、原因、解決辦法三列對查報錯現(xiàn)象根本原因解決辦法MySQL連接時報SSL connection error高版本驅(qū)動默認開啟SSLURL后加useSSLfalsePublic Key Retrieval is not allowedMySQL8新認證機制URL上加allowPublicKeyRetrievaltrueUnknown time zone / 時區(qū)錯誤未指定serverTimezoneURL上加serverTimezoneAsia/ShanghaiFreeMarker模板訪問報錯或404模板路徑或文件后綴錯誤確認模板在templates目錄且后綴是.ftl頁面CSS/JS全部加載失敗攔截器攔截了靜態(tài)資源攔截器排除/static/**路徑Layui表格數(shù)據(jù)正常但分頁不工作PageHelper分頁被其他查詢污染startPage后緊跟目標查詢語句部署jar后中文亂碼Linux默認編碼不是UTF-8啟動參數(shù)加-Dfile.encodingUTF-8Druid監(jiān)控頁面無法打開未放行druid的Servlet配置web-stat-filter并開啟enabledMaven依賴下載極慢默認中央倉庫網(wǎng)絡(luò)不穩(wěn)定settings.xml配置阿里云鏡像表里這些坑有好幾個都是我實際踩過的。最典型的是部署到Linux中文亂碼本地開發(fā)Windows沒問題一上服務(wù)器全變問號。排查下來發(fā)現(xiàn)是Linux系統(tǒng)locale沒有設(shè)置UTF-8Java讀取文件默認用了系統(tǒng)編碼加上Dfile.encoding參數(shù)后解決。5.3 生產(chǎn)環(huán)境數(shù)據(jù)初始化與權(quán)限配置上線前有一件事一定要做數(shù)據(jù)初始化。我先在測試環(huán)境把系統(tǒng)跑通然后用mysqldump導(dǎo)出表結(jié)構(gòu)和基礎(chǔ)數(shù)據(jù)再導(dǎo)入生產(chǎn)庫。不要在生產(chǎn)庫手工執(zhí)行一遍建表腳本漏一個索引后面補起來相當(dāng)被動。權(quán)限初始化這塊管理員賬號、角色、部門數(shù)據(jù)我用一個init.sql腳本管理腳本里先判斷記錄是否存在再插入保證腳本可以重復(fù)執(zhí)行。生產(chǎn)環(huán)境的日志級別也要改開發(fā)環(huán)境MyBatis打印了所有SQL生產(chǎn)環(huán)境如果還開著會把磁盤寫爆。我把log-impl配置成org.apache.ibatis.logging.nologging.NoLoggingImplSpringBoot的日志級別設(shè)為INFO只保留業(yè)務(wù)關(guān)鍵日志。6. 項目實操心得與后續(xù)擴展方向6.1 復(fù)盤這次CRM改造里最值得說的幾個教訓(xùn)整個項目做完我復(fù)盤了一遍有幾個點值得單獨提醒。第一個是關(guān)于Session存儲。一開始我把用戶對象全部放進Session里面有位圖、頭像字段等冗長信息用戶在個人中心上傳新頭像后Session里的舊數(shù)據(jù)還留著展示還是舊頭像。后來把Session對象瘦身成ID和關(guān)鍵標識需要完整信息時再查庫問題解決。第二個是關(guān)于FreeMarker模板緩存。上線前我把cache改成了true結(jié)果有一次改了頁面上的一個錯別字重新部署后發(fā)現(xiàn)頁面沒變排查才想起來是模板緩存的問題。生產(chǎn)環(huán)境如果有模板變更要么重啟服務(wù)要么用腳本清空freemarker緩存目錄這個坑影響不大但很惱人。第三個是SQL注入。我在寫客戶搜索功能時曾經(jīng)圖省事直接用字符串拼接條件結(jié)果被測試同事傳入特殊字符搞崩了查詢。后來全部改成MyBatis的#{}預(yù)編譯參數(shù)這個教訓(xùn)我在代碼里貫徹得很徹底所有動態(tài)條件都走XML的if標簽配合#{}絕不拼字符串。第四個是ECharts圖表的舊數(shù)據(jù)覆蓋。前面已經(jīng)提過這個問題如果不在setOption時處理報表數(shù)據(jù)一刷新就顯示混亂。我后來做了一個公共封裝每次繪制圖表前都強制清空舊實例。6.2 CRM系統(tǒng)可以持續(xù)演進的幾個方向核心功能落地后我整理了目前沒做但值得擴展的方向給有同樣需求的朋友一個參考導(dǎo)出Excel銷售經(jīng)常要把客戶名單導(dǎo)出給領(lǐng)導(dǎo)看我用Apache POI解決了這個問題模板導(dǎo)出客戶列表、商機報表按照標題里提到的“java poi word能生成圖表嗎”這個思路擴展數(shù)據(jù)還可以導(dǎo)出為帶圖表的Word文檔。自動提醒每個銷售登錄后能看到今天需要跟進的客戶列表靠cron定時任務(wù)掃描next_contact_time把過期未跟進的客戶推送到首頁待辦。WebSocket消息通知客戶被分配、商機階段變化時給相關(guān)銷售實時推送消息比刷新頁面體驗好很多。數(shù)據(jù)大屏把ECharts的報表做成一整塊大屏頁面投到銷售辦公室電視上實時展示整體業(yè)績和漏斗轉(zhuǎn)化這對管理層的直觀沖擊力很強。多租戶隔離如果以后要給不同分公司獨立使用可以在所有業(yè)務(wù)表加一個org_id字段實現(xiàn)數(shù)據(jù)隔離而不用重新設(shè)計表結(jié)構(gòu)。我在實際使用這套系統(tǒng)的過程中最深的感受是技術(shù)的復(fù)雜度永遠是第二位的業(yè)務(wù)模型是不是貼合銷售真實工作流才是CRM能不能活下去的核心。SpringBoot、ECharts、MySQL這些都是隨手就能上手的工具難的是把“客戶、商機、跟進”這條鏈路理解透再把它們穩(wěn)妥地落到代碼和表結(jié)構(gòu)里。希望這篇復(fù)盤能幫你在自己的項目里少走幾條彎路。