最近幫朋友調(diào)試一套基于Java的知識(shí)產(chǎn)權(quán)管理系統(tǒng)忙活了兩天把里面的坑和設(shè)計(jì)思路都捋了一遍。突然覺(jué)得這套東西值得單獨(dú)寫(xiě)一篇因?yàn)橹R(shí)產(chǎn)權(quán)管理系統(tǒng)在平時(shí)項(xiàng)目里不算高頻但真要做起來(lái)涉及流程、期限、費(fèi)用、權(quán)限這些亂七八糟的模塊比一般的管理系統(tǒng)要復(fù)雜不少。特別是畢設(shè)或者小公司想快速落地的時(shí)候很多人拿到一整套源碼加論文加調(diào)試文檔卻不知道怎么消化、怎么二次開(kāi)發(fā)。這篇博客就基于這套典型的JavaSpringBootSSM知識(shí)產(chǎn)權(quán)管理系統(tǒng)講講我從拿到項(xiàng)目到跑通、再到梳理模塊邏輯的整個(gè)過(guò)程。包括技術(shù)棧怎么理解、數(shù)據(jù)庫(kù)為什么要這么設(shè)計(jì)、核心接口怎么實(shí)現(xiàn)、部署調(diào)試會(huì)遇到哪些典型的坑我會(huì)盡量把這些年的實(shí)操經(jīng)驗(yàn)揉進(jìn)去?？赡苣闶稚险郎?zhǔn)備做相似的系統(tǒng)設(shè)計(jì)也可能你是剛拿到畢設(shè)項(xiàng)目不知道怎么下手看完這篇應(yīng)該能少走很多彎路。先說(shuō)清楚這套系統(tǒng)解決的核心問(wèn)題知識(shí)產(chǎn)權(quán)管理狹義上管的是專(zhuān)利、商標(biāo)、著作權(quán)軟著、集成電路布圖這幾類(lèi)知識(shí)產(chǎn)權(quán)的全生命周期從提案、申請(qǐng)、審查、授權(quán)/駁回到年費(fèi)管理、官文歸檔、期限監(jiān)控。廣義上還會(huì)延伸到知識(shí)產(chǎn)權(quán)評(píng)估、交易、訴訟等。這套題目里的管理系統(tǒng)走的還是標(biāo)準(zhǔn)的企業(yè)內(nèi)部信息化路線重點(diǎn)在流程審批、臺(tái)賬管理、期限提醒、統(tǒng)計(jì)報(bào)表。1. 先厘清標(biāo)題里的技術(shù)棧SpringBoot與SSM到底是什么關(guān)系項(xiàng)目標(biāo)題同時(shí)寫(xiě)了JavaSpringBootSSM這種寫(xiě)法在畢設(shè)題目和企業(yè)項(xiàng)目招標(biāo)里經(jīng)常出現(xiàn)看起來(lái)是一套技術(shù)棧實(shí)際上這里有一個(gè)容易混淆的點(diǎn)。SSM是SpringSpringMVCMyBatis的組合SpringBoot本身只是對(duì)Spring生態(tài)的自動(dòng)化配置封裝它并不排斥SpringMVC和MyBatis。1.1 兩套寫(xiě)法出現(xiàn)的實(shí)際原因我在市面上見(jiàn)到的大多數(shù)同類(lèi)畢設(shè)項(xiàng)目實(shí)際上是用SpringBootMyBatis搭建的但仍沿用“SSM”這個(gè)稱(chēng)呼。原因是很多高校課程大綱和題目庫(kù)里SSM還是默認(rèn)的技術(shù)標(biāo)簽學(xué)生答辯的時(shí)候也更習(xí)慣說(shuō)自己用的是SpringSpringMVCMyBatis體系。而SpringBoot只是把Spring的XML配置改成了自動(dòng)裝配和注解驅(qū)動(dòng)。上一套源碼調(diào)試時(shí)我第一件事就是去看pom.xml依賴(lài)確定底層是SpringBoot 2.x還是Spring Boot 3.x因?yàn)閮烧叩膉avax和jakarta命名空間不一樣不少直接抄代碼的人會(huì)在這里翻車(chē)。這套系統(tǒng)跑的是SpringBoot 2.7.xJDK 1.811都沒(méi)問(wèn)題如果用JDK 17以上需要額外處理一些反射和模塊訪問(wèn)限制。1.2 Controller-Service-Mapper三層各自的職責(zé)SSM體系的項(xiàng)目代碼結(jié)構(gòu)一定逃不開(kāi)Controller、Service、Mapper三層。很多同學(xué)剛開(kāi)始寫(xiě)的時(shí)候都會(huì)困惑到底什么邏輯放Controller什么放Service什么直接寫(xiě)在Mapper的XML里。以這套知識(shí)產(chǎn)權(quán)管理系統(tǒng)為例我建議的劃分方式是Controller層只做參數(shù)接收、校驗(yàn)、會(huì)話獲取、響應(yīng)封裝不寫(xiě)業(yè)務(wù)判斷。Service層處理業(yè)務(wù)規(guī)則例如審核狀態(tài)的流轉(zhuǎn)、期限計(jì)算的調(diào)用、費(fèi)用狀態(tài)的聯(lián)動(dòng)。Mapper層負(fù)責(zé)SQL操作連表查詢(xún)復(fù)雜的話寫(xiě)在XML里簡(jiǎn)單操作可以用注解或者M(jìn)yBatis-Plus的Wrapper。舉例來(lái)說(shuō)新增一個(gè)專(zhuān)利申請(qǐng)?zhí)岚傅臅r(shí)候Controller里只負(fù)責(zé)接收前端傳過(guò)來(lái)的申請(qǐng)人信息、技術(shù)交底書(shū)編號(hào)、代理機(jī)構(gòu)等Service層要做的事包括校驗(yàn)專(zhuān)利名稱(chēng)是否重復(fù)、創(chuàng)建申請(qǐng)單主記錄、初始化流程狀態(tài)為“待審核”、插入一條操作日志Mapper層只是把數(shù)據(jù)持久化。如果你把校驗(yàn)和日志邏輯都堆在Controller里代碼會(huì)亂成一片后面想加“同一天同一發(fā)明人只能提交五件提案”這種復(fù)雜規(guī)則時(shí)就特別痛苦。這套系統(tǒng)在分層上做得比較標(biāo)準(zhǔn)我拿到手后基本沒(méi)有大改。真正花時(shí)間的是搞清楚它的權(quán)限模型。2. 功能模塊拆解知識(shí)產(chǎn)權(quán)管理系統(tǒng)到底管些什么很多人以為知識(shí)產(chǎn)權(quán)管理系統(tǒng)就是給專(zhuān)利做個(gè)登記表格實(shí)際上要管的東西遠(yuǎn)比想象中多。只有先把模塊邊界畫(huà)清楚才能理解源碼里那些表為什么長(zhǎng)那樣也才能在論文里寫(xiě)清楚“系統(tǒng)需求分析”。2.1 基礎(chǔ)數(shù)據(jù)與人員組織管理系統(tǒng)底層一定有一個(gè)組織架構(gòu)和用戶體系。常見(jiàn)的設(shè)計(jì)是用戶表、角色表、部門(mén)表、權(quán)限表以及用戶角色關(guān)聯(lián)、角色權(quán)限關(guān)聯(lián)這兩張中間表。這套系統(tǒng)采用的是RBAC基于角色的訪問(wèn)控制模型即用戶不直接綁權(quán)限而是綁角色角色綁權(quán)限。這樣做的好處是權(quán)限調(diào)整只動(dòng)角色。在企業(yè)真實(shí)場(chǎng)景里知識(shí)產(chǎn)權(quán)部門(mén)通常有這幾個(gè)角色普通員工發(fā)明人/提案人、IP管理員流程管理人、部門(mén)主管審批人、高管查看統(tǒng)計(jì)。系統(tǒng)初始化的時(shí)候一般會(huì)內(nèi)置admin超級(jí)管理員用于創(chuàng)建角色和分配權(quán)限。這些角色對(duì)應(yīng)的菜單權(quán)限、按鈕權(quán)限分別存在菜單表和權(quán)限字表里。2.2 申請(qǐng)流程管理從提案到授權(quán)知識(shí)產(chǎn)權(quán)管理的核心流程大致是這樣的發(fā)明人提交技術(shù)交底書(shū)或商標(biāo)設(shè)計(jì)稿經(jīng)過(guò)部門(mén)審核判斷是否有申請(qǐng)價(jià)值通過(guò)后交給代理機(jī)構(gòu)或直接向官方提交申請(qǐng)然后跟蹤審查意見(jiàn)、答復(fù)、授權(quán)/駁回最后歸檔獲取證書(shū)編號(hào)。這套系統(tǒng)的流程表設(shè)計(jì)把“主表狀態(tài)機(jī)”結(jié)合起來(lái)。主表記錄知識(shí)產(chǎn)權(quán)的基本信息比如申請(qǐng)?zhí)?、名稱(chēng)、類(lèi)型、申請(qǐng)日、申請(qǐng)人每次流程節(jié)點(diǎn)變更會(huì)在流程記錄表里追加一條軌跡。這樣做的好處是保留了完整的審核痕跡方便后續(xù)追溯。流程狀態(tài)字段一般用數(shù)字0/1/2/3或者英文枚舉去表示在界面上再映射成中文。我見(jiàn)過(guò)很多半成品的項(xiàng)目把流程狀態(tài)直接用String類(lèi)型存“已提交”“審核中”“已授權(quán)”這種做法的缺點(diǎn)是寫(xiě)錯(cuò)一個(gè)字查詢(xún)就查不到而且改狀態(tài)文案時(shí)還得改歷史數(shù)據(jù)。正確的做法是存狀態(tài)編碼頁(yè)面展示時(shí)做翻譯。這套系統(tǒng)用的是Integer類(lèi)型的狀態(tài)編碼這點(diǎn)我很認(rèn)可。2.3 官文、年費(fèi)與期限監(jiān)控知識(shí)產(chǎn)權(quán)管理跟普通項(xiàng)目最大的區(qū)別就是它有嚴(yán)格的法定期限。專(zhuān)利年費(fèi)要按時(shí)繳納商標(biāo)到期要續(xù)展軟著沒(méi)有年費(fèi)但也有審查意見(jiàn)答復(fù)期限。逾期會(huì)導(dǎo)致權(quán)利喪失這是真金白銀的損失所以期限模塊必須獨(dú)立設(shè)計(jì)。這個(gè)系統(tǒng)的期限臺(tái)賬做得比較完整每一條知識(shí)產(chǎn)權(quán)記錄都關(guān)聯(lián)若干期限事件每個(gè)事件包括事件類(lèi)型、到期日、提醒狀態(tài)、處理結(jié)果。同時(shí)配套了年費(fèi)管理模塊按年度生成應(yīng)繳費(fèi)用、實(shí)繳金額、繳費(fèi)日期。還有一個(gè)官方文件管理模塊用來(lái)存儲(chǔ)受理通知書(shū)、授權(quán)通知書(shū)、審查意見(jiàn)通知書(shū)等掃描件方便調(diào)閱。2.4 統(tǒng)計(jì)報(bào)表與儀表盤(pán)報(bào)表不是核心業(yè)務(wù)但答辯和實(shí)際使用都離不開(kāi)它。這套系統(tǒng)做了按類(lèi)型統(tǒng)計(jì)專(zhuān)利、商標(biāo)、軟著、按狀態(tài)統(tǒng)計(jì)申請(qǐng)中、已授權(quán)、已失效、按部門(mén)統(tǒng)計(jì)各部門(mén)提案量對(duì)比、按期繳納統(tǒng)計(jì)年費(fèi)繳納及時(shí)率。圖表用的是ECharts后端提供JSON格式的數(shù)據(jù)接口前端渲染。我在實(shí)際調(diào)試中發(fā)現(xiàn)報(bào)表模塊最容易出的問(wèn)題是聚合SQL寫(xiě)不對(duì)。比如統(tǒng)計(jì)“各部門(mén)有效專(zhuān)利數(shù)量”必須關(guān)聯(lián)知識(shí)產(chǎn)權(quán)表、部門(mén)表、狀態(tài)表還要過(guò)濾“已失效”狀態(tài)和“法律狀態(tài)為授權(quán)”的記錄。這種SQL建議先單獨(dú)在數(shù)據(jù)庫(kù)客戶端里跑通再貼到Mapper的XML里不要直接在代碼里拼字符串。3. 數(shù)據(jù)庫(kù)設(shè)計(jì)核心表結(jié)構(gòu)與字段選擇的取舍源碼里帶了完整的SQL腳本但我拿到后并沒(méi)有直接執(zhí)行而是先花了半小時(shí)把表梳理了一遍。數(shù)據(jù)庫(kù)是MySQL 8.0字符集用了utf8mb4這個(gè)細(xì)節(jié)很關(guān)鍵否則存不了生僻字和特殊符號(hào)。下面說(shuō)的這些表結(jié)構(gòu)就是這套系統(tǒng)的核心骨架。3.1 主表知識(shí)產(chǎn)權(quán)信息表主表字段大概有主鍵id、類(lèi)型1專(zhuān)利/2商標(biāo)/3軟著、名稱(chēng)、申請(qǐng)?zhí)?、申?qǐng)日、申請(qǐng)人、發(fā)明人、代理機(jī)構(gòu)、官方狀態(tài)、內(nèi)部狀態(tài)、證書(shū)編號(hào)、法律狀態(tài)、備注、創(chuàng)建時(shí)間、更新時(shí)間。其中申請(qǐng)?zhí)栆鑫ㄒ凰饕驗(yàn)橥患暾?qǐng)不應(yīng)該被重復(fù)錄入。這里有個(gè)容易踩的坑申請(qǐng)?zhí)栐诠俜较到y(tǒng)里可能有“CN”“ZL”等前綴不同國(guó)家格式不一樣甚至有時(shí)候錄入人員會(huì)不小心帶上空格。所以入庫(kù)前必須做字符串清洗要么統(tǒng)一去掉前綴只存數(shù)字要么統(tǒng)一規(guī)范格式否則后續(xù)查重和接口對(duì)接都會(huì)出問(wèn)題。這套系統(tǒng)選擇了保留完整申請(qǐng)?zhí)柊亚逑匆?guī)則寫(xiě)在了Service層雖然邏輯簡(jiǎn)單但很實(shí)用。3.2 流程記錄表的設(shè)計(jì)原則流程記錄表是知識(shí)產(chǎn)權(quán)的“操作日志”字段包括流程id、知識(shí)產(chǎn)權(quán)主表id、動(dòng)作提交提案、部門(mén)審核、代理機(jī)構(gòu)接收、提交申請(qǐng)、答復(fù)審查意見(jiàn)、授權(quán)歸檔、操作人、操作時(shí)間、審批意見(jiàn)、附件地址。設(shè)計(jì)這張表時(shí)要注意不要?jiǎng)h數(shù)據(jù)只增不改。哪怕操作人填錯(cuò)了也應(yīng)該通過(guò)“更正”動(dòng)作再追加一條記錄而不是直接改原記錄。這是合規(guī)審計(jì)的要求你在論文里把這個(gè)解釋清楚答辯時(shí)屬于加分項(xiàng)。這套系統(tǒng)沒(méi)做物理刪除只在界面上隱藏了“刪除”按鈕思路是對(duì)的。3.3 狀態(tài)字段取值的陷阱Integer還是String前面已經(jīng)提過(guò)狀態(tài)值建議用編碼。這里我補(bǔ)充一個(gè)更具體的例子。把知識(shí)產(chǎn)權(quán)狀態(tài)從立案到授權(quán)拆成10個(gè)以?xún)?nèi)的節(jié)點(diǎn)例如0-草稿箱1-待部門(mén)審核2-待代理機(jī)構(gòu)處理3-已提交官方4-審查中5-已授權(quán)6-已駁回7-已失效8-已撤回。每個(gè)節(jié)點(diǎn)對(duì)應(yīng)一個(gè)界面按鈕比如狀態(tài)為“已提交官方”時(shí)顯示“答復(fù)審查意見(jiàn)”按鈕狀態(tài)為“已授權(quán)”時(shí)顯示“登記證書(shū)編號(hào)”按鈕。如果你給每個(gè)狀態(tài)都配一個(gè)“前端能否點(diǎn)擊”的布爾字段也能實(shí)現(xiàn)但會(huì)非常麻煩。更簡(jiǎn)潔的是在后端Service里寫(xiě)狀態(tài)流轉(zhuǎn)規(guī)則不滿足條件的直接拋異常。這個(gè)系統(tǒng)的做法順應(yīng)了行業(yè)習(xí)慣狀態(tài)機(jī)邏輯在代碼里清晰可見(jiàn)。3.4 日期字段與費(fèi)單體日期字段建議統(tǒng)一用date或datetime類(lèi)型不要為了圖方便用varchar存字符串。因?yàn)楹竺嬉銎谙抻?jì)算字符串日期做差值運(yùn)算非常痛苦還得反復(fù)轉(zhuǎn)換。年費(fèi)表要包含費(fèi)用所屬年度、應(yīng)繳日期、金額、狀態(tài)0未繳/1已繳/2減免。每件專(zhuān)利的有效期是20年這意味著系統(tǒng)要能自動(dòng)生成未來(lái)20年的應(yīng)繳記錄不能靠人工一條條錄入。這里我特別提一下“期限計(jì)算”的算法發(fā)明專(zhuān)利年費(fèi)從申請(qǐng)日起算第1-3年為一個(gè)維護(hù)期第4-6年為下一個(gè)維護(hù)期……每個(gè)階段的年費(fèi)金額不一樣。系統(tǒng)里通常不是按日歷年的1月1日計(jì)算而是按申請(qǐng)日周年計(jì)算。如果不理解這個(gè)規(guī)則代碼里寫(xiě)出來(lái)的“到期日”會(huì)和企業(yè)代理機(jī)構(gòu)計(jì)算的對(duì)不上。源碼里專(zhuān)門(mén)有一個(gè)年費(fèi)計(jì)算工具類(lèi)輸入申請(qǐng)日和當(dāng)前年份輸出應(yīng)繳金額和截止日期我在調(diào)試時(shí)就借用它跑通了整套測(cè)試數(shù)據(jù)。4. 編碼實(shí)戰(zhàn)基于SpringBoot實(shí)現(xiàn)幾個(gè)核心接口源碼已經(jīng)整體可運(yùn)行但看源碼和真正動(dòng)手改是兩碼事。我挑了幾個(gè)有代表性的環(huán)節(jié)給大家拆解一下具體實(shí)現(xiàn)方式以及代碼背后為什么要這么寫(xiě)。4.1 登錄鑒權(quán)和用戶角色處理登錄這塊用的是SpringSecurityJWT的方案。用戶登錄成功后后端生成一個(gè)帶有用戶id和角色信息的JWT令牌前端把令牌存在本地存儲(chǔ)里每次請(qǐng)求在Header里帶上“Authorization: Bearer xxxxxx”。SpringSecurity的過(guò)濾器鏈攔截所有/api/**請(qǐng)求解析令牌把用戶身份塞進(jìn)SecurityContext里。然后通過(guò)PreAuthorize(hasRole(ADMIN))這種注解控制接口權(quán)限。這套方案的好處是前后端分離項(xiàng)目里服務(wù)端不需要維護(hù)Session擴(kuò)展性和跨域部署都方便。壞處是JWT令牌一旦簽發(fā)無(wú)法在服務(wù)端主動(dòng)注銷(xiāo)所以要在Redis里存一個(gè)黑名單或者維護(hù)在線狀態(tài)。這套源碼用了Redis做令牌狀態(tài)管理算是一個(gè)不錯(cuò)的進(jìn)階設(shè)計(jì)。如果你用的是老的SSM單體架構(gòu)前后端不分離頁(yè)面由服務(wù)端渲染用SessionCookie的方式會(huì)更簡(jiǎn)單。但如果你按現(xiàn)在很多畢設(shè)的標(biāo)準(zhǔn)做法Vue前端SpringBoot后端那JWT是更通用的選擇。這兩者的區(qū)別建議在論文的前言里描述一下作為技術(shù)選型的依據(jù)。4.2 申請(qǐng)單提交用Java Record簡(jiǎn)化實(shí)體類(lèi)JDK 16支持了Record語(yǔ)法用來(lái)寫(xiě)只承載數(shù)據(jù)的DTO非常舒服。比如前端提交一件專(zhuān)利申請(qǐng)時(shí)后端接收參數(shù)的類(lèi)可以寫(xiě)成public record PatentApplyRequest( String patentName, String applicant, String inventor, String techDescription, String agency, String departmentId ) {}相比傳統(tǒng)的getter/setter類(lèi)Record自動(dòng)生成了equals、hashCode、toString代碼量少了一大截。Controller直接把它作為RequestBody接收后續(xù)轉(zhuǎn)成實(shí)體類(lèi)再調(diào)用Service保存。這個(gè)寫(xiě)法在JDK 8的老項(xiàng)目里沒(méi)法用但如果是SpringBoot 2.7加JDK 17以上完全可以直接上。提交提案對(duì)應(yīng)的Service方法我簡(jiǎn)化后是這樣Transactional public Long submitPatentApplication(PatentApplyRequest request) { Patent patent new Patent(); patent.setName(request.patentName()); patent.setApplicant(request.applicant()); patent.setInventor(request.inventor()); patent.setStatus(1); // 待部門(mén)審核 patentMapper.insert(patent); PatentFlow flow new PatentFlow(); flow.setPatentId(patent.getId()); flow.setAction(提交提案); flow.setOperator(SecurityUtil.getCurrentUserId()); patentFlowMapper.insert(flow); return patent.getId(); }Transactional注解必不可少因?yàn)橐瑫r(shí)插入主表和流程記錄表要么都成功要么都回滾。很多新手寫(xiě)業(yè)務(wù)邏輯時(shí)容易漏掉事務(wù)導(dǎo)致主表插入成功、日志插入失敗后數(shù)據(jù)對(duì)不上。4.3 年費(fèi)計(jì)算后補(bǔ)費(fèi)期的算法邏輯年費(fèi)計(jì)算的算法是整個(gè)知識(shí)產(chǎn)權(quán)系統(tǒng)里最“含金量”的部分。專(zhuān)利法規(guī)定年費(fèi)應(yīng)當(dāng)在上一年度期滿前繳納過(guò)期有六個(gè)月寬限期寬限期后還沒(méi)繳的專(zhuān)利權(quán)終止。系統(tǒng)里要能算出“當(dāng)前需要繳納幾次年費(fèi)”“每筆對(duì)應(yīng)的應(yīng)繳日和金額”。核心算法思路是把一件專(zhuān)利的申請(qǐng)日作為起點(diǎn)計(jì)算出第幾年度的年費(fèi)。例如申請(qǐng)日是2024年6月30日那么第1年年費(fèi)期間是2024年6月30日到2025年6月29日第2年是2025年6月30日到2026年6月29日。落在當(dāng)前日歷年的年費(fèi)賬單就是需要提醒繳納的。源碼里用了一個(gè)Map存儲(chǔ)年費(fèi)標(biāo)準(zhǔn)檔位代碼類(lèi)似這樣private static final MapInteger, BigDecimal ANNUAL_FEE_STANDARD new HashMap(); static { ANNUAL_FEE_STANDARD.put(1, new BigDecimal(900)); ANNUAL_FEE_STANDARD.put(2, new BigDecimal(900)); ANNUAL_FEE_STANDARD.put(3, new BigDecimal(900)); ANNUAL_FEE_STANDARD.put(4, new BigDecimal(1200)); ANNUAL_FEE_STANDARD.put(5, new BigDecimal(1200)); // 更長(zhǎng)的年限按規(guī)則遞增這里只列部分示例 }實(shí)際項(xiàng)目建議把年費(fèi)標(biāo)準(zhǔn)放到數(shù)據(jù)庫(kù)表里這樣官費(fèi)調(diào)整時(shí)不需要改代碼只要改一張配置表。源碼把部分檔位寫(xiě)死在類(lèi)里只能說(shuō)滿足演示需求真要落地還是得挪到庫(kù)里。如果你做二次開(kāi)發(fā)這一步建議優(yōu)先改掉。4.4 統(tǒng)一異常處理與日志這套系統(tǒng)的全局異常處理用的是Spring的RestControllerAdvice自定義了一個(gè)BusinessException業(yè)務(wù)校驗(yàn)失敗時(shí)拋出異常統(tǒng)一捕獲后返回結(jié)構(gòu)化的響應(yīng)體。比如申請(qǐng)?zhí)栔貜?fù)時(shí)Service里直接throw new BusinessException(申請(qǐng)?zhí)栆汛嬖?前端彈出提示不需要每個(gè)Controller都寫(xiě)try-catch。日志用SLF4JLogback這個(gè)組合幾乎成了Java Web項(xiàng)目的標(biāo)配。要注意的是日志里不要打印用戶的敏感信息比如密碼明文。這套系統(tǒng)用戶表存的是BCrypt加密后的密碼登錄時(shí)用BCryptPasswordEncoder做校驗(yàn)即使數(shù)據(jù)庫(kù)泄露了短時(shí)間內(nèi)也不會(huì)暴露明文這個(gè)安全意識(shí)值得保留。5. 調(diào)試與部署把完整項(xiàng)目跑起來(lái)的全過(guò)程拿到源碼后大家都想盡快看到界面但直接雙擊運(yùn)行往往是一堆報(bào)錯(cuò)。這里我把自己實(shí)測(cè)的啟動(dòng)流程整理出來(lái)基本跟著做就能跑通。5.1 調(diào)試前的環(huán)境準(zhǔn)備清單運(yùn)行這套系統(tǒng)需要的環(huán)境如下JDK 1.8或JDK 11本機(jī)實(shí)測(cè)JDK 1.8最穩(wěn)。Maven 3.6以上國(guó)內(nèi)建議配置阿里云鏡像否則依賴(lài)下載能卡半小時(shí)。MySQL 8.0數(shù)據(jù)庫(kù)編碼用utf8mb4。Redis 5.x以上用于存JWT令牌狀態(tài)和部分緩存。Node.js和npm因?yàn)榍岸耸荲ue項(xiàng)目需要npm install構(gòu)建或者直接用后端模板渲染頁(yè)面。源碼包里一般會(huì)附帶數(shù)據(jù)庫(kù)腳本文件和application.yml配置文件示例。把a(bǔ)pplication.yml復(fù)制一份改成application-local.yml修改數(shù)據(jù)源連接串是本項(xiàng)目的推薦做法避免把本地密碼提交到代碼倉(cāng)庫(kù)里。這里有個(gè)小經(jīng)驗(yàn)在配置環(huán)境時(shí)數(shù)據(jù)庫(kù)連接串里的時(shí)區(qū)要寫(xiě)清楚比如serverTimezoneAsia/Shanghai否則日期時(shí)間字段會(huì)差8個(gè)小時(shí)。5.2 啟動(dòng)報(bào)錯(cuò)排查的完整鏈路我在調(diào)試這套系統(tǒng)時(shí)遇到過(guò)一次啟動(dòng)失敗錯(cuò)誤信息是“Field patentMapper in … required a bean of type … could not be found”。這個(gè)問(wèn)題在MyBatis項(xiàng)目里非常經(jīng)典本質(zhì)是Mapper接口沒(méi)有被Spring掃描到。排查鏈路是這樣的先檢查啟動(dòng)類(lèi)上的掃描配置正常情況是SpringBootApplication默認(rèn)掃描啟動(dòng)類(lèi)所在包及子包但因?yàn)轫?xiàng)目有多個(gè)模塊包比如com.example.iprs.controller、com.example.iprs.mapper如果啟動(dòng)類(lèi)在com.example根目錄下應(yīng)該沒(méi)問(wèn)題。再看Mapper接口上有沒(méi)有加Mapper注解或者在啟動(dòng)類(lèi)上有沒(méi)有加MapperScan(com.example.iprs.mapper)。這套源碼用了MapperScan注解理論上沒(méi)問(wèn)題。我檢查后才發(fā)現(xiàn)是主啟動(dòng)類(lèi)放在了client目錄下沒(méi)有覆蓋到mapper包把MapperScan的路徑改成全限定包名就解決了。這類(lèi)問(wèn)題在二次開(kāi)發(fā)中很容易出現(xiàn)因?yàn)槟阈略隽艘粋€(gè)包忘了掃描范圍啟動(dòng)時(shí)才報(bào)錯(cuò)就非常難查。還有一次是端口被占用。SpringBoot默認(rèn)端口是8080如果本地已經(jīng)被其他服務(wù)占用了啟動(dòng)日志里會(huì)看到“Port already in use”。解決辦法要么改端口要么把占用8080端口的進(jìn)程找出來(lái)結(jié)束掉。Windows下用“netstat -ano | findstr 8080”查PID再“taskkill /F /PID xxx”殺掉Linux下用ss -lntp或者netstat配合kill處理。5.3 前端聯(lián)調(diào)的注意點(diǎn)后端啟動(dòng)成功后還要確認(rèn)前端接口能否正常訪問(wèn)。如果Vue前端和后端分離部署需要配置代理解決跨域問(wèn)題。開(kāi)發(fā)環(huán)境可以在vue.config.js里這樣配置module.exports { devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }這樣前端通過(guò)“/api/login”發(fā)請(qǐng)求時(shí)本地開(kāi)發(fā)服務(wù)器會(huì)把請(qǐng)求轉(zhuǎn)發(fā)到后端8080端口避免瀏覽器直接跨域報(bào)錯(cuò)。生產(chǎn)環(huán)境更穩(wěn)妥的做法是讓Nginx統(tǒng)一代理把靜態(tài)頁(yè)面和后端接口掛在同一個(gè)域名下通過(guò)location路徑區(qū)分。5.4 論文與答辯的銜接建議如果你用這套系統(tǒng)做畢業(yè)設(shè)計(jì)拿到調(diào)試文檔后要清楚論文怎么寫(xiě)才撐得起工作量。我的建議是把論文的第五章放到“系統(tǒng)測(cè)試”上重點(diǎn)寫(xiě)測(cè)試用例的設(shè)計(jì)。比如專(zhuān)利申請(qǐng)主流程的用例從登錄、填寫(xiě)提案、提交審核、審核通過(guò)、繳納年費(fèi)到生成證書(shū)每一步的預(yù)期結(jié)果和實(shí)際結(jié)果都要記錄。同時(shí)把權(quán)限控制作為論文中的一個(gè)亮點(diǎn)說(shuō)明不同角色看到的菜單不同、操作的接口不同。比如普通員工看不到“年費(fèi)繳納”菜單只有IP管理員能進(jìn)入費(fèi)用管理。這個(gè)用表格列出來(lái)答辯時(shí)老師會(huì)覺(jué)得你的系統(tǒng)考慮得很周全確實(shí)是有完整設(shè)計(jì)的。6. 從畢設(shè)到生產(chǎn)環(huán)境幾個(gè)容易忽視的環(huán)節(jié)源碼能跑通只是第一步真正要讓這套系統(tǒng)在企業(yè)里站住腳還需要補(bǔ)齊下面這些容易被忽略的細(xì)節(jié)。我在實(shí)際工作中見(jiàn)過(guò)太多系統(tǒng)死在這些小問(wèn)題上不是在線的就是在年費(fèi)上。6.1 重復(fù)提交與冪等設(shè)計(jì)申請(qǐng)一件專(zhuān)利時(shí)用戶手快點(diǎn)了兩次提交按鈕就可能產(chǎn)生兩條重復(fù)的申請(qǐng)記錄。雖然前端可以按鈕置灰但更可靠的是后端做冪等控制。常見(jiàn)做法是在表單提交時(shí)生成一個(gè)前端token后端在Redis里存一下處理完業(yè)務(wù)后刪除如果短時(shí)間內(nèi)同樣的token再次進(jìn)入直接拒絕。這套源碼在新增提案上沒(méi)做冪等處理只靠前端按鈕loading擋一下。如果是真實(shí)生產(chǎn)環(huán)境我建議在主表申請(qǐng)?zhí)栁ㄒ凰饕幕A(chǔ)上再配合接口層防重設(shè)計(jì)雙保險(xiǎn)更可靠。6.2 數(shù)據(jù)權(quán)限RBAC解決了“誰(shuí)能用這個(gè)功能”但沒(méi)有解決“誰(shuí)能看到這些數(shù)據(jù)”。比如部門(mén)主管應(yīng)該只能看到自己部門(mén)的專(zhuān)利提案不能隨便看其他部門(mén)的數(shù)據(jù)。這就需要在SQL層面做數(shù)據(jù)權(quán)限過(guò)濾比如增加department_id條件或者通過(guò)自定義注解攔截器根據(jù)當(dāng)前登錄用戶的部門(mén)自動(dòng)追加條件。這套系統(tǒng)做了簡(jiǎn)單的數(shù)據(jù)權(quán)限在高管和IP管理員層面是全量數(shù)據(jù)部門(mén)主管只看本部門(mén)。實(shí)現(xiàn)方法是在Service層通過(guò)當(dāng)前用戶信息手動(dòng)拼接查詢(xún)條件雖然代碼多了一些但邏輯直觀也適合作為論文里的一個(gè)論述點(diǎn)。6.3 定時(shí)任務(wù)做期限提醒年費(fèi)繳納提醒如果只靠用戶登錄系統(tǒng)時(shí)看一眼很容易漏掉。生產(chǎn)環(huán)境里一般用定時(shí)任務(wù)每天掃描一次期限臺(tái)賬把未來(lái)30天內(nèi)到期但未繳費(fèi)的記錄挑出來(lái)發(fā)送郵件或短信給對(duì)應(yīng)的發(fā)明人和IP管理員。SpringBoot里實(shí)現(xiàn)這功能很簡(jiǎn)單一個(gè)Scheduled注解加一個(gè)方法就夠了。Scheduled(cron 0 0 8 * * ?) public void remindExpiringFees() { ListFeeRecord list feeMapper.findExpiringUnpaid(LocalDate.now().plusDays(30)); for (FeeRecord fee : list) { sendRemindMessage(fee); } }注意定時(shí)任務(wù)要盡量避開(kāi)數(shù)據(jù)庫(kù)高峰期一般早上8點(diǎn)或早上9點(diǎn)執(zhí)行比較合理。如果系統(tǒng)部署在多臺(tái)服務(wù)器上還要加分布式鎖防止多臺(tái)同時(shí)執(zhí)行導(dǎo)致重復(fù)發(fā)提醒。6.4 刪除策略知識(shí)產(chǎn)權(quán)的申請(qǐng)記錄屬于重要的法律證據(jù)文件絕不能允許隨意物理刪除。這套系統(tǒng)的做法是狀態(tài)置為“已撤回”或“已作廢”保留歷史數(shù)據(jù)。我在這個(gè)基礎(chǔ)上建議再加一層軟刪除字段用delete_flag標(biāo)記0和1普通用戶查詢(xún)時(shí)自動(dòng)過(guò)濾已刪除的數(shù)據(jù)管理員后臺(tái)可以查看全部數(shù)據(jù)。像知識(shí)產(chǎn)權(quán)這種有審計(jì)需求的系統(tǒng)數(shù)據(jù)留存時(shí)間越長(zhǎng)越有價(jià)值。我個(gè)人在實(shí)際操作中的體會(huì)是技術(shù)本身不難難的是把業(yè)務(wù)規(guī)則吃透。知識(shí)產(chǎn)權(quán)管理系統(tǒng)最大的價(jià)值不在編碼而在期限和費(fèi)用的合規(guī)邏輯。就算以后你不想做Java開(kāi)發(fā)轉(zhuǎn)去做需求分析或者產(chǎn)品經(jīng)理能把“年費(fèi)計(jì)算規(guī)則”講清楚也是一個(gè)很能打的經(jīng)歷。好了這篇先寫(xiě)到這里我后續(xù)會(huì)再多整理一些知識(shí)產(chǎn)權(quán)系統(tǒng)二次開(kāi)發(fā)的實(shí)戰(zhàn)細(xì)節(jié)尤其是對(duì)接代理機(jī)構(gòu)接口和批量導(dǎo)入導(dǎo)出這兩塊這兩塊在實(shí)際部署時(shí)幾乎是必做的。