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