做過文檔管理系統(tǒng)的人都知道這類項目表面上就是一個文件的CRUD但真正把需求理清楚、把權(quán)限和流程落地難度一點都不低。尤其是以任務(wù)書形式給出的SSM版本文檔管理系統(tǒng)既要滿足基礎(chǔ)的文件存取又要體現(xiàn)三層架構(gòu)的工程化能力還要在答辯或驗收時講清楚每一個設(shè)計決策。這篇博文我就以自己從任務(wù)書到交付的完整過程為例把里面的設(shè)計思路、表結(jié)構(gòu)、核心代碼、部署細節(jié)和踩坑記錄都翻出來給正準(zhǔn)備動手或者寫技術(shù)文檔的同學(xué)一點參考。項目標(biāo)題: 基于SSM的文檔管理系統(tǒng)的設(shè)計與實現(xiàn)任務(wù)書——這句話里真正重要的關(guān)鍵詞是任務(wù)書意味著你拿到的不是一句做個文檔系統(tǒng)的模糊需求而是一份有功能邊界、有技術(shù)指標(biāo)、有驗收標(biāo)準(zhǔn)的約束文件。SSM是SpringSpringMVCMyBatis的組合在目前Spring Boot大行其道的環(huán)境下依然有很多課程設(shè)計和中小型企業(yè)內(nèi)部項目在用這套組合原因無非兩個一是Spring的核心IoC與AOP思想必須通過SSM這種手動裝配的方式才能理解得更透二是大量存量系統(tǒng)仍然是SSM架構(gòu)維護和二次開發(fā)的需求長期存在。我的經(jīng)驗是拿到任務(wù)書先別急著寫代碼花兩天時間把數(shù)據(jù)庫表和接口設(shè)計定下來后面能省一半的返工時間。下面我從頭到尾拆解這個項目的完整落地過程。1. 項目定位與整體設(shè)計思路1.1 這類項目要解決的核心痛點是什么文檔管理系統(tǒng)的本質(zhì)不是把文件存起來而是解決三個現(xiàn)實問題文件散落、權(quán)限失控、操作無痕。先說說使用場景。一個小團隊或者一個部門日常產(chǎn)生的合同、制度、技術(shù)資料、會議紀(jì)要往往散落在各人的電腦和共享文件夾里。共享文件夾最大的問題是沒有權(quán)限粒度要么大家都能刪要么配起來極其麻煩。誰在什么時間修改過哪個文件完全沒有記錄。文檔管理系統(tǒng)要做的就是把散落的文件收攏到一個統(tǒng)一入口按組織架構(gòu)和角色控制誰能看、誰能傳、誰能刪同時對關(guān)鍵操作留下日志。從任務(wù)書常見的要求來看功能模塊一般繞不開這幾個用戶登錄與角色權(quán)限、文檔分類管理、文檔上傳下載、文檔檢索、操作日志、回收站機制。有些任務(wù)書還會加上在線預(yù)覽、版本管理、收藏與分享但核心永遠是權(quán)限和流程。我接手過的模擬項目X就是典型的中小規(guī)模需求用戶分管理員和普通用戶兩級管理員可以管理所有文檔和分類普通用戶只能管理自己上傳的文檔所有用戶共享一個公共文檔庫。就這么一條簡單的規(guī)則直接決定了后面用戶表、角色表和文檔表的關(guān)聯(lián)方式。1.2 為什么選SSM而不是Spring Boot這個問題幾乎每輪答辯都會被問到也是任務(wù)書如此設(shè)計技術(shù)棧的核心用意。SSM是一個典型的三層架構(gòu)技術(shù)組合Spring負責(zé)對象管理和事務(wù)控制SpringMVC負責(zé)HTTP請求的路由與參數(shù)綁定MyBatis負責(zé)SQL與對象映射。這三層各司其職邊界非常清晰。而Spring Boot把大量配置自動化了你只需要引入依賴就能跑起來但底層的DispatcherServlet、HandlerMapping、SqlSessionFactory這些核心機制反而被隱藏了。對于以學(xué)習(xí)和教學(xué)為目的的任務(wù)書項目選SSM的意義在于你必須自己配置數(shù)據(jù)源、自己聲明事務(wù)管理器、自己寫攔截器、自己管理SQL映射這個過程能把框架的核心原理串起來。換句話說SSM版本做一遍Spring Boot版本就是水到渠成的事情。另外從實際運維角度看很多公司在2015到2020年間沉淀的內(nèi)部系統(tǒng)就是SSM架構(gòu)目前依然在線運行。一個能基于SSM做二次開發(fā)的工程師在老系統(tǒng)維護這個維度上是有實際價值的。1.3 功能模塊的拆解與邊界劃分動手設(shè)計之前我會把任務(wù)書里的每一條功能要求拆成四層表現(xiàn)層、接口層、服務(wù)層、數(shù)據(jù)層。這是SSM項目的天然分層也是寫技術(shù)文檔時最直觀的結(jié)構(gòu)。以文檔檢索為例表現(xiàn)層是一個帶搜索框的列表頁接口層接收keyword、categoryId、pageNum、pageSize這些參數(shù)服務(wù)層負責(zé)拼接查詢條件并調(diào)用MyBatis的Mapper接口數(shù)據(jù)層則是動態(tài)SQL的查詢語句。每一層只干自己的事后面排查問題的時候一層一層看效率很高。功能邊界同樣重要。任務(wù)書如果寫了回收站就要定義清楚用戶刪除文檔是邏輯刪除還是物理刪除回收站里的文檔保留多久徹底刪除是否需要管理員權(quán)限這些邊界問題如果不提前想清楚代碼寫到最后很容易陷進改不完的狀態(tài)流轉(zhuǎn)。我的建議是畫一張角色權(quán)限矩陣橫軸是功能操作縱軸是角色類型單元格里標(biāo)注允許或不允許。這張表后面既是寫代碼的依據(jù)也是測試用例的來源。2. 數(shù)據(jù)庫設(shè)計與核心表結(jié)構(gòu)2.1 表結(jié)構(gòu)設(shè)計的原則與典型拆分文檔管理系統(tǒng)的數(shù)據(jù)庫表不會特別多但表與表之間的關(guān)聯(lián)關(guān)系很考驗設(shè)計功底。一個典型的SSM文檔管理系統(tǒng)核心表包括用戶表、角色表、用戶角色關(guān)聯(lián)表、文檔分類表、文檔信息表、操作日志表。用戶表的核心字段是id、用戶名、密碼、真實姓名、郵箱、手機號、狀態(tài)、創(chuàng)建時間。密碼一定不要存明文用MD5加鹽或者BCrypt散列這是底線問題。角色表相對簡單就是id、角色名、角色編碼和描述。用戶和角色是多對多關(guān)系所以需要一張中間關(guān)聯(lián)表。文檔信息表是整個系統(tǒng)最關(guān)鍵的一張表字段設(shè)計我后面單獨展開。分類表是自關(guān)聯(lián)結(jié)構(gòu)用parentId字段實現(xiàn)樹形目錄比如技術(shù)資料/后端/框架這就是兩層的父子關(guān)系。操作日志表記錄關(guān)鍵行為字段包括操作人、操作類型、操作對象、操作詳情、IP地址、操作時間。這張表的價值在于審計追溯屬于平時沒人看、出事必須查的表設(shè)計時寧可多存字段不要事后補字段。2.2 文件存儲方式數(shù)據(jù)庫BLOB還是磁盤路徑這是文檔管理系統(tǒng)里最容易糾結(jié)的決定。我見過有人把文件轉(zhuǎn)成byte[]直接塞進數(shù)據(jù)庫的BLOB字段也見過只存文件路徑的做法。我的結(jié)論很明確主流可靠方案是文件存磁盤數(shù)據(jù)庫存元數(shù)據(jù)和路徑。用一個維度來對比會非常直觀對比項數(shù)據(jù)庫BLOB磁盤路徑元數(shù)據(jù)數(shù)據(jù)庫備份體積非常大備份恢復(fù)都很慢數(shù)據(jù)庫體積小備份快文件讀取性能每次讀取走數(shù)據(jù)庫連接高頻下載時是災(zāi)難文件流直接從磁盤讀或交給靜態(tài)資源服務(wù)器處理文件預(yù)覽支持需要額外寫二進制流輸出邏輯配合Nginx映射目錄即可支持?jǐn)U展性數(shù)據(jù)庫擴容成本高文件可遷移到OSS或分布式存儲如果任務(wù)書明確要求使用BLOB那說明這個項目是教學(xué)演示級重點是展示MyBatis對大字段的處理能力這種情況可以按照任務(wù)書執(zhí)行但也要在文檔里說明方案的局限性。如果任務(wù)書沒有強制要求存儲方式選磁盤路徑方案更合理也更符合企業(yè)真實做法。文件存儲目錄的規(guī)劃同樣重要。在應(yīng)用所在磁盤建立一個專用目錄比如/data/docfiles下面按日期或者按分類分子目錄存儲時給文件生成一個新的隨機文件名擴展名保留原文件擴展名。這樣做的好處是避免重名覆蓋同時避免特殊字符和中文名在文件系統(tǒng)層面的兼容問題。2.3 權(quán)限設(shè)計從簡到繁的兩檔實現(xiàn)權(quán)限模型是文檔管理系統(tǒng)和普通文件目錄最本質(zhì)的區(qū)別。任務(wù)書通常會給兩種權(quán)限要求對應(yīng)的實現(xiàn)復(fù)雜度差別很大。第一檔是粗粒度權(quán)限只有管理員和普通用戶兩種角色管理員能做所有操作普通用戶只能操作自己上傳的文檔。這種模型不需要菜單表只需要在service層判斷當(dāng)前登錄用戶的角色和資源歸屬即可。第二檔是細粒度RBAC任務(wù)書可能要求不同角色看到不同菜單、不同按鈕這時候就要引入菜單表和角色菜單關(guān)聯(lián)表。登錄成功后查詢當(dāng)前角色的菜單列表動態(tài)渲染左側(cè)導(dǎo)航欄。后端每個接口通過攔截器和注解雙重校驗權(quán)限比第一檔復(fù)雜不少。我的建議是如果任務(wù)書沒有明確要求權(quán)限細分先做第一檔把核心業(yè)務(wù)流程跑通有余力再升級到第二檔。權(quán)限這東西最容易陷入過度設(shè)計一套系統(tǒng)如果一共就三個角色硬生生做五張權(quán)限表純屬給自己挖坑。3. 核心技術(shù)實現(xiàn)與實操要點3.1 登錄認(rèn)證與攔截器的完整實現(xiàn)登錄認(rèn)證幾乎是每一個SSM項目的第一個硬骨頭。流程不復(fù)雜但細節(jié)很多。登錄接口接收用戶名和密碼調(diào)用service層根據(jù)用戶名查詢用戶比對密碼時用MD5加鹽的方式前端提交明文密碼后端用固定鹽值拼上密碼再做MD5與數(shù)據(jù)庫存儲的散列值比對。成功之后將用戶對象放入session同時放入角色編碼后續(xù)每個請求通過攔截器從session中判斷登錄狀態(tài)。SpringMVC的攔截器需要實現(xiàn)HandlerInterceptor接口核心在preHandle方法里public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session request.getSession(); Object user session.getAttribute(loginUser); if (user null) { response.sendRedirect(request.getContextPath() /login); return false; } return true; }這里有幾個關(guān)鍵配置需要注意。攔截器要排除登錄接口、注冊接口和靜態(tài)資源路徑否則CSS、JS、圖片全部被攔頁面會變成裸HTML。在spring-mvc.xml配置攔截器路徑時我用的是/*還是/**這點非常容易搞錯。/*只匹配一級路徑/doc/detail/1這種多級URL會直接繞過攔截必須用/**才能匹配所有層級。還有一個隱患是session超時。Tomcat默認(rèn)session過期時間是30分鐘用戶在上傳大文件或長時間停留后提交請求時session已經(jīng)失效會被攔截器踢回登錄頁。這個情況要在任務(wù)書文檔的異常處理部分提及生產(chǎn)環(huán)境可以適當(dāng)調(diào)大session超時時間或者配合記住我的Cookie機制做自動登錄。3.2 文件上傳與下載的實現(xiàn)細節(jié)文件上傳是文檔管理系統(tǒng)的核心操作也是坑最多的地方。SpringMVC處理文件上傳依賴commons-fileupload和commons-io兩個庫在spring-mvc.xml中配置MultipartResolver。核心配置如下bean idmultipartResolver classorg.springframework.web.multipart.commons.CommonsMultipartResolver property namemaxUploadSize value104857600/ property namemaxInMemorySize value1048576/ property namedefaultEncoding valueUTF-8/ /beanmaxUploadSize是總上傳大小上限這里設(shè)置100MB單位是字節(jié)。maxInMemorySize是內(nèi)存緩沖閾值超過1MB的文件會先寫入臨時文件再處理避免大文件撐爆內(nèi)存。這兩個參數(shù)如果不設(shè)置Tomcat默認(rèn)單次請求最大數(shù)據(jù)量可能是2MB或者2048KB用戶傳個稍大的PDF就會報錯。接收文件的Controller層方法簽名是MultipartFile參數(shù)PostMapping(/upload) ResponseBody public Result upload(RequestParam(file) MultipartFile file, RequestParam(categoryId) Integer categoryId) { if (file.isEmpty()) { return Result.error(請選擇文件); } String originalFilename file.getOriginalFilename(); String ext originalFilename.substring(originalFilename.lastIndexOf(.)); String newFileName UUID.randomUUID().toString().replace(-, ) ext; // 保存到磁盤 File dest new File(fileDir File.separator newFileName); file.transferTo(dest); // 插入文檔表記錄 docService.addDoc(...); }保存文件前一定要做擴展名校驗。任務(wù)書里通常會寫支持常見辦公文檔格式那就定義一個白名單doc、docx、xls、xlsx、ppt、pptx、pdf、txt、zip。不要用黑名單攔截exe、bat這種可執(zhí)行文件因為黑名單永遠漏白名單才是可靠方案。下載文件有兩種寫法。一種是返回ResponseEntitybyte[]代碼簡潔但大文件會把整個文件讀進內(nèi)存另一種是直接用HttpServletResponse獲取OutputStream流式寫入這種方法對大文件更友好。流式下載核心代碼如下File file new File(filePath); response.setContentType(application/octet-stream); String fileName URLEncoder.encode(doc.getFileName(), UTF-8); response.setHeader(Content-Disposition, attachment;filename fileName); FileInputStream fis new FileInputStream(file); OutputStream os response.getOutputStream(); byte[] buffer new byte[1024 * 8]; int len; while ((len fis.read(buffer)) ! -1) { os.write(buffer, 0, len); } os.flush(); fis.close();這里最大的坑是下載文件名中文亂碼。HTTP協(xié)議頭不支持非ASCII字符必須用URLEncoder轉(zhuǎn)碼瀏覽器收到后會自動解碼。如果不做這步文件名是中文的文檔下載下來全是亂碼。下載完成后還要回寫一條操作日志記錄哪個用戶在什么時間下載了哪個文件同時把數(shù)據(jù)庫里的下載數(shù)字段加一。這一步很多人會漏而操作日志恰恰是任務(wù)書評分的加分項。3.3 MyBatis動態(tài)SQL與分頁查詢的最佳實踐文檔管理系統(tǒng)的查詢條件通常不固定用戶可能只按文件名搜也可能同時按分類和文件名搜還可能按上傳時間范圍搜。這種場景正是MyBatis動態(tài)SQL發(fā)揮威力的地方。Mapper XML里用where和if標(biāo)簽拼接條件select idsearchDocs resultTypecom.example.pojo.Document select * from doc_info where if testkeyword ! null and keyword ! and file_name like concat(%, #{keyword}, %) /if if testcategoryId ! null and category_id #{categoryId} /if if testuploaderId ! null and uploader_id #{uploaderId} /if if teststartTime ! null and create_time gt; #{startTime} /if /where order by create_time desc /selectwhere標(biāo)簽會自動處理第一個條件前面的and不用手動加where 11這種寫法看起來不優(yōu)雅但在MyBatis里確實很多人還在用只是不建議因為會影響查詢優(yōu)化器對索引的使用。分頁查詢我推薦使用PageHelper插件引入依賴后在service層調(diào)用PageHelper.startPage(pageNum, pageSize)緊接著的查詢就是分頁查詢再通過PageInfo對象獲取總記錄數(shù)。用法如下PageHelper.startPage(pageNum, pageSize); ListDocument list docMapper.searchDocs(condition); PageInfoDocument pageInfo new PageInfo(list);PageHelper的原理是攔截MyBatis的Executor在查詢前自動拼接LIMIT語句。優(yōu)點是代碼侵入性小缺點是有時候容易忘掉它只能在第一次查詢前調(diào)用如果Mapper里有兩個查詢它只對第一個生效。如果不想引入額外依賴也可以手寫LIMIT分頁自己算偏移量再單獨寫一條count查詢。這種方式更可控但代碼量大一些。課程設(shè)計階段用PageHelper完全足夠。還有一個MyBatis高頻坑插入文檔后要立刻拿到自增主鍵用于回填文檔ID和后續(xù)操作。配置起來很簡單insert idaddDoc parameterTypecom.example.pojo.Document useGeneratedKeystrue keyPropertyid如果沒有這行配置你插入后拿到的id永遠是0后面要做根據(jù)ID綁定分類、生成日志關(guān)聯(lián)ID時全都會出問題。4. 關(guān)鍵配置與部署實操4.1 環(huán)境準(zhǔn)備與依賴管理一個標(biāo)準(zhǔn)的SSM項目環(huán)境我這邊用的是JDK 1.8、Maven 3.6、Tomcat 8.5、MySQL 5.7。JDK 1.8在SSM生態(tài)里兼容性最好MyBatis和Spring的老版本都能正常跑Tomcat 8.5對應(yīng)Servlet 3.1規(guī)范支持SpringMVC的注解驅(qū)動方式。Maven依賴是SSM項目里最容易出錯的部分。常見問題是版本沖突spring-webmvc用的是5.xspring-jdbc卻引成一個4.x啟動時各種NoSuchMethodError。建議所有Spring相關(guān)依賴統(tǒng)一版本屬性在pom.xml中定義properties spring.version5.3.28/spring.version /properties核心依賴清單如下用途依賴名說明Spring核心spring-context, spring-webmvc版本統(tǒng)一數(shù)據(jù)訪問mybatis, mybatis-springMyBatis和Spring整合連接池druid阿里連接池監(jiān)控方便文件上傳commons-fileupload, commons-ioMultipart支持JSON處理jackson-databind前后端交互分頁插件pagehelper分頁查詢JSTLjstl, taglibs-standard-implJSP頁面使用JDK 1.8對應(yīng)Tomcat版本不能太新Tomcat 10把javax改名成了jakartaSpring老版本的包全都找不到類這是新手常踩的坑。我推薦直接用Tomcat 8.5減少不必要的適配。4.2 SSM整合配置的三個關(guān)鍵文件SSM項目需要三份配置文件web.xml、spring-mvc.xml、spring-mybatis.xml。這三份文件的職責(zé)劃分清晰配置時各管各的。web.xml配置編碼過濾器、Spring容器監(jiān)聽器和DispatcherServletfilter filter-nameencodingFilter/filter-name filter-classorg.springframework.web.filter.CharacterEncodingFilter/filter-class init-param param-nameencoding/param-name param-valueUTF-8/param-value /init-param init-param param-nameforceEncoding/param-name param-valuetrue/param-value /init-param /filterCharacterEncodingFilter放在所有過濾器最前面而且forceEncoding要設(shè)為true否則只影響請求編碼不影響響應(yīng)編碼頁面會亂碼得很均勻。spring-mvc.xml配置掃描Controller包、注解驅(qū)動、視圖解析器、攔截器和MultipartResolver。spring-mybatis.xml配置掃描service、配置數(shù)據(jù)源、配置SqlSessionFactory、配置Mapper掃描、配置事務(wù)管理器。DataSource用Druid連接池的核心參數(shù)是initialSize5、maxActive20、minIdle5這些參數(shù)要根據(jù)實際并發(fā)量調(diào)整不要默認(rèn)值跑天下。事務(wù)管理是我特別想強調(diào)的一點。文檔系統(tǒng)中刪除分類、批量搬移文件、更新文檔狀態(tài)這些操作涉及多張表如果沒有事務(wù)中間一步失敗會導(dǎo)致數(shù)據(jù)不一致。配置事務(wù)管理器后在Service實現(xiàn)類或方法上使用Transactional注解即可。4.3 部署到Tomcat的完整流程部署階段的任務(wù)是打包成war包丟進Tomcat的webapps目錄。Maven打包前要先做幾個檢查數(shù)據(jù)庫連接URL的IP是不是生產(chǎn)庫的IP上傳文件目錄在服務(wù)器上是否存在磁盤權(quán)限是否可寫。war包部署后同樣有一個約束要提前規(guī)避上傳文件目錄不能放在Tomcat部署目錄內(nèi)部。如果文件存到webapps/upload下一次重新部署war包時整個目錄會被覆蓋用戶上傳的文件全部丟失。正確做法是把上傳目錄配置到Tomcat之外比如/data/docfiles通過配置文件注入路徑這樣重新部署也不會丟文件。生產(chǎn)環(huán)境的數(shù)據(jù)庫初始化腳本建議在部署文檔中單獨提供。建庫語句、建表語句、初始管理員賬號的插入語句都要寫成SQL腳本。初始化時要注意字符集設(shè)置建庫語句帶上DEFAULT CHARSETutf8mb4否則存emoji或生僻字時數(shù)據(jù)庫直接報錯。5. 常見問題與排查技巧實錄5.1 文件上傳失敗的幾種典型場景上傳功能是這個項目問題重災(zāi)區(qū)我把常見問題匯總成表格排查時對照著看效率很高。報錯現(xiàn)象根本原因解決方案請求被拒絕超出大小限制maxUploadSize未配置或太小設(shè)置CommonsMultipartResolver的maxUploadSize空文件也能上傳成功未判空file.isEmpty()Controller層加判空和擴展名校驗上傳中文文件名保存后亂碼編碼過濾器未設(shè)置或順序不對web.xml放最前forceEncodingtrue傳到本地目錄出現(xiàn)重復(fù)文件直接用原文件名改用UUID隨機名存儲大文件上傳內(nèi)存溢出maxInMemorySize過大設(shè)為1MB左右觸發(fā)臨時文件機制還有一個很容易被忽略的問題如果項目配置了Spring Security或自定義的過濾器它可能會讀取并消費請求體導(dǎo)致MultipartResolver拿不到文件數(shù)據(jù)。雖然SSM項目一般不引入Security但如果遇到上傳接口無響應(yīng)的情況優(yōu)先檢查過濾器鏈有沒有攔請求體。5.2 中文亂碼的一次排查實錄亂碼問題在SSM項目中幾乎不可避免我實際排查過的案例里亂碼往往不是單一原因而是多層疊加的結(jié)果。假設(shè)上傳一個名為產(chǎn)品需求說明書.docx的文件下載后文件名變成亂碼。第一層檢查URL編碼Content-Disposition頭里必須用URLEncoder.encode轉(zhuǎn)碼第二層檢查瀏覽器解碼方式不同瀏覽器對RFC 5987格式的支持有差異我最終用了一個簡單粗暴且兼容的方案文件名轉(zhuǎn)碼成UTF-8后再按ISO-8859-1重新編碼再用URLEncoder處理雖然繞了一點但對主流瀏覽器都有效。如果列表頁顯示的文件名亂碼那是數(shù)據(jù)庫層面或者前端頁面編碼的問題。數(shù)據(jù)庫連接URL要加characterEncodingutf8頁面JSP的pageEncoding要設(shè)置為UTF-8Tomcat的URIEncoding也要設(shè)為UTF-8。這三個地方只要有一個漏了中文就會在某個環(huán)節(jié)變成問號。排查思路永遠是從源頭到展示一步步試不要瞎改配置。先用數(shù)據(jù)庫客戶端直接查庫判斷數(shù)據(jù)本身是否正常再判斷是后端返回前就已經(jīng)亂碼還是瀏覽器顯示時亂碼。定位到具體環(huán)節(jié)修復(fù)就很快了。5.3 前端與后端聯(lián)調(diào)中的隱藏坑前后端分離不是SSM的主流用法但很多任務(wù)書要求頁面顯示結(jié)果和接口分開測試。用AJAX請求JSON數(shù)據(jù)時有幾個坑不可避免。Jackson默認(rèn)序列化Date類型的結(jié)果是一長串時間戳數(shù)字前端顯示很丑陋。解決辦法是在實體類的日期字段上加注解JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8) private Date createTime;另一個是static靜態(tài)資源被攔截的問題。如果spring-mvc.xml里沒有放行靜態(tài)資源瀏覽器打開頁面時CSS和JS全部加載失敗頁面光禿禿的。配置方式有兩種要么用mvc:default-servlet-handler/交給默認(rèn)Servlet處理要么用mvc:resources mapping/static/** location/static//指定資源路徑映射。我推薦使用mapping方式匹配規(guī)則更明確。JSON字符串中文亂碼也比較常見。SpringMVC的ResponseBody默認(rèn)StringHttpMessageConverter編碼是ISO-8859-1需要在spring-mvc.xml配置消息轉(zhuǎn)換器使用UTF-8否則通過AJAX返回的中文全是問號。5.4 性能與安全的基本加固文檔管理系統(tǒng)的并發(fā)量一般不高但也不能完全不考慮性能和建議層面的安全加固尤其是任務(wù)書如果涉及系統(tǒng)的非功能需求這一節(jié)。查詢性能的重中之重是索引。doc_info表的file_name字段如果經(jīng)常被模糊查詢可以建立前綴索引create_time字段用于排序建普通索引即可category_id是外鍵關(guān)聯(lián)字段頻繁做等值查詢必須建索引。安全方面有兩個底線操作必須做。一是密碼加密二是SQL注入防護。MyBatis的#{}預(yù)編譯天然防止SQL注入但那種手寫拼接${}的地方要特別小心一旦出現(xiàn)在用戶可控參數(shù)的場景就存在注入風(fēng)險。上傳文件的存儲路徑也要做合法性校驗嚴(yán)禁用戶通過路徑穿越等方式訪問系統(tǒng)目錄。我一般在保存文件時直接使用數(shù)據(jù)庫生成的ID和時間戳重構(gòu)文件名完全不用原始文件名這樣可以最大化降低這類風(fēng)險。還有一個經(jīng)驗是備份策略。文檔系統(tǒng)的數(shù)據(jù)價值主要在文件本身數(shù)據(jù)庫可以每天備份一次但文件目錄最好采用增量同步方案。我在模擬項目X中寫過一個簡單的Shell腳本每天凌晨將當(dāng)日新增文件同步到備份盤這個操作成本極低關(guān)鍵時候能救命。6. 從任務(wù)書到交付的項目管理心得6.1 任務(wù)書的驗收標(biāo)準(zhǔn)如何落實到開發(fā)計劃任務(wù)書在結(jié)尾部分通常會有成果要求比如系統(tǒng)運行截圖、核心代碼說明、數(shù)據(jù)庫設(shè)計文檔、操作手冊、測試報告。這些文檔不是最后一天能趕出來的最好開發(fā)過程中同步積累。我習(xí)慣在項目目錄下維護三個文檔技術(shù)方案書、數(shù)據(jù)庫設(shè)計說明、測試記錄表。技術(shù)方案書寫框架選型理由和模塊劃分?jǐn)?shù)據(jù)庫設(shè)計說明標(biāo)注每張表每個字段的業(yè)務(wù)含義測試記錄表把每個功能點的操作步驟和結(jié)果截圖存檔。這份資料往任務(wù)書里一貼就是一份非常完整的項目材料。時間分配上前期設(shè)計占30%編碼占50%測試和文檔占20%。新手最常犯的錯誤是一上來就寫代碼寫到一半發(fā)現(xiàn)表結(jié)構(gòu)不合理返工成本極高。6.2 答辯和評審環(huán)節(jié)的講解重點如果這個項目最終要答辯講解的邏輯主線應(yīng)該是需求分析到表設(shè)計表設(shè)計到代碼實現(xiàn)代碼實現(xiàn)到功能演示。不要一上來就念代碼要先講清楚為什么這樣設(shè)計。我建議準(zhǔn)備一個設(shè)計決策表把任務(wù)書中每個關(guān)鍵要求對應(yīng)到具體的實現(xiàn)方案和技術(shù)點。比如任務(wù)書寫了支持多條件組合檢索就對應(yīng)MyBatis動態(tài)SQL寫不同角色對文檔操作權(quán)限不同就對應(yīng)攔截器和角色判斷邏輯。答辯時評委問什么就從這張表里找答案。演示環(huán)節(jié)一定要用自己的測試數(shù)據(jù)不要用空的數(shù)據(jù)庫或者只有兩三條記錄的庫演示。提前準(zhǔn)備好十來份不同格式的測試文檔把搜索、分類、權(quán)限切換、回收站恢復(fù)這些操作連貫演示一遍效果比說一百句話都強。6.3 拓展思路與后續(xù)升級方向SSM版本的文檔管理系統(tǒng)做完后往下的升級路徑很清晰如果團隊規(guī)模變大可以替換成Spring Boot來降低維護成本配合Spring Security做更細粒度的權(quán)限控制如果文件量繼續(xù)增長可以對接對象存儲服務(wù)把文件從本地磁盤搬遷到云端數(shù)據(jù)庫只存訪問地址如果要做在線預(yù)覽可以通過中間件把Office文件轉(zhuǎn)換成PDF后再展示這也是企業(yè)版文檔系統(tǒng)最常見的功能。技術(shù)選型從來不是追新而是合適。SSM這套組合雖然在配置上比Spring Boot繁瑣但它的每一行配置都在幫你理解Web開發(fā)底層發(fā)生了什么。這個理解在排查線上問題時非常值錢。我個人在多次做過類似系統(tǒng)后最大的體會是文檔管理系統(tǒng)的難點不在存取文件而在定義清楚誰能做什么。任務(wù)書限定SSM反而是件好事它強迫你把權(quán)限、流程、狀態(tài)這些業(yè)務(wù)規(guī)則用最傳統(tǒng)但最扎實的三層結(jié)構(gòu)寫出來。把這份功課做扎實了以后不管換成什么框架、什么存儲、什么部署方式核心的業(yè)務(wù)建模能力都是通用的。