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