汽車資訊網(wǎng)站聽起來像是早十年就該被做濫了的項目但真到自己動手設(shè)計實現(xiàn)時才發(fā)現(xiàn)里面藏著不少值得琢磨的細節(jié)。不是簡單堆幾個頁面、連一個數(shù)據(jù)庫就能交差的尤其是當你希望它像一個真正能跑起來的產(chǎn)品而不是課程設(shè)計級別的Demo。這段時間我從零搭了一套基于Spring Boot的汽車資訊系統(tǒng)從功能拆分到實際編碼落地踩了一些坑也想明白了一些設(shè)計上的取舍。這篇就把整個設(shè)計實現(xiàn)過程拆開聊聊把關(guān)鍵的選擇邏輯和代碼細節(jié)一并捋清楚。1. 項目整體設(shè)計與功能拆解1.1 核心需求解析做系統(tǒng)之前先得把汽車資訊網(wǎng)站到底要解決什么問題拆明白。汽車資訊類網(wǎng)站的典型使用場景是什么用戶上來想干什么無非三類需求。第一類是瀏覽資訊包括新車發(fā)布、車型評測、行業(yè)動態(tài)、導購推薦之類的內(nèi)容。第二類是互動表達看到感興趣的文章點個贊、收藏一下、留個評論。第三類是內(nèi)容管理也就是網(wǎng)站運營方要能發(fā)布文章、管理欄目、審核評論、查看數(shù)據(jù)?；谶@些場景系統(tǒng)的角色可以劃分為兩類。一類是普通用戶另一類是內(nèi)容管理員。用戶端需要的是清晰的內(nèi)容展示、順滑的瀏覽體驗、以及基礎(chǔ)的互動能力。管理員端則需要一個能支撐日常內(nèi)容維護的后臺界面和配套接口。把需求落成功能模塊大概是這樣一張清單用戶模塊注冊、登錄、個人信息查看與維護資訊模塊文章列表、文章詳情、分類篩選、關(guān)鍵詞搜索互動模塊點贊、收藏、評論、評論列表管理模塊欄目管理、文章發(fā)布與上下架、評論審核刪除、用戶狀態(tài)管理數(shù)據(jù)統(tǒng)計模塊資訊瀏覽量統(tǒng)計、熱門排行這套功能邊界看著基礎(chǔ)但實際做起來涉及很多設(shè)計決策。比如用戶登錄用傳統(tǒng)的Session還是用JWT資訊搜索用數(shù)據(jù)庫模糊查詢還是引入搜索引擎權(quán)限校驗寫死在代碼里還是用Spring Security做統(tǒng)一攔截這些問題的答案決定了整個項目寫起來是順滑還是別扭。1.2 功能模塊邊界劃分模塊邊界如果劃不清楚寫代碼的時候很容易出現(xiàn)這個Service該放哪的糾結(jié)。我按職責把系統(tǒng)分成了五個核心模塊每個模塊只關(guān)心自己范圍內(nèi)的事情用戶模塊user負責賬號的注冊、登錄、鑒權(quán)。這里包含用戶基本信息表、登錄狀態(tài)管理、個人資料接口但不負責具體資訊內(nèi)容的加工。資訊模塊content負責文章、欄目、標簽的增刪改查。一篇資訊從創(chuàng)建到展示經(jīng)過欄目歸屬、狀態(tài)校驗、內(nèi)容組裝全部在這個模塊內(nèi)閉環(huán)?；幽Kinteraction處理點贊、收藏、評論三類行為。這個模塊與用戶模塊、資訊模塊會有關(guān)聯(lián)但通過userId和articleId做弱耦合互不直接操作對方的表。管理模塊admin面向前臺管理員的接口集合。它調(diào)用用戶模塊和資訊模塊的底層服務(wù)但在Controller層與管理端接口分開便于做獨立的權(quán)限控制。統(tǒng)計模塊stats負責瀏覽量計數(shù)和排行數(shù)據(jù)的產(chǎn)出。為了不拖慢主流程我把它設(shè)計為異步采集、定時匯總的模式而不是每次請求都去做重聚合運算。這樣劃分之后開發(fā)次序就很清晰了。先做用戶和資訊兩大基礎(chǔ)模塊因為它們承載了系統(tǒng)的骨架?；幽K隨后接入因為它依賴前兩者的主鍵ID做關(guān)聯(lián)。統(tǒng)計模塊放最后等基礎(chǔ)功能穩(wěn)定之后再考慮數(shù)據(jù)的挖掘和展示。2. 技術(shù)選型與核心工具解析2.1 框架選型背后的理由Spring Boot本身解決的核心痛點是配置繁瑣、依賴管理混亂。用了它之后以往SSH時代那一大堆XML配置基本可以丟掉了一個啟動類加約定大于配置的理念能夠把精力集中在業(yè)務(wù)代碼上。具體到這個項目我選用了Spring Boot 2.7.x版本。之所以沒有選擇最新的3.x主要考慮到生態(tài)兼容性的問題很多配套的第三方組件對3.x的Jakarta命名空間支持還不夠完善。對于一個資訊網(wǎng)站這種CRUD密集型業(yè)務(wù)來說2.7.x已經(jīng)綽綽有余而且網(wǎng)上踩坑資料也多遇到了問題容易查到解決方案。在持久層框架上我選了MyBatis-Plus。在實際開發(fā)中單表的增刪改查如果用原生的MyBatis需要手動寫大量的重復SQL。MyBatis-Plus的BaseMapper提供了現(xiàn)成的通用方法配合Wrapper構(gòu)造器可以應對絕大多數(shù)查詢場景讓我能省下時間專注在復雜查詢的SQL優(yōu)化上。安全框架用的是Spring Security加JWT。Session方案的痛點在于服務(wù)端要存狀態(tài)、處理跨域時很麻煩、水平擴展時還要考慮Session共享這些對前后端分離的架構(gòu)都不友好。JWT令牌是無狀態(tài)的服務(wù)端不用保存會話客戶端帶著Token請求就行了。配合Spring Security的過濾器鏈做統(tǒng)一鑒權(quán)邏輯清晰也符合現(xiàn)在主流的前后端分離開發(fā)模式。2.2 數(shù)據(jù)存儲與檢索方案選型數(shù)據(jù)庫毫無疑問是MySQL。汽車資訊系統(tǒng)的數(shù)據(jù)模型不算復雜主要是用戶表、資訊表、評論表這幾張核心表MySQL的InnoDB引擎在事務(wù)支持和行級鎖方面的表現(xiàn)足夠勝任。但是資訊的搜索功能光用MySQL會有點難受。文章標題和內(nèi)容的模糊查詢?nèi)绻苯由螸IKE %關(guān)鍵詞%在數(shù)據(jù)量大了之后性能會明顯下降。不過我考慮到這個項目的定位是中小規(guī)模的業(yè)務(wù)場景初期不引入Elasticsearch這種重組件。我采用的折中方案是先用MySQL的全文索引配合必要的查詢優(yōu)化處理搜索需求同時在表結(jié)構(gòu)設(shè)計時預留text字段的檢索余地。如果未來資訊量真的漲到幾十萬條再平滑遷移到Elasticsearch也不遲。緩存層我用了Redis。在這個項目里Redis承擔兩個職責一是存儲熱點資訊的詳情數(shù)據(jù)避免每次請求都穿透到數(shù)據(jù)庫二是維護部分統(tǒng)計計數(shù)比如瀏覽量這種高頻寫入的數(shù)據(jù)直接走Redis的INCR命令定時刷入MySQL。這樣不僅查詢快了數(shù)據(jù)庫的壓力也小了很多。2.3 配置管理設(shè)計配置管理這塊我按照環(huán)境拆分了配置文件。開發(fā)環(huán)境用application-dev.yml生產(chǎn)環(huán)境用application-prod.yml主配置文件里只放兩類環(huán)境通用的配置項。數(shù)據(jù)源、Redis連接、日志級別這些按環(huán)境區(qū)分開的配置在各自的配置文件里單獨維護。有一個細節(jié)容易被忽略數(shù)據(jù)庫密碼、JWT密鑰這類敏感信息不應該明文寫在配置文件里。在部署階段我改為通過環(huán)境變量的方式注入配置文件中只保留占位符。這是從安全角度考量的做法雖然本地開發(fā)時會麻煩一點但能避免密碼泄露的風險。3. 數(shù)據(jù)庫設(shè)計與核心模塊實現(xiàn)3.1 核心表結(jié)構(gòu)設(shè)計數(shù)據(jù)庫設(shè)計是整個系統(tǒng)動工前的第一道工序表結(jié)構(gòu)定得不合理后面所有代碼寫起來都別扭。我用了大概半天時間梳理字段、確定關(guān)聯(lián)關(guān)系最終落成這幾張核心表。用戶表users的設(shè)計除了常規(guī)的id、用戶名、密碼之外我額外加了status字段做賬號狀態(tài)標記以及avatar、phone這類可選信息字段。密碼字段我選用了BCrypt加密后的哈希值存儲固定長度60字符所以字段類型設(shè)為varchar(60)就足夠了。資訊表articles是內(nèi)容的核心載體字段相對多。基本信息包括標題、摘要、正文內(nèi)容、封面圖URL、所屬欄目ID。狀態(tài)字段用來區(qū)分草稿、已發(fā)布、已下架幾種狀態(tài)。瀏覽數(shù)字段用于展示閱讀量。為了防止管理后臺編輯時內(nèi)容過大影響查詢性能我把正文單獨放在longtext類型的body字段里列表查詢時只select必要字段不把正文撈出來。評論表comments記錄了用戶對資訊的評論內(nèi)容。除了正文和關(guān)聯(lián)的文章ID我還設(shè)計了parent_id字段支持樓中樓的回復場景。另外通過audit_status字段控制評論的展示狀態(tài)新評論默認處于待審核狀態(tài)管理員確認無違規(guī)后才對外展示?；雨P(guān)系表和統(tǒng)計計數(shù)我單獨處理。點贊、收藏這類行為記錄關(guān)聯(lián)表我會連帶著把用戶的ID、內(nèi)容ID加上做成唯一約束避免用戶重復操作產(chǎn)生臟數(shù)據(jù)。瀏覽量和點贊數(shù)的數(shù)值字段直接冗余在文章表里通過事務(wù)保證關(guān)聯(lián)表和計數(shù)的一致性。3.2 權(quán)限體系與接口設(shè)計規(guī)范接口設(shè)計遵循RESTful風格資源的動作通過HTTP方法表達通過URL定位資源。登錄注冊用POST獲取文章列表用GET刪除評論用DELETE更新的操作用PUT。接口路徑上也能清晰看出資源層級比如/articles/{id}/comments是某篇文章的評論列表/users/{id}/favorites是某用戶的收藏列表。接口分兩類來設(shè)計權(quán)限。一類是公開接口比如注冊登錄、文章列表、文章詳情。另一類是認證接口比如發(fā)布評論、點贊收藏、進入后臺管理必須攜帶有效的Token才能訪問。后臺管理的權(quán)限需要單獨分級管理員可以管理資訊內(nèi)容和用戶狀態(tài)普通操作員只能維護資訊內(nèi)容。Spring Security里通過配置多個SecurityFilterChain實現(xiàn)不同的安全規(guī)則/api/admin/開頭的路徑走管理端認證規(guī)則/api/user/開頭的路徑走用戶端認證規(guī)則兩個鏈互不干擾。3.3 核心表DDL與數(shù)據(jù)關(guān)系示意在設(shè)計階段我整理出了核心表之間的關(guān)系脈絡(luò)作為開發(fā)時手寫SQL和數(shù)據(jù)訪問的依據(jù)。項目里并不使用外鍵約束關(guān)聯(lián)關(guān)系完全通過邏輯上的ID對應來維護這樣在分庫分表或數(shù)據(jù)歸檔時不會受物理外鍵的拖累。用戶表和資訊表的關(guān)系主要體現(xiàn)在創(chuàng)建者字段上。文章表里存user_id表示誰發(fā)布了這篇文章。資訊表和欄目的關(guān)系則通過column_id來歸屬欄目欄目表負責維護一層分類信息。用戶與資訊的互動關(guān)系通過中間表表達比如用戶表與資訊表的點贊關(guān)系映射成一張favorites表里面只存user_id和article_id?？紤]到一篇資訊下評論數(shù)量比較多評論表里單獨存article_id做索引分頁查出指定文章的評論列表。字段命名時我堅持了統(tǒng)一規(guī)范主鍵統(tǒng)一叫id外鍵關(guān)聯(lián)統(tǒng)一用xxx_id的格式時間字段統(tǒng)一叫create_time和update_time。這樣即使項目做到后期接手同事也能快速理解數(shù)據(jù)結(jié)構(gòu)不用翻著文檔猜來猜去。3.4 分頁查詢與數(shù)據(jù)組裝優(yōu)化列表頁和后臺管理頁都離不開分頁。MyBatis-Plus的分頁插件使用很簡單傳入當前頁和每頁條數(shù)就能拿到分頁結(jié)果。但真正需要花心思的是分頁之外的數(shù)據(jù)組裝。文章列表接口返回給前端時不能只給數(shù)據(jù)庫里的原始字段。前端還需要知道作者的名字、文章所屬的欄目名稱、以及點贊和評論的計數(shù)。如果用循環(huán)去數(shù)據(jù)庫里逐條查關(guān)聯(lián)數(shù)據(jù)N1問題就出現(xiàn)了列表接口會慢得讓人崩潰。我的處理辦法是先查出當前頁的文章ID集合然后用IN查詢一次性查出所有關(guān)聯(lián)的用戶信息、欄目信息、計數(shù)信息在內(nèi)存里做一次Map匹配組裝。這樣無論一頁是10條還是20條記錄查詢次數(shù)都保持在一個穩(wěn)定的數(shù)量級性能表現(xiàn)非常好。4. 關(guān)鍵功能實操與代碼落地4.1 基于JWT的登錄鑒權(quán)實現(xiàn)登錄功能看起來簡單實際上涉及Spring Security的過濾器鏈配置、JWT工具類的封裝、以及UserDetailsService的對接幾個環(huán)節(jié)任何一個地方銜接不上登錄流程都跑不通。先看JWT工具類的核心邏輯。生成Token時我把用戶ID和用戶名放進了claims里同時設(shè)置了過期時間。解析Token時通過密鑰校驗簽名并從claims中提取用戶IDComponent public class JwtTokenProvider { private final String secretKey your-secret-key-at-least-32-chars-long; private final long validityInMilliseconds 7200000; // 2小時 public String createToken(Long userId, String username) { Date now new Date(); Date validity new Date(now.getTime() validityInMilliseconds); return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(username, username) .setIssuedAt(now) .setExpiration(validity) .signWith(Keys.hmacShaKeyFor(secretKey.getBytes()), SignatureAlgorithm.HS256) .compact(); } public Long getUserIdFromToken(String token) { Claims claims Jwts.parserBuilder() .setSigningKey(secretKey.getBytes()) .build() .parseClaimsJws(token) .getBody(); return Long.valueOf(claims.getSubject()); } public boolean validateToken(String token) { try { Jwts.parserBuilder().setSigningKey(secretKey.getBytes()).build().parseClaimsJws(token); return true; } catch (JwtException | IllegalArgumentException e) { return false; } } }實際項目中密鑰不應該硬編碼在代碼里應該通過配置中心或環(huán)境變量注入這里只是便于演示。認證過濾器的職責是從請求頭里讀取Token校驗通過后把用戶信息放進SecurityContext中讓后續(xù)的接口可以直接獲取當前登錄用戶Component public class JwtAuthenticationFilter extends OncePerRequestFilter { Autowired private JwtTokenProvider jwtTokenProvider; Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { String token resolveToken(request); if (token ! null jwtTokenProvider.validateToken(token)) { Long userId jwtTokenProvider.getUserIdFromToken(token); UsernamePasswordAuthenticationToken authentication new UsernamePasswordAuthenticationToken(userId, null, Collections.emptyList()); SecurityContextHolder.getContext().setAuthentication(authentication); } filterChain.doFilter(request, response); } private String resolveToken(HttpServletRequest request) { String bearerToken request.getHeader(Authorization); if (bearerToken ! null bearerToken.startsWith(Bearer )) { return bearerToken.substring(7); } return null; } }登錄接口本身比較簡單先根據(jù)用戶名查出用戶再用BCrypt校驗密碼是否匹配匹配通過就生成Token返回給前端。這里有一個設(shè)計上的小決策查詢用戶時如果查不到不應該直接拋異常而是統(tǒng)一拋一個業(yè)務(wù)異常讓全局異常處理器把用戶名或密碼錯誤的提示返回給前端避免暴露用戶是否存在的信息。4.2 資訊列表與詳情接口實現(xiàn)資訊列表接口是面向用戶的主入口需要考慮分類篩選、發(fā)布時間排序、分頁等因素。如果是后臺管理的列表接口還需要疊加狀態(tài)篩選能力兩套場景應該分開實現(xiàn)。用戶端列表接口我用條件構(gòu)造器實現(xiàn)Override public PageResultArticleVO getPublishedArticles(Long columnId, int page, int size) { PageArticle pageParam new Page(page, size); LambdaQueryWrapperArticle wrapper new LambdaQueryWrapper(); wrapper.eq(Article::getStatus, 1); // 已發(fā)布 if (columnId ! null) { wrapper.eq(Article::getColumnId, columnId); } wrapper.orderByDesc(Article::getPublishTime); PageArticle articlePage articleMapper.selectPage(pageParam, wrapper); ListArticleVO voList buildArticleVOList(articlePage.getRecords()); return new PageResult(voList, articlePage.getTotal()); }buildArticleVOList方法里處理數(shù)據(jù)組裝的問題。通過收集全部記錄里的userId和columnId分別查詢得到用戶Map和欄目Map再遍歷填充private ListArticleVO buildArticleVOList(ListArticle records) { if (records null || records.isEmpty()) { return Collections.emptyList(); } SetLong userIds records.stream().map(Article::getUserId).collect(Collectors.toSet()); SetLong columnIds records.stream().map(Article::getColumnId).collect(Collectors.toSet()); MapLong, String userNames userService.getUserNamesByIds(userIds); MapLong, String columnNames columnService.getColumnNamesByIds(columnIds); return records.stream().map(article - { ArticleVO vo new ArticleVO(); BeanUtils.copyProperties(article, vo); vo.setAuthorName(userNames.getOrDefault(article.getUserId(), 未知用戶)); vo.setColumnName(columnNames.getOrDefault(article.getColumnId(), 未分類)); return vo; }).collect(Collectors.toList()); }文章詳情的實現(xiàn)比列表多一點細節(jié)。每次訪問詳情頁瀏覽量都要加一。我選擇直接更新文章表中的view_count字段通過Redis的INCR緩存熱點數(shù)據(jù)異步刷盤。為了減少高并發(fā)下的鎖競爭更新瀏覽量的SQL只針對主鍵做條件更新不校驗原值Update(UPDATE articles SET view_count view_count 1 WHERE id #{articleId}) void increaseViewCount(Param(articleId) Long articleId);這樣做雖然極端場景下會有少量計數(shù)丟失但換取的是寫入性能的提升。對資訊系統(tǒng)來說瀏覽量的精準度并不是業(yè)務(wù)核心指標完全夠用。4.3 全文搜索的落地實現(xiàn)搜索這塊我沒有引入Elasticsearch而是用了MySQL的全文索引配合MyBatis-Plus的自定義SQL。一張資訊表要支持標題和內(nèi)容的搜索在表結(jié)構(gòu)上先做文章建表時給title和body字段加上全文索引或者通過ALTER TABLE動態(tài)添加ALTER TABLE articles ADD FULLTEXT INDEX ft_title_body (title, body);查詢時使用MATCH AGAINST語法來做相關(guān)度匹配Select(SELECT * FROM articles WHERE MATCH(title, body) AGAINST(#{keyword} IN NATURAL LANGUAGE MODE) AND status 1 ORDER BY publish_time DESC LIMIT #{offset}, #{size}) ListArticle searchByFullText(Param(keyword) String keyword, Param(offset) int offset, Param(size) int size);在使用過程中發(fā)現(xiàn)一個值得注意的點全文索引的檢索模式分為自然語言模式和布爾模式自然語言模式的匹配更加智能但相關(guān)度的排序用戶感知不明顯。在對搜索體驗要求更高的場景下可以改用布爾模式配合加減號干預排序。不過這個方案也有委屈的地方中文分詞的支持不如專業(yè)搜索引擎好在資訊網(wǎng)站的搜索詞多半是品牌名、車型名這類明確詞匯匹配效果還算理想。4.4 評論與互動的并發(fā)控制評論功能看起來只是插入一條記錄但埋了一個并發(fā)隱患。如果同一時間大量用戶給同一篇文章發(fā)評論評論計數(shù)應該平滑增長。我在實現(xiàn)評論插入的同時通過事務(wù)把評論數(shù)和文章表的評論計數(shù)更新放在一起保證兩者不會出現(xiàn)長短腿。點贊功能的冪等性很關(guān)鍵用戶重復點擊不應該產(chǎn)生多條記錄。我的做法是在點贊表中建立user_id和article_id的唯一索引插入時捕獲DuplicateKeyException如果出現(xiàn)重復記錄就返回已點贊的友好提示避免前端誤以為操作失敗。取消點贊時直接物理刪除對應記錄簡單高效。另外值得提的是在我的設(shè)計里評論是有審核狀態(tài)的。用戶發(fā)出的評論先落在待審核狀態(tài)管理員在后臺審核通過后展示出來。這個流程會讓首次寫評論的用戶產(chǎn)生發(fā)出去了怎么看不到的疑問所以前端需要在交互上明確提示評論處于待審核狀態(tài)這個體驗細節(jié)很容易被忽略。5. 常見問題與排查技巧實錄5.1 鑒權(quán)失效的經(jīng)典場景前后端分離開發(fā)時聯(lián)調(diào)階段最容易出的問題就是跨域?qū)е虑岸藥Р涣薚oken。瀏覽器在跨域請求時如果前端代碼沒有顯式設(shè)置withCredentials或者后端沒有配置允許攜帶憑證請求頭里的Authorization會被瀏覽器吃掉后端自然拿不到Token。排查這類問題時我先在瀏覽器的Network面板里看請求頭是否包含Authorization。如果請求頭本身就沒有Token說明問題出在前端或網(wǎng)關(guān)層。如果請求頭里有Token但接口還是返回401那就要看后端的過濾器是否被Spring Security的過濾鏈正確加載了。一個容易被忽略的點是自定義過濾器必須注冊到Security的過濾鏈中才能生效僅僅聲明成Component有時不會自動加入。5.2 分頁查詢中數(shù)據(jù)重復與丟失MyBatis-Plus分頁插件使用中最經(jīng)典的坑是排序字段不唯一導致的分頁數(shù)據(jù)偏移。如果文章列表里有大量文章發(fā)布時間相同排序不穩(wěn)定就會造成同一篇文章在翻頁時重復出現(xiàn)或漏掉。解決思路是排序時增加一個唯一字段作為次級排序條件比如先按publish_time倒序再按id倒序這樣每一條記錄的順序都是確定性的。這個調(diào)整在數(shù)據(jù)量大了之后能明顯感受到翻頁體驗的變化。另一個常見問題是分頁插件失效。如果MyBatis-Plus的分頁插件沒有配置攔截器或者配置了但因為包掃描順序問題沒有加載所有分頁查詢都會變成全表查詢。排查時可以在日志里看SQL語句末尾是否拼接了LIMIT關(guān)鍵字來快速定位。5.3 緩存穿透與緩存擊穿引入Redis緩存后我實際遇到過兩類數(shù)據(jù)問題。一類是緩存穿透也就是用戶頻繁請求一條根本不存在的文章ID每次請求都會壓到數(shù)據(jù)庫給數(shù)據(jù)庫帶來不必要的查詢壓力。解決的辦法很簡單在緩存中存儲一個空值的占位標記并設(shè)置較短的過期時間這樣同一無效ID的反復查詢不會每次都打到數(shù)據(jù)庫。另一類是緩存擊穿熱門的資訊緩存過期瞬間大量請求同時涌入數(shù)據(jù)庫。我用了一個分布式鎖的間接方案來緩解當緩存失效時只允許一個線程去數(shù)據(jù)庫查詢并回填緩存其他線程先等待緩存重建完成后再讀取。簡單實現(xiàn)了一個基于Redis的SETNX鎖雖然不如Redisson那么完善但應對中小規(guī)模系統(tǒng)的熱點數(shù)據(jù)已經(jīng)夠用。5.4 文件上傳與存儲策略的實際考量資訊網(wǎng)站的封面圖和正文插圖涉及圖片上傳的問題。本地磁盤存儲雖然簡單但在部署到云服務(wù)器后會有兩個麻煩一是磁盤空間有限二是后續(xù)遷移成本高。我當時采用的是本地目錄存儲配合Nginx靜態(tài)映射的方案上傳接口把文件保存到服務(wù)器指定目錄返回給前端的是經(jīng)過Nginx映射后的訪問URL。實現(xiàn)上傳接口時有兩個細節(jié)需要注意。一是文件名的生成不能用用戶上傳的原始文件名否則很容易出現(xiàn)重名覆蓋和路徑穿越的安全問題我用UUID重命名后保留了原始擴展名作為后綴。二是需要做文件類型的白名單校驗只允許jpg、png、webp這幾個常用的圖片格式防止惡意用戶上傳可執(zhí)行文件偽裝成圖片。文件大小也要做限制我設(shè)置了單張圖片5MB的上限超出就直接拒絕。5.5 后臺管理接口的安全加固后臺管理接口暴露出去之后如果只有登錄認證沒有其他防護措施容易被批量調(diào)用造成數(shù)據(jù)泄露或資源消耗。除了登錄鑒權(quán)之外我還加了兩個層面的防護。第一層是管理端接口全部走獨立路徑前綴在Spring Security中對該路徑單獨配置權(quán)限要求只有具有對應角色的人才允許訪問。第二層是對管理端的敏感操作加操作日志管理員刪除資訊或強制下架文章時系統(tǒng)會記錄下操作人的ID、操作時間和操作內(nèi)容方便事后追溯。接口的防刷處理在實際運營中也是必要的一環(huán)。我在網(wǎng)關(guān)層增加了一個簡單的計數(shù)器同一IP在單位時間內(nèi)調(diào)用管理端接口的次數(shù)超過閾值就會被臨時封禁。這個邏輯用Redis的INCR加EXPIRE就能實現(xiàn)代碼量不大但能把絕大多數(shù)惡意請求擋在外面。6. 項目運行效果與個人實操心得6.1 從本地聯(lián)調(diào)到模擬部署的完整鏈路項目開發(fā)完成后的聯(lián)調(diào)階段我習慣先按正常業(yè)務(wù)流走一遍全流程模擬真實用戶從注冊登錄到瀏覽收藏評論的完整路徑。這一遍的目的不是找Bug而是感受操作邏輯是否順暢。聯(lián)調(diào)通過后進入部署準備階段我選用寶塔面板配合Docker的方式完成模擬部署。Spring Boot應用打成Jar包后通過Docker鏡像運行MySQL和Redis用Docker Compose統(tǒng)一編排。容器化部署的好處是環(huán)境一致性有保障換一臺服務(wù)器也能快速拉起全套服務(wù)。Docker Compose的核心配置大致長這樣version: 3.8 services: mysql: image: mysql:8.0 container_name: car-news-mysql environment: MYSQL_ROOT_PASSWORD: root123456 MYSQL_DATABASE: car_news ports: - 3306:3306 volumes: - ./mysql-data:/var/lib/mysql redis: image: redis:7.0 container_name: car-news-redis ports: - 6379:6379 app: build: . container_name: car-news-app depends_on: - mysql - redis ports: - 8080:8080 environment: SPRING_PROFILES_ACTIVE: prod DB_HOST: mysql DB_PASSWORD: root123456 REDIS_HOST: redis容器化的過程中有一個經(jīng)常出問題的點應用容器啟動時MySQL容器可能還沒就緒連接數(shù)據(jù)庫直接報錯。雖然depends_on能控制容器的啟動順序但并不能保證數(shù)據(jù)庫服務(wù)已經(jīng)完成初始化。我加了一個簡單的健康檢查腳本應用啟動前先檢測MySQL的3306端口是否可連接直到確認數(shù)據(jù)庫就緒后才啟動Spring Boot應用這個細節(jié)幫我節(jié)省了不少排查時間。6.2 開發(fā)中反復踩過的幾個真實坑踩坑經(jīng)驗往往比功能代碼更有價值。我印象最深的是第一個版本里把所有Service實現(xiàn)都優(yōu)先考慮做事務(wù)無論讀操作還是寫操作都加上Transactional。結(jié)果在查看資訊列表時因為事務(wù)中的查詢持有數(shù)據(jù)庫連接時間過長并發(fā)量上來后連接池被占滿整個應用直接不可用。后來我給只讀操作去掉了事務(wù)把事務(wù)粒度縮小到真正的寫操作上才解決了這個問題。還有一個坑是關(guān)于前端跨域配置的。開發(fā)環(huán)境下我用Vue壓理了代理轉(zhuǎn)發(fā)生產(chǎn)環(huán)境則通過Nginx反向代理統(tǒng)一處理后端沒有開啟全局跨域配置。之所以刻意這樣設(shè)計是因為把所有跨域放寬會讓接口暴露在任意域名的惡意請求下產(chǎn)生不必要風險。通過反向代理集中管理域名的白名單策略能收得更緊安全上也更有底氣。JWT密鑰的管理也值得專門說一句。最初我把密鑰直接寫在配置文件中后來考慮到部署環(huán)境的差異化改成通過環(huán)境變量注入。這樣做的原因很簡單如果代碼倉庫泄露密鑰也一起泄露攻擊者就能自己偽造Token直接以管理員身份訪問后臺后果不堪設(shè)想。密鑰的管理看起來是個小細節(jié)但在安全鏈條上是至關(guān)重要的一環(huán)。6.3 這個系統(tǒng)還能往哪些方向擴展這套系統(tǒng)現(xiàn)在的狀態(tài)是功能完整、邏輯清晰但要是放在真實運營場景里還有不少可以深入的空間。搜索方面如果資訊積累到一定量級MySQL全文索引的短板會逐漸顯現(xiàn)。到時候可以平滑地引入Elasticsearch把搜索單獨拆成微服務(wù)與主站的業(yè)務(wù)邏輯解耦。資訊內(nèi)容的個性化推薦也是一個值得做的方向基于用戶的歷史閱讀記錄做簡單的標簽偏好統(tǒng)計就能在首頁給出千人千面的資訊流這在提升用戶留存上效果很明顯。后臺的運營能力也可以繼續(xù)加深。比如加上定時發(fā)布功能讓運營人員提前備稿增加數(shù)據(jù)報表模塊按天維度統(tǒng)計各欄目的瀏覽量趨勢。這些功能與現(xiàn)有架構(gòu)互不沖突甚至可以在不改動現(xiàn)有核心代碼的前提下以增量方式開發(fā)上線。對想做畢業(yè)設(shè)計或者面試項目展示的朋友來說基礎(chǔ)版本搭好后按這幾個方向做迭代增值里面的技術(shù)含量是完全足夠展開來講的。最后想給準備動手做這類系統(tǒng)的朋友一個建議一定不要一頭扎進代碼里先花時間把表結(jié)構(gòu)設(shè)計好、把模塊邊界理清楚動手寫代碼的時候會順暢得多。我當時在表結(jié)構(gòu)設(shè)計上多花了一個晚上后面整個開發(fā)過程中來回頭修改表結(jié)構(gòu)的情況幾乎沒有發(fā)生。技術(shù)框架一直在迭代但數(shù)據(jù)模型和業(yè)務(wù)邏輯的分析能力才是這類系統(tǒng)真正考驗人的地方。