簡(jiǎn)介一份基于SpringBootVueMySQL的企業(yè)檔案管理系統(tǒng)可運(yùn)行源碼包面向Java后端開發(fā)者、軟件專業(yè)學(xué)生及企業(yè)信息化建設(shè)者用于解決檔案數(shù)據(jù)分散、借閱流程不透明、檢索效率低等管理難題。系統(tǒng)內(nèi)置檔案分類、權(quán)限管理、生命周期追蹤、電子上傳與掃描歸檔、自動(dòng)編號(hào)、借閱歸還提醒、全文檢索與關(guān)聯(lián)分析等模塊前端覆蓋管理員、員工、管理者多角色界面能夠支撐企業(yè)級(jí)檔案全流程管理。資源共21個(gè)文件以16個(gè)Java源文件為核心配合YAML/XML配置、Maven構(gòu)建文件及Markdown說明文檔整體僅23KB結(jié)構(gòu)精簡(jiǎn)便于直接導(dǎo)入IDE運(yùn)行與二次開發(fā)。目前已有95人學(xué)習(xí)下載適合作為SpringBoot企業(yè)級(jí)項(xiàng)目實(shí)戰(zhàn)參考也可為中小型檔案管理系統(tǒng)改造提供基礎(chǔ)代碼。1. 企業(yè)檔案管理系統(tǒng)可運(yùn)行源碼先想清楚拿到的是一套什么架子開發(fā)者在找一個(gè)企業(yè)檔案管理系統(tǒng)的可運(yùn)行源碼時(shí)手頭多半已經(jīng)壓了一個(gè)需求合同、證照、項(xiàng)目文檔要?dú)w攏Excel 管不住領(lǐng)導(dǎo)點(diǎn)名要一套系統(tǒng)。反直覺的是網(wǎng)上標(biāo)著“可運(yùn)行”的源碼解壓后能一次跑通的不到一半——數(shù)據(jù)庫(kù)腳本缺主鍵、上傳路徑寫死、登錄頁(yè)和后臺(tái)對(duì)不上這些坑幾乎人人踩過。真正的企業(yè)檔案管理系統(tǒng)核心不是頁(yè)面多華麗而是圍繞檔案生命周期把分類、權(quán)限、借閱、下載做成閉環(huán)。這套源碼適合 Java 技術(shù)棧的開發(fā)者直接拉下來改也適合把它當(dāng)作一個(gè) RBAC 加文件管理的參考架子需求來了能少走彎路。2. 技術(shù)底子Spring Boot MySQL 本地文件池為什么是這套系統(tǒng)的常見答案2.1 前后端與數(shù)據(jù)庫(kù)的常見組合為什么 Spring Boot MySQL 是默認(rèn)選項(xiàng)企業(yè)檔案系統(tǒng)跑在內(nèi)網(wǎng)服務(wù)器上一臺(tái)機(jī)器就能部署用不著微服務(wù)那套復(fù)雜體系。常見做法是 Spring Boot 單體應(yīng)用MyBatis 做數(shù)據(jù)訪問MySQL 存業(yè)務(wù)數(shù)據(jù)文件落本地磁盤。前端有兩種形態(tài)老項(xiàng)目多用 Thymeleaf 直接渲染頁(yè)面新項(xiàng)目偏向 Vue 前后端分離。選哪種要看你團(tuán)隊(duì)維護(hù)習(xí)慣而不是性能——檔案系統(tǒng)的并發(fā)量通常只有幾十人同時(shí)操作性能瓶頸根本不在這層。MySQL 在這個(gè)場(chǎng)景里夠用到什么程度檔案量在一百萬(wàn)條以內(nèi)標(biāo)題、文號(hào)、責(zé)任者這幾個(gè)字段的 LIKE 檢索加上合理索引響應(yīng)時(shí)間能壓在五百毫秒內(nèi)。企業(yè)檔案的典型量級(jí)是幾萬(wàn)到幾十萬(wàn)條MySQL 完全扛得住團(tuán)隊(duì)的 SQL 排查經(jīng)驗(yàn)也最豐富。至于文件庫(kù)為什么不上對(duì)象存儲(chǔ)很多企業(yè)檔案不允許出內(nèi)網(wǎng)業(yè)務(wù)上直接排除。本地磁盤按“年份/分類”建目錄數(shù)據(jù)庫(kù)里只記相對(duì)路徑備份時(shí)整盤打包邏輯最直白。這套技術(shù)組合的真正價(jià)值是招聘和排障成本低。Spring Boot 的 starter 機(jī)制把 Tomcat、Jackson、參數(shù)校驗(yàn)全包好了MyBatis 的 SQL 寫在 XML 里新接手的人看半天就能改。相比之下用某個(gè)冷門框架寫的檔案系統(tǒng)哪怕代碼再精巧沒人會(huì)維護(hù)就是負(fù)債。選型時(shí)記住一條檔案系統(tǒng)要的是可靠和可交接不是技術(shù)秀。2.2 檔案生命周期與權(quán)限模型四條線怎么串起來檔案系統(tǒng)和普通 CRUD 系統(tǒng)的本質(zhì)區(qū)別在于它是圍繞“狀態(tài)”和“權(quán)限”設(shè)計(jì)的。檔案生命周期一般是暫存 → 待歸檔 → 已歸檔 → 借閱中 → 已銷毀。每一步都對(duì)應(yīng)一條操作記錄誰(shuí)在什么時(shí)間把檔案從哪個(gè)狀態(tài)改到了哪個(gè)狀態(tài)必須能追溯。這對(duì)二次開發(fā)很關(guān)鍵——你往系統(tǒng)里加功能時(shí)先問自己這個(gè)操作是否改變了檔案狀態(tài)如果改了就得同步寫一條帶操作人、操作時(shí)間、操作類型的日志。權(quán)限模型用 RBAC 就夠了。用戶掛在角色下角色關(guān)聯(lián)菜單和操作權(quán)限數(shù)據(jù)權(quán)限按部門過濾。常見角色是系統(tǒng)管理員、檔案管理員、普通用戶、借閱審批人。系統(tǒng)管理員管賬號(hào)和角色檔案管理員負(fù)責(zé)歸檔和銷毀普通用戶只能檢索和發(fā)起借閱借閱審批人單獨(dú)審核借閱單。數(shù)據(jù)權(quán)限要落到部門某個(gè)分公司的員工默認(rèn)只能看到本部門歸檔的檔案除非單獨(dú)授權(quán)。核心表結(jié)構(gòu)通常是一張檔案主表加多張輔助表下面這張表是常見的設(shè)計(jì)字段名可以按自己習(xí)慣改但職責(zé)劃分大致如此。表名職責(zé)關(guān)鍵字段sys_user用戶id、姓名、部門id、狀態(tài)sys_role角色id、角色編碼、角色名sys_user_role用戶角色關(guān)聯(lián)用戶id、角色idarchive_doc檔案主表編號(hào)、題名、分類碼、密級(jí)、狀態(tài)、文件路徑archive_category檔案分類表分類碼、分類名、上級(jí)分類archive_borrow借閱記錄表檔案id、借閱人、審批人、借出時(shí)間、歸還時(shí)間archive_log操作日志表檔案id、操作人、操作類型、操作時(shí)間實(shí)際跑起來之前先花十分鐘把這幾張表的關(guān)系看懂比直接啟動(dòng)項(xiàng)目有用得多。很多“可運(yùn)行”源碼跑起來就報(bào)錯(cuò)不是因?yàn)榇a爛而是你沒建分類表的基礎(chǔ)數(shù)據(jù)或者字段字典里沒初始化狀態(tài)枚舉。下一章進(jìn)入實(shí)操?gòu)慕◣?kù)開始。3. 從解壓到登錄頁(yè)數(shù)據(jù)庫(kù)初始化與最小啟動(dòng)配置3.1 環(huán)境清單與數(shù)據(jù)庫(kù)初始化先讓 MySQL 建好核心表拿到這類源碼我一般先確認(rèn)三樣?xùn)|西JDK 版本、MySQL 版本、是否要單獨(dú)裝前端依賴。Spring Boot 2.x 對(duì)應(yīng) JDK 1.8 或 11MySQL 用 5.7 或 8.x 都行但連接串參數(shù)略有差異。如果是前后端分離版本還要 Node.js 14 以上。先看 README 或 pom.xml別上來就敲命令——見過有人拿 JDK 17 跑 Spring Boot 2.2 的老項(xiàng)目啟動(dòng)直接報(bào)非法反射警告折騰半天。數(shù)據(jù)庫(kù)初始化最容易踩的坑是字符集。建庫(kù)時(shí)必須顯式指定 utf8mb4否則 MySQL 8 默認(rèn)可能是 utf8mb4 沒問題但 MySQL 5.7 的默認(rèn)字符集可能是 latin1中文寫進(jìn)去全變問號(hào)。建庫(kù)和建表腳本一般是項(xiàng)目里 sql 目錄下的一個(gè)或幾個(gè) .sql 文件按文件名順序執(zhí)行。核心腳本里通常包含下面這類建表語(yǔ)句CREATE DATABASE IF NOT EXISTS archive_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE archive_db; CREATE TABLE archive_doc ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 主鍵, doc_no VARCHAR(40) NOT NULL COMMENT 檔案編號(hào), title VARCHAR(200) NOT NULL COMMENT 題名, category_code VARCHAR(20) NOT NULL COMMENT 分類碼, secret_level TINYINT NOT NULL DEFAULT 0 COMMENT 密級(jí):0公開,1內(nèi)部,2秘密,3機(jī)密, dept_id BIGINT NOT NULL COMMENT 歸屬部門, status TINYINT NOT NULL DEFAULT 0 COMMENT 狀態(tài):0暫存,1待歸檔,2已歸檔,3已銷毀, file_path VARCHAR(255) NULL COMMENT 文件相對(duì)路徑, uploader VARCHAR(50) NULL COMMENT 上傳人, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 創(chuàng)建時(shí)間, INDEX idx_dept_status (dept_id, status), INDEX idx_category (category_code), UNIQUE KEY uk_doc_no (doc_no) ) ENGINEInnoDB COMMENT檔案主表;這段 SQL 里有幾個(gè)地方值得注意。doc_no 加唯一鍵是因?yàn)闄n案編號(hào)在業(yè)務(wù)上必須全局唯一如果源碼里沒有這個(gè)約束后續(xù)導(dǎo)入歷史數(shù)據(jù)時(shí)會(huì)重復(fù)。idx_dept_status 是復(fù)合索引匹配“按部門查列表再按狀態(tài)過濾”這個(gè)最常見的查詢路徑。file_path 存的是相對(duì)路徑不是絕對(duì)路徑這一點(diǎn)非常重要——絕對(duì)路徑寫進(jìn)數(shù)據(jù)庫(kù)換臺(tái)機(jī)器整張表就廢了。密級(jí)和狀態(tài)都用 TINYINT 存數(shù)字不要用字符串業(yè)務(wù)上擴(kuò)展枚舉更方便。執(zhí)行導(dǎo)入命令時(shí)注意先確認(rèn) MySQL 賬號(hào)權(quán)限。常見做法是用 root 執(zhí)行 source 命令或者用 mysql 客戶端重定向文件mysql -uroot -p sql/init.sql mysql -uroot -p sql/data.sqlinit.sql 建表data.sql 導(dǎo)入基礎(chǔ)數(shù)據(jù)包括超級(jí)管理員賬號(hào)、角色、菜單和分類字典。導(dǎo)完后可以驗(yàn)證一下執(zhí)行SHOW TABLES;看表是否齊全再查一下archive_category有沒有分類數(shù)據(jù)。很多項(xiàng)目啟動(dòng)報(bào)錯(cuò)“表不存在”或“分類碼為空”都是因?yàn)橹慌芰私ū砟_本忘了跑數(shù)據(jù)腳本。日志里報(bào)的錯(cuò)往往滯后先查表再啟動(dòng)能省半小時(shí)。3.2 改配置、起服務(wù)、看日志跑通最小閉環(huán)數(shù)據(jù)庫(kù)就緒后下一步是改配置文件。Spring Boot 的配置集中在 src/main/resources/application.yml少數(shù)老項(xiàng)目是 application.properties。你需要改的通常只有三個(gè)地方數(shù)據(jù)庫(kù)連接串、文件存儲(chǔ)根目錄、端口。先給一份最小化的配置參考server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/archive_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: your_password servlet: multipart: max-file-size: 200MB max-request-size: 500MB archive: storage: # 檔案文件根目錄Linux 上建議放到 /data/archive不要丟在用戶目錄下 root-path: /data/archive數(shù)據(jù)庫(kù)連接串里有三個(gè)參數(shù)別動(dòng)useUnicodetrue 和 characterEncodingutf8 負(fù)責(zé)中文不亂碼serverTimezoneAsia/Shanghai 解決 MySQL 8 的時(shí)區(qū)報(bào)錯(cuò)。如果你用的是 MySQL 8.0 以上連接串里最好再加一個(gè)allowPublicKeyRetrievaltrue否則可能報(bào) Public Key Retrieval is not allowed。multipart 的兩個(gè)限制是上傳大掃描件用的默認(rèn) 1MB 太小傳個(gè)幾十 MB 的 PDF 直接報(bào)錯(cuò)。root-path 是本地文件池的根目錄按“年份/分類”自動(dòng)建子目錄這個(gè)目錄必須有寫權(quán)限。配置改完啟動(dòng)方式取決于項(xiàng)目形態(tài)。Maven 項(xiàng)目直接跑插件或者打包成 jar 再跑兩種都是一條命令的事# 本地開發(fā)直接跑 mvn spring-boot:run -Dspring-boot.run.profilesdev # 或者打成 jar 再跑方便放到測(cè)試服務(wù)器 mvn clean package -DskipTests java -jar target/archive-system.jar --spring.profiles.activedev啟動(dòng)成功的標(biāo)志不是控制臺(tái)不報(bào)錯(cuò)而是看到這行日志Started ArchiveApplication in 12.345 seconds。在這之前Tomcat 會(huì)先輸出Tomcat started on port(s): 8080看到這行說明 Web 容器起來了。瀏覽器訪問http://localhost:8080/login如果能出現(xiàn)登錄頁(yè)最小閉環(huán)就算跑通了。默認(rèn)賬號(hào)密碼一般在 data.sql 里常見的是 admin / admin123或者 admin / 123456去腳本里搜一下就知道。啟動(dòng)失敗最典型的三類錯(cuò)誤第一類 Access denied for user是數(shù)據(jù)庫(kù)賬號(hào)密碼不對(duì)或權(quán)限不足第二類 Unknown database是沒執(zhí)行建庫(kù)腳本第三類時(shí)區(qū)錯(cuò)誤是連接串里少了 serverTimezone。這三類在日志里都有明確關(guān)鍵字按關(guān)鍵字搜比從頭到尾讀日志快得多。如果項(xiàng)目里帶了前端目錄且要求分離部署記得先 npm install 再 npm run dev前端代理指向 8080 端口否則登錄請(qǐng)求會(huì)被 CORS 攔下來。4. 檔案業(yè)務(wù)怎么跑通錄入、檢索、借閱與下載的關(guān)鍵設(shè)計(jì)4.1 檔案錄入與分類字段設(shè)計(jì)背后的業(yè)務(wù)規(guī)則檔案錄入界面看起來是個(gè)普通表單但字段設(shè)計(jì)背后是業(yè)務(wù)規(guī)則。最核心的字段有四組標(biāo)題和文號(hào)決定檔案“叫什么”分類碼和密級(jí)決定它“歸到哪、誰(shuí)能看”保管期限決定它“留多久”文件路徑?jīng)Q定它“存到哪”。錄入時(shí)的校驗(yàn)邏輯通常是這樣標(biāo)題不能為空文號(hào)在同類檔案里不能重復(fù)密級(jí)默認(rèn)是公開但可以改保管期限默認(rèn)按分類表的配置帶出。檔案編號(hào)是錄入時(shí)自動(dòng)生成的生成規(guī)則一般是“分類碼 年份 流水號(hào)”。例如合同類的分類碼是 HT2025 年第 123 份檔案的編號(hào)就是 HT-2025-000123。這個(gè)編號(hào)生成邏輯在源碼里通常是一個(gè) Service 方法用數(shù)據(jù)庫(kù)的同一張計(jì)數(shù)表或 Redis 自增來保證并發(fā)下不重復(fù)。如果你要改編號(hào)規(guī)則別只改前端顯示要改生成邏輯——否則會(huì)出現(xiàn)界面上顯示一套編號(hào)、數(shù)據(jù)庫(kù)里另一套編號(hào)的問題。文件存儲(chǔ)路徑的設(shè)計(jì)決定了后期維護(hù)成本。常見做法是在 root-path 下按“年份/分類碼”建二級(jí)目錄比如/data/archive/2025/HT/000123.pdf。數(shù)據(jù)庫(kù)里只存相對(duì)路徑2025/HT/000123.pdf下載時(shí)再拼上 root-path。這樣做的理由是備份時(shí)只需要備份 root-path 整個(gè)目錄換機(jī)器時(shí)只改 root-path 一個(gè)配置不用動(dòng)數(shù)據(jù)庫(kù)。我見過有項(xiàng)目直接把完整路徑存進(jìn)數(shù)據(jù)庫(kù)結(jié)果測(cè)試環(huán)境路徑和生產(chǎn)環(huán)境不一致下載全部 404最后只能寫批量腳本修數(shù)據(jù)那就是給自己找罪受。密級(jí)字段是整個(gè)錄入表單里最不能忽略的。公開、內(nèi)部、秘密、機(jī)密四級(jí)對(duì)應(yīng)不同的借閱審批策略。常見做法是公開檔案直接下載內(nèi)部檔案登錄后可看但下載要記錄日志秘密及以上必須走借閱審批。這個(gè)規(guī)則要在錄入階段就定好因?yàn)闄n案一旦歸檔密級(jí)修改就要走審批流程不能像普通編輯一樣隨便改。源碼里一般有個(gè)字典表管理密級(jí)枚舉新增密級(jí)時(shí)要同步改接口校驗(yàn)邏輯和前端下拉框。4.2 全文檢索與文件下載為什么 LIKE 檢索能覆蓋九成需求檢索是整個(gè)系統(tǒng)里最常用的功能也是性能最容易翻車的地方。企業(yè)檔案的檢索需求說穿了就三類按標(biāo)題查、按文號(hào)查、按責(zé)任者或主題詞查都是模糊匹配。很多人一聽說檢索就想到 Elasticsearch但先冷靜想想數(shù)據(jù)量十萬(wàn)條檔案每個(gè)字段建好普通索引LIKE 查詢加前綴匹配響應(yīng)時(shí)間一般在幾百毫秒內(nèi)MySQL 完全能應(yīng)付。真正需要 Elasticsearch 的場(chǎng)景是檢索 PDF 和 Word 的正文內(nèi)容或者檔案量到了百萬(wàn)級(jí)以上這才值得引入全文檢索中間件。常見的做法是把檢索 SQL 寫成動(dòng)態(tài)拼接根據(jù)用戶輸入的關(guān)鍵詞決定查哪個(gè)字段。核心查詢邏輯類似下面這段SELECT id, doc_no, title, category_code, secret_level, create_time FROM archive_doc WHERE status 2 AND dept_id IN (SELECT dept_id FROM sys_user_dept WHERE user_id #{userId}) AND ( title LIKE CONCAT(%, #{keyword}, %) OR doc_no LIKE CONCAT(%, #{keyword}, %) OR finder_no LIKE CONCAT(%, #{keyword}, %) ) ORDER BY create_time DESC LIMIT #{offset}, #{pageSize};這段 SQL 里最容易被忽略的是dept_id IN (...)這個(gè)子查詢它實(shí)現(xiàn)了數(shù)據(jù)權(quán)限過濾。如果源碼里只查檔案表不查部門權(quán)限就會(huì)出現(xiàn)這樣的情況A 部門的員工搜到了 B 部門的機(jī)密檔案這在企業(yè)內(nèi)部是嚴(yán)重安全事故。LIKE 的寫法用CONCAT(%, #{keyword}, %)而不是直接拼字符串是為了防止 SQL 注入——MyBatis 的#{}會(huì)做參數(shù)預(yù)編譯而${}是直接拼接檢索這種用戶輸入場(chǎng)景永遠(yuǎn)別用${}。下載接口的設(shè)計(jì)要比檢索更小心。常規(guī)流程是前端請(qǐng)求下載接口 → 后端校驗(yàn)登錄態(tài) → 校驗(yàn)數(shù)據(jù)權(quán)限 → 拼文件絕對(duì)路徑 → 檢查文件存在 → 以流的方式返回。這里有一個(gè)很多源碼都會(huì)犯的錯(cuò)校驗(yàn)了登錄態(tài)但沒校驗(yàn)數(shù)據(jù)權(quán)限結(jié)果任何登錄用戶都能下任何檔案。正確的校驗(yàn)順序是先權(quán)限后文件寧可多查一次數(shù)據(jù)庫(kù)也不要讓越權(quán)文件流出去。文件讀取用InputStreamResource而不是byte[]因?yàn)榇笪募苯幼x入內(nèi)存幾百 MB 的文件能把 JVM 堆撐爆。5. 可運(yùn)行源碼避坑數(shù)據(jù)庫(kù)、路徑與權(quán)限的三個(gè)硬骨頭5.1 坑一數(shù)據(jù)庫(kù)腳本少跑一遍字符集與時(shí)區(qū)導(dǎo)致啟動(dòng)即崩現(xiàn)象按照 README 導(dǎo)入數(shù)據(jù)庫(kù)后啟動(dòng)項(xiàng)目控制臺(tái)報(bào)Unknown database或者能啟動(dòng)但插入中文檔案標(biāo)題后顯示為“???”時(shí)間字段比本地時(shí)間差八小時(shí)。原因建庫(kù)時(shí)沒執(zhí)行CREATE DATABASE語(yǔ)句只導(dǎo)了建表腳本——MySQL 里沒這個(gè)庫(kù)連接自然失敗。中文亂碼是庫(kù)或表的默認(rèn)字符集不在 utf8mb4常見于 MySQL 5.7 默認(rèn) latin1 的老環(huán)境。時(shí)間差八小時(shí)是連接串里少了serverTimezoneAsia/ShanghaiMySQL 8 默認(rèn)用 UTC 解析時(shí)間。解決建庫(kù)和建表是兩件事先執(zhí)行帶CREATE DATABASE的 init.sql再執(zhí)行建表腳本最后導(dǎo)基礎(chǔ)數(shù)據(jù)。字符集問題用ALTER DATABASE archive_db CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;修改如果表已經(jīng)建好再把表的字符集也改掉。連接串三個(gè)參數(shù)一個(gè)都不能少characterEncodingutf8、serverTimezoneAsia/Shanghai、useSSLfalse最后那個(gè)參數(shù)在測(cè)試環(huán)境不加會(huì)報(bào) SSL 警告雖然不影響啟動(dòng)但日志里一大片很煩。5.2 坑二上傳路徑寫死換臺(tái)機(jī)器全部文件找不到現(xiàn)象在本地開發(fā)時(shí)上傳的檔案部署到服務(wù)器后全部下載失敗日志報(bào)FileNotFoundException但數(shù)據(jù)庫(kù)里的檔案記錄一條沒少。原因源碼配置或代碼里把文件存儲(chǔ)路徑寫死了比如D:\\upload\\archive或/home/ubuntu/upload這個(gè)路徑只存在于開發(fā)機(jī)生產(chǎn)服務(wù)器上根本沒有這個(gè)目錄或者沒有寫權(quán)限。數(shù)據(jù)庫(kù)里存的是絕對(duì)路徑換機(jī)器后路徑前綴全部失效。解決把存儲(chǔ)根目錄抽成配置項(xiàng)用環(huán)境變量注入。application.yml里這樣寫root-path: ${ARCHIVE_ROOT:/data/archive}。部署時(shí)在啟動(dòng)腳本里export ARCHIVE_ROOT/data/archive如果環(huán)境變量沒配就回退到默認(rèn)值。同時(shí)數(shù)據(jù)庫(kù)存儲(chǔ)邏輯要改成只存root-path下的相對(duì)路徑下載時(shí)用Paths.get(storageRoot).resolve(relativePath)拼出完整路徑。改完配置后記得把已上傳的文件按新目錄結(jié)構(gòu)遷移一次舊數(shù)據(jù)跑個(gè)腳本改 path 前綴或者寫一個(gè)兼容邏輯自動(dòng)拼接。5.3 坑三下載接口繞過權(quán)限校驗(yàn)機(jī)密檔案被直接拿走現(xiàn)象未登錄狀態(tài)下訪問下載接口的完整 URL比如/archive/download?id108竟然能直接把文件下載下來。登錄用戶把鏈接發(fā)給別人別人點(diǎn)開也能下。原因下載接口只校驗(yàn)了文件是否存在沒有校驗(yàn)當(dāng)前請(qǐng)求是否攜帶合法登錄態(tài)。常見寫法是直接用GetMapping(/download/{id})參數(shù)只有檔案 id方法體里文件存在就返回文件流——但沒從 Session 或 Token 里取當(dāng)前用戶。這種接口在企業(yè)內(nèi)網(wǎng)里尤其危險(xiǎn)因?yàn)殒溄右坏┍晦D(zhuǎn)發(fā)等于把檔案原文直接暴露。解決下載接口必須同時(shí)校驗(yàn)登錄態(tài)和數(shù)據(jù)權(quán)限缺一不可。核心邏輯參考下面這段GetMapping(/download/{id}) public ResponseEntityResource download(PathVariable Long id) { ArchiveDoc doc archiveDocMapper.selectById(id); if (doc null || !permissionService.canDownload(getLoginUser(), doc)) { return ResponseEntity.status(403).build(); } Path file Paths.get(storageRoot).resolve(doc.getFilePath()).normalize(); if (!file.startsWith(Paths.get(storageRoot))) { return ResponseEntity.status(400).build(); } return ResponseEntity.ok() .header(HttpHeaders.CONTENT_DISPOSITION, attachment; filename\ doc.getTitle() \) .body(new InputStreamResource(Files.newInputStream(file))); }這段代碼里有兩個(gè)關(guān)鍵點(diǎn)。canDownload方法內(nèi)部校驗(yàn)用戶是否登錄、檔案密級(jí)是否超過用戶權(quán)限、檔案部門是否在用戶的數(shù)據(jù)權(quán)限范圍內(nèi)。file.startsWith(Paths.get(storageRoot))是防路徑穿越——如果數(shù)據(jù)庫(kù)里的相對(duì)路徑被人改成../../etc/passwd這個(gè)校驗(yàn)?zāi)軘r下來。文件流用InputStreamResource包裝避免大文件吃滿內(nèi)存。改完后自測(cè)一遍退出登錄訪問下載接口應(yīng)該返回 403登錄后下載不屬于本部門的秘密檔案也應(yīng)該返回 403。5.4 坑四大文件上傳超時(shí)與文件句柄泄漏現(xiàn)象上傳 100MB 以上的掃描件時(shí)前端請(qǐng)求轉(zhuǎn)圈幾分鐘后報(bào)錯(cuò)或者上傳成功后下載時(shí)提示文件被占用。服務(wù)器日志里出現(xiàn)Connection reset或Too many open files。原因multipart 限制沒調(diào)大是第一個(gè)原因Spring Boot 默認(rèn)單文件最大 1MB超過直接拒絕。第二個(gè)原因是文件讀寫方式不對(duì)——上傳時(shí)把整個(gè)文件讀入 byte[] 再寫盤大文件直接把內(nèi)存撐爆下載時(shí)用FileInputStream讀完沒關(guān)流時(shí)間長(zhǎng)了文件句柄耗盡。解決先調(diào)大 multipart 限制max-file-size按業(yè)務(wù)實(shí)際需要來一般掃描件建議 200MBmax-request-size要比單文件略大。讀寫文件統(tǒng)一用流式處理上傳用MultipartFile.transferTo()避免內(nèi)存拷貝下載用InputStreamResource。上傳大文件時(shí)前端請(qǐng)求時(shí)間可能超過 Nginx 默認(rèn)的 60 秒代理超時(shí)如果帶了 Nginx 前置proxy_read_timeout也要相應(yīng)調(diào)大。文件句柄問題用lsof -p pid | wc -l排查如果數(shù)量持續(xù)上漲不回落優(yōu)先檢查自己代碼里有沒有忘記 close。6. 從可運(yùn)行到可上線環(huán)境變量、備份與二次開發(fā)的收尾習(xí)慣6.1 把配置拆成環(huán)境相關(guān)與環(huán)境無關(guān)上線前先做一次部署演練可運(yùn)行源碼只代表它能跑不代表它能上線。我交付這類系統(tǒng)前會(huì)強(qiáng)制自己做一次部署演練找一臺(tái)干凈服務(wù)器從零裝 JDK、MySQL再用一條啟動(dòng)命令把系統(tǒng)拉起來。如果過程中要改三個(gè)以上配置文件說明配置設(shè)計(jì)不合格。密碼、數(shù)據(jù)庫(kù)地址、存儲(chǔ)路徑這些環(huán)境相關(guān)變量一律用${ENV_VAR}占位代碼里不要出現(xiàn)任何硬編碼。6.2 每日備份腳本與清理策略給系統(tǒng)留一條后悔藥檔案系統(tǒng)的數(shù)據(jù)比代碼值錢。代碼丟了可以重新拉倉(cāng)庫(kù)檔案文件和數(shù)據(jù)庫(kù)丟了就是事故。我一般會(huì)在交付時(shí)附帶一個(gè)備份腳本放到 cron 里每日凌晨執(zhí)行#!/bin/bash # 每日凌晨備份檔案庫(kù)與文件目錄保留最近 30 天 BACKUP_ROOT/backup/archive DATE$(date %Y%m%d_%H%M%S) mkdir -p $BACKUP_ROOT/$DATE mysqldump -uroot -p$DB_PASS archive_db | gzip $BACKUP_ROOT/$DATE/db.sql.gz tar czf $BACKUP_ROOT/$DATE/files.tar.gz -C /data/archive . # 清理 30 天前的備份防止磁盤被撐爆 find $BACKUP_ROOT -type d -mtime 30 -exec rm -rf {} \;這個(gè)腳本里有兩個(gè)關(guān)鍵點(diǎn)。mysqldump 一定要加--single-transaction否則備份期間業(yè)務(wù)寫入會(huì)導(dǎo)致數(shù)據(jù)不一致——腳本里沒寫但你實(shí)際部署時(shí)建議加上。find 清理要用-mtime 30意思是修改時(shí)間超過 30 天的目錄千萬(wàn)不要用-atime因?yàn)閭浞菸募脑L問時(shí)間經(jīng)常被各種巡檢腳本修改容易誤刪。備份頻率按數(shù)據(jù)變更強(qiáng)度來檔案系統(tǒng)一天新增幾百條記錄以內(nèi)每日一次足夠不用做實(shí)時(shí)備份。至于二次開發(fā)我養(yǎng)成了一個(gè)習(xí)慣加需求時(shí)先問自己改的是“基礎(chǔ)數(shù)據(jù)”還是“流程數(shù)據(jù)”。新增字典項(xiàng)、分類、菜單屬于基礎(chǔ)數(shù)據(jù)直接改數(shù)據(jù)庫(kù)或管理界面就行。改動(dòng)檔案狀態(tài)流轉(zhuǎn)、借閱審批、權(quán)限校驗(yàn)屬于流程邏輯必須先理清影響范圍再動(dòng)代碼。歸檔后的檔案表結(jié)構(gòu)能加字段就別改字段類型——比如把 title 從 VARCHAR(200) 改成 VARCHAR(500)MySQL 8 里會(huì)導(dǎo)致全表重建幾十萬(wàn)條數(shù)據(jù)的表鎖住幾個(gè)鐘頭業(yè)務(wù)直接停擺。線上出過一次這種事之后凡是檔案表的 DDL我都先在測(cè)試庫(kù)跑一遍看影響行數(shù)。檔案系統(tǒng)的技術(shù)含量不在高并發(fā)、不在炫技而在數(shù)據(jù)準(zhǔn)確和權(quán)限嚴(yán)密。你照著這套思路把一個(gè)可運(yùn)行源碼跑通、部署、備份起來就已經(jīng)超過了大部分停留在“能啟動(dòng)就算完事”的開發(fā)者。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取