第27周JavaSpringboot電商進階開發 1.企業級用戶驗證

課程筆記：注冊郵箱驗證

一、概述

從本小節開始，將學習如何進行注冊郵箱驗證。主要任務是給項目配置一個公共郵箱（可自己注冊或由公司提供），用于向用戶發送驗證碼，幫助用戶完成注冊流程。課程中以QQ郵箱為例，介紹在Spring Boot中發送郵件（包括正文、標題等）的方法。用戶收到驗證碼后填寫回來，與系統發送的進行比對，一致則驗證成功，反之則失敗。

二、注冊郵箱驗證的兩種主流方式

  1. 驗證碼驗證（國內常用，課程采用方式）

    • 流程：用戶填寫郵箱后點擊發送驗證碼按鈕，系統向該郵箱發送隨機生成的驗證碼。用戶收到后填寫回來，系統進行比對校驗。
    • 原理：驗證碼生成、校驗及重復校驗。若后續需進行短信驗證，只需將發郵件改為發短信，其他校驗原理一致。

  2. 唯一鏈接驗證（國外常用）

    • 原理：給用戶郵箱發送一個帶有長鏈接的郵件，鏈接訪問某接口并帶參數（含個人信息）。每個郵箱的鏈接唯一，能訪問該鏈接說明用戶是郵箱主人。
    • 流程：用戶點擊唯一鏈接后，系統驗證通過，確認是真實用戶。

三、課程采用的驗證碼驗證流程

  1. 用戶在網頁點擊發送驗證碼按鈕，系統檢查該郵箱是否已注冊。
    • 未注冊：將用戶信息放入緩存，向郵箱發送驗證碼。
    • 已注冊：拒絕注冊（不允許兩個用戶使用同一郵箱）。
  2. 用戶在郵箱中收到驗證碼，復制到網站繼續注冊，提交驗證碼。
  3. 系統在緩存中校驗驗證碼是否正確、是否過期。
    • 不正確或過期：拒絕注冊。
    • 正確：用戶注冊成功。

課程筆記：郵件發送功能的開發與完善

一、郵箱配置（以 QQ 郵箱為例）

  1. 進入郵箱設置：點擊郵箱界面的“設置”選項。
  2. 找到第三方服務：在設置頁面的“常規”選項下，找到“第三方服務”相關設置。
  3. 開啟服務并獲取授權碼：
    • 如果服務未開啟，點擊“開啟服務”。
    • 開啟后，系統會生成一個授權碼，該授權碼專門用于程序驗證，不同于普通登錄密碼。
    • 授權碼相當于獨立密碼，用于提高賬號安全性，需妥善保存，后續在程序配置中會用到。
  4. 其他郵箱配置類似：如 163 郵箱等，配置過程大致相同，找到類似“第三方服務”或“授權碼”相關設置，進行相應配置。

二、給 User 類添加字段

  1. 進入 mybatis 配置類：找到對應的配置類，注釋掉其他表，僅保留 User 表。
  2. 更新數據庫表：在數據庫中找到對應的 User 表，添加 email 字段，類型為 varchar(100)，注釋為“郵箱地址”。
  3. 重新生成舊類：運行 mybatis generator，生成新的 User 類。
  4. 備份自定義代碼：提前復制保存 mapper 中自動生成代碼后添加的自定義方法和 SQL 語句，避免重新生成后被覆蓋。
  5. 恢復自定義代碼：生成新類后，將備份的代碼粘貼回來，并引入相關包。

三、引入郵件發送依賴

在項目中添加 spring-boot-starter-mail 依賴，指定版本為 2.3.4.RELEASE。

四、開發發送郵件接口

  1. 在 UserController 中添加接口：

    • 方法頭：發送郵件，路徑為 sendEmail，參數為 emailaddress（郵件地址）。
    • 返回格式匹配。

  2. 實現方法：

    • 校驗郵件地址是否有效：
      • 使用 utu 包中的 InternetAddress 類的 validate 方法。
      • 創建 Email 工具類，新增 isValidEmailAddress 方法，返回 boolean 值。
      • 在該方法中，使用 try-catch 包裹 InternetAddress(email).validate()，若無異常返回 true，否則返回 false。
      • 使用該方法檢查傳入的 emailaddress，若無效，返回錯誤響應（枚舉值為 INVALID_EMAIL，中文為“非法的郵件地址”）。
    • 檢查是否已注冊：若郵件地址有效，進一步檢查是否已注冊。
    • 發送郵件：若以上校驗均通過，執行郵件發送邏輯。

五、檢查郵件地址是否已注冊

  1. 在 User Service 中新增方法：

    • 方法名：public boolean checkEmailRegistered(String emailaddress)
    • 使用 UserMapper 的 selectOneByEmailaddress 方法，根據傳入的郵件地址查詢用戶。
    • 若返回的 User 對象不為空，說明郵件地址已被注冊，返回 false；否則返回 true。

  2. 在 UserMapper 中補充 SQL 語句：

    • 方法名：selectOneByEmailaddress(String emailaddress)
    • SQL 語句：SELECT * FROM imcomo_user WHERE emailaddress = #{emailaddress} LIMIT 1

六、郵件發送邏輯實現

  1. 在 UserController 中調用檢查方法：

    • 在通過郵件地址合法性驗證后，調用 userService.checkEmailRegistered(emailaddress)。
    • 若返回值為 false（郵件地址已被注冊），返回錯誤響應（枚舉值為 EMAIL_ALREADY_BEEN_REGISTERED，中文為“email 地址已被注冊”）。

  2. 創建 EmailService 接口及實現類：

    • 接口方法：void sendSimpleMessage(String to, String subject, String text)
    • 實現類：EmailServiceImpl，使用 JavaMailSender 發送郵件。

  3. 配置郵件相關屬性：

    • 在配置文件中設置郵件主機、端口號、用戶名、授權碼、編碼及驗證相關屬性。

  4. 完善郵件發送方法：

    • 在 sendSimpleMessage 方法中，創建 SimpleMailMessage 對象，設置發件人（從常量中獲取）、收件人、主題和正文。
    • 使用 JavaMailSender 的 send 方法發送郵件。

  5. 在 UserController 中調用郵件發送服務：

    • 引入 EmailService。
    • 調用 emailService.sendSimpleMessage，傳入郵件地址、主題（從常量中獲取）和驗證碼相關正文。

七、生成隨機驗證碼

  1. 在 Email 工具類中新增方法：

    • 方法名：public static String generateVerificationCode()
    • 創建包含數字、大寫字母、小寫字母的字符列表。
    • 使用 Collections.shuffle 打亂列表順序。
    • 取列表前六位字符作為驗證碼。
    • 返回生成的驗證碼字符串。

  2. 測試驗證碼生成方法：編寫測試方法，打印生成的驗證碼，驗證其隨機性和正確性。

八、限制重復發送郵件

  1. 引入 Redis 依賴：添加 redisson 依賴，用于操作 Redis。

  2. 在 EmailService 中新增方法：

    • 方法名：public boolean saveEmailToRedis(String emailaddress, String verificationCode)
    • 獲取 Redis 客戶端，連接到本地 Redis。
    • 使用 getBucket 方法傳入郵箱地址作為 key，獲取對應的 bucket。
    • 檢查 bucket 中是否存在值：
      • 不存在：使用 set 方法存入驗證碼，設置過期時間為 60 秒，單位為秒，返回 true。
      • 存在：返回 false，表示 60 秒內已發送過郵件。

  3. 在 UserController 中調用并處理：

    • 調用 emailService.saveEmailToRedis，傳入郵箱地址和驗證碼。
    • 根據返回值判斷：
      • 返回 true：發送郵件，返回成功響應。
      • 返回 false：返回錯誤響應，提示郵件已發送，請稍后再試。

九、完善郵件發送內容

將生成的驗證碼添加到郵件正文內容中。

十、測試驗證

  1. 測試非法郵件地址：發送格式錯誤的郵件地址，驗證是否被攔截。
  2. 測試已注冊郵箱：將郵箱地址設置為已注冊的用戶，驗證是否被攔截。
  3. 測試重復發送：短時間內反復發送郵件，驗證是否被攔截。

十一、總結

通過校驗郵件地址合法性、檢查是否已注冊、限制重復發送以及使用 Redis 緩存驗證碼，完善了郵件發送接口的功能，提高了系統的安全性和穩定性。

課程筆記：注冊接口升級與郵箱驗證總結

一、注冊接口升級

  1. 調整入參：

    • 增加 emailaddress（郵箱地址）和 verificationcode（驗證碼）兩個參數。

  2. 增加校驗：

    • 非空校驗：對郵箱和驗證碼進行非空校驗，新建異常類 26email不能為空 和 27驗證碼不能為空。
    • 郵箱是否已注冊校驗：調用 checkEmailRegister 方法，判斷郵箱是否已被注冊。
    • 郵箱和驗證碼匹配校驗：在 emailService 中新增 checkEmailAndCode 方法，通過 Redis 獲取存儲的驗證碼并與用戶傳入的驗證碼進行比對。

  3. 數據存儲：

    • 注冊成功時，將郵箱地址存入數據庫用戶表中。

二、校驗流程

  1. 非空校驗：確保用戶名、密碼、郵箱和驗證碼均不為空。
  2. 郵箱注冊狀態校驗：防止重復注冊。
  3. 驗證碼匹配校驗：確保用戶提供的驗證碼與 Redis 中存儲的驗證碼一致。

三、驗證碼存儲選擇

  1. 為什么選擇 Redis 而不是數據庫：
    • 臨時性：驗證碼僅一次有效，注冊成功后即無作用，無需長期存儲。
    • 過期機制：Redis 提供方便的過期時間設置，自動處理驗證碼過期，而數據庫難以實現自動過期。

四、總結

通過升級注冊接口，增加郵箱和驗證碼參數及相關校驗，確保了用戶注冊流程的安全性和完整性。使用 Redis 存儲驗證碼，利用其過期機制，有效防止了惡意重復注冊和驗證碼濫用。整個流程包括發送驗證碼、校驗郵箱是否已注冊、驗證碼匹配校驗以及最終的用戶注冊，各步驟緊密銜接，確保了用戶注冊信息的準確性和系統安全性。

課程筆記：登錄狀態的保存和驗證

一、學習背景

在企業級權限認證中，登錄是第一步，不僅需要驗證用戶身份，還要保存登錄狀態，以便用戶后續操作時系統能夠識別其身份。

二、HTTP 無狀態特性

HTTP 協議是無狀態的，意味著每個請求都是獨立的，請求之間不攜帶狀態信息。即使前一個請求通過驗證，下一個請求仍需重新驗證。這要求我們采取措施保存憑證，以解決無狀態帶來的問題。

三、憑證保存機制

1. 第一次登錄驗證

用戶第一次登錄時，需要提供用戶名和密碼等信息進行嚴格的身份驗證。

2. Session 的創建

驗證通過后，服務器為用戶創建一個 Session，Session 是保存在服務器端的數據結構，用于跟蹤用戶狀態。

3. Cookie 的作用

服務器返回給客戶端一個 Cookie，其中包含 Session ID。客戶端（如瀏覽器）在后續請求中攜帶此 Cookie，服務器通過 Session ID 找到對應的 Session，從而識別用戶身份。

四、Session 和 Cookie 的工作流程

  1. 用戶發送登錄請求：包含用戶名和密碼。
  2. 服務器驗證并創建 Session：驗證通過后，生成 Session 并返回包含 Session ID 的 Cookie。
  3. 客戶端保存 Cookie：瀏覽器保存 Cookie，在后續請求中自動攜帶。
  4. 服務器識別用戶：通過 Cookie 中的 Session ID 找到對應的 Session，獲取用戶狀態和數據。

五、特殊情況處理

如果客戶端禁用 Cookie，可以采用 URL 重寫的方式，在每個請求的 URL 后附加必要的身份參數，以便服務器進行校驗。

六、總結

本小節介紹了登錄狀態保存和驗證的基本原理和流程，重點講解了 HTTP 無狀態特性下如何通過 Session 和 Cookie 解決用戶身份識別問題。下一個小節將深入探討 Session 的細節和應用。

課程筆記：深入理解Session

一、Session 的安全性

  1. 用戶空間的獨立性：

    • 每個用戶的Session空間是獨立的，即使使用相同的key存儲數據，也不會相互影響。
    • Tomcat會為每個用戶分配獨立的Session ID，每個Session ID對應自己的空間。

  2. Session ID 的生成規則：

    • 目標：保證唯一性，防止重復。
    • 方法：通常結合隨機數、當前時間（過濾大部分同時觸發的情況）和JVM的ID值（區分不同服務器）。

二、Session 劫持與防護

  1. Session 劫持：

    • 概念：攻擊者竊取用戶的Session ID，冒充用戶進行操作。
    • 風險：可能導致用戶數據泄露、被惡意操作等。

  2. 防護措施：

    • HttpOnly 標記：服務器告知客戶端，Session Cookie不允許通過前端代碼讀取，僅允許瀏覽器讀取。
    • Secure 標記：如果項目支持HTTPS，標記Session Cookie僅在HTTPS協議下傳輸。

三、Session 的缺點

  1. 擴展性差：

    • 分布式環境下，多臺機器需要同步和復制Session，處理復雜。

  2. 服務端存儲壓力：

    • 用戶量大時，存儲大量Session數據（無論在內存、Redis還是數據庫中）都會帶來挑戰。

四、實際操作演示

  1. Postman 測試流程：

    • 默認Cookie中包含Session ID，每個用戶的Session ID唯一。
    • 刪除Cookie后請求，服務端會創建新的Session并要求設置Cookie。
    • 設置Cookie后，后續請求攜帶該Session ID，服務端據此識別用戶。

  2. 瀏覽器中的Session Cookie：

    • 查看請求中的Cookie，包含JSession Cookie，代表用戶唯一標識。
    • 注意保護Session ID，防止泄露。

五、總結

Session用于保存用戶狀態，其安全性至關重要。通過理解Session的工作原理、Session ID的生成規則以及劫持與防護措施，可以更好地保障用戶數據安全。Session存在擴展性和存儲壓力的缺點，后續將學習JWT來克服這些問題。

課程筆記：JWT 介紹與原理

一、JWT 的重要性

  1. 獨特優勢：相比 Session 和 Cookie，JWT 有自身的特點和優勢。
  2. 項目應用：后續小節將把項目中原有的 Session 驗證方式升級為 JWT。

二、JWT 的基本概念

  1. 定義：JWT（JSON Web Token）是一種流行的用于網站身份驗證的認證方案。
  2. 官網：jwt.io ，提供調試工具用于編碼和解碼。

三、JWT 的組成

JWT 由三部分組成，每部分之間用英文半角句號（.）分隔：

  1. Header（頭部）：

    • 包含兩個功能：簽名算法和令牌類型。
    • 示例：{"alg": "HS256", "typ": "JWT"}，其中 alg 是簽名算法，typ 是令牌類型。

  2. Payload（消息體）：

    • 是 JWT 中最重要的部分，用于放置業務相關數據。
    • 示例：{"sub": "1234567890", "name": "John Doe", "iat": 1516239022}，其中 name 可改為用戶名、身份、用戶 ID 等。

  3. Signature（簽名）：

    • 用于驗證消息是否被更改過，保證數據安全。
    • 生成方式：將 Header 和 Payload 編碼后，用 Secret 進行簽名。

四、JWT 的生成與驗證

  1. 生成：

    • Header 和 Payload 分別經過 Base64 URL 編碼。
    • 使用 Secret 對編碼后的 Header 和 Payload 進行簽名，生成 Signature。
    • 三部分組合成完整的 JWT。

  2. 驗證：

    • 服務端解碼 JWT，驗證 Signature 的有效性。
    • 如果 Signature 無效，說明 JWT 被篡改。

五、Session 與 JWT 的對比

流程對比

  1. Session 流程：

    • 客戶端發起 HTTP 請求，服務端創建 Session，生成唯一的 Session ID。
    • 服務端要求客戶端保存 Session ID 到 Cookie。
    • 后續請求客戶端攜帶 Cookie，服務端通過 Session ID 識別用戶。

  2. JWT 流程：

    • 客戶端發起 HTTP 請求，服務端校驗用戶名和密碼。
    • 校驗通過后，服務端將用戶信息轉換為 JWT 并發送給客戶端。
    • 后續請求客戶端攜帶 JWT，服務端解碼 JWT 獲取用戶信息。

優缺點對比

  1. Session：

    • 優點：簡單方便，適合小規模網站。
    • 缺點：
      • 擴展性差：用戶量大時，分布式架構下存儲和同步 Session 成本高。
      • 需要存儲數據：服務端需為每個用戶開辟空間存儲 Session。

  2. JWT：

    • 優點：
      • 減少存儲開銷：服務端無需存儲用戶信息，直接將信息編碼到 JWT 中。
      • 可擴展性強：分布式架構下，各服務器可獨立校驗 JWT。
      • 可用于交換信息：直接攜帶用戶相關業務數據。
      • 防止篡改：簽名機制保證 JWT 的完整性。
    • 缺點：
      • 默認不加密：不適合保存敏感信息，如密碼。
      • 無法臨時廢止：一旦發出，無法主動使其失效，需設置合理過期時間。
      • 有效期評估難：過長或過短的過期時間都會帶來問題。
      • 網絡開銷高：相比 Session ID，JWT 字符串較長。

六、總結

JWT 憑借其減少存儲開銷和良好的擴展性，在互聯網公司中應用越來越廣泛。盡管存在一些缺點，但通過合理設置和使用，可以充分發揮其優勢。后續小節將進入 JWT 的實際開發應用。

課程筆記：項目實戰 - 用戶校驗從Session升級為JWT

一、項目實戰目標

將用戶校驗從傳統的Session Cookie升級為JWT。

二、主要修改內容

  1. 登錄接口升級：不再保存Session，改為在登錄時生成JWT Token并返回給用戶。
  2. 過濾器修改：包括用戶過濾器和管理員過濾器，以適應JWT校驗。
  3. 用戶獲取方式升級：調整從請求中獲取用戶信息的方式。

三、實戰步驟

1. 引入JWT依賴

在pom.xml中添加JWT依賴：

<dependency><groupId>com.off0</groupId><artifactId>java-jwt</artifactId><version>3.14.0</version>
</dependency>

手動刷新項目，確保依賴正確下載。

2. 修改登錄接口

(1) 引入必要的包和工具

確保項目中已引入JWT相關的包和工具。

(2) 來到UserController

找到login接口，準備進行改造。

(3) 保留原有登錄邏輯

保留用戶名和密碼的判空邏輯，以及通過用戶名和密碼獲取用戶信息的邏輯。

(4) 生成JWT Token

在原有登錄邏輯的基礎上，添加JWT Token的生成代碼：

// 定義算法
Algorithm algorithm = Algorithm.HMAC256(Constant.JWT_KEY);// 創建JWT
String token = JWT.create().withClaim(Constant.USERNAME, user.getUsername()).withClaim(Constant.USER_ID, user.getId()).withClaim(Constant.USER_ROW, user.getRow()).withExpiresAt(new Date(System.currentTimeMillis() + Constant.JWT_EXPIRE_TIME)).sign(algorithm);// 返回token
return APIResponse.success(token);

3. 定義常量

在Constant類中添加以下常量：

public static final String JWT_KEY = "your_secret_key"; // JWT密鑰
public static final String USERNAME = "username"; // 用戶名常量
public static final String USER_ID = "user_id"; // 用戶ID常量
public static final String USER_ROW = "user_row"; // 用戶行常量
public static final long JWT_EXPIRE_TIME = 1000L * 60 * 60 * 24 * 1000; // JWT過期時間（1000天）

四、總結

通過上述步驟，完成了將用戶校驗從Session升級為JWT的主要工作。登錄接口已改造為生成并返回JWT Token，后續請求中客戶端需將Token放在請求頭中，由服務器進行校驗。接下來，還需對過濾器和用戶獲取方式進行相應升級，以全面支持JWT校驗。

課程筆記：項目實戰 - JWT 校驗與過濾器升級

一、項目重啟與環境準備

  1. 重啟項目：清理緩存、刪除target目錄，重新生成項目文件。
  2. 解決包不存在問題：
    • 刷新Maven依賴，手動觸發下載。
    • 調整IDEA設置（打開override、importing選項，檢測JDK版本，配置process resources）。
    • 清空IDEA緩存（File -> Invalidate Caches）。

二、獲取JWT Token

  1. 測試新接口：使用用戶名和密碼調用login for jwt接口。
  2. 驗證Token：將返回的Token復制到jwt.io網站，解析查看內容是否包含用戶名、用戶ID、用戶角色和過期時間等信息。

三、過濾器升級

  1. 修改用戶過濾器：

    • 刪除原從Session獲取用戶信息的代碼。
    • 從請求頭獲取JWT Token（約定Header的Key為jwt token）。
    • 校驗Token：
      • 使用Algorithm.HMAC256(Constant.JWT_KEY)生成Algorithm對象。
      • 通過JWT.require(algorithm).build()生成Verifier。
      • 使用Verifier.verify(token)解碼Token，獲取用戶信息并設置到CurrentUser對象中。
    • 處理解碼異常：
      • Token過期異常（TokenExpiredException）。
      • Token解碼失敗異常（JWTDecodeException）。

  2. 完善用戶過濾器配置：

    • 修改方法名為user filter config。
    • 增加對更新用戶信息接口的攔截。

四、總結

完成了JWT Token的生成與校驗，以及過濾器的相應升級。用戶登錄后，通過在請求頭中攜帶JWT Token進行身份校驗，取代了原有的Session方式。在實際操作中，要注意處理Maven依賴和IDEA緩存等問題，確保項目順利運行。

本文來自互聯網用戶投稿，該文觀點僅代表作者本人，不代表本站立場。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。
如若轉載，請注明出處：http://www.pswp.cn/pingmian/72037.shtml
繁體地址，請注明出處：http://hk.pswp.cn/pingmian/72037.shtml
英文地址，請注明出處：http://en.pswp.cn/pingmian/72037.shtml

如若內容造成侵權/違法違規/事實不符，請聯系多彩編程網進行投訴反饋email:809451989@qq.com，一經查實，立即刪除！

相關文章

數據庫---sqlite3

數據庫---sqlite3

數據庫&#xff1a; 數據庫文件與普通文件區別: 1.普通文件對數據管理(增刪改查)效率低 2.數據庫對數據管理效率高,使用方便 常用數據庫: 1.關系型數據庫: 將復雜的數據結構簡化為二維表格形式 大型:Oracle、DB2 中型:MySql、SQLServer …
閱讀更多...
音視頻軟件工程師面試題

音視頻軟件工程師面試題

一、基礎知識 編解碼相關 H.264 和 H.265（HEVC）的主要區別是什么？視頻編解碼的基本流程是什么？關鍵技術有哪些？音頻編解碼（如 AAC、MP3、Opus）的區別和應用場景？什么是 B 幀、P 幀、I 幀？它們的作用是什么？ 流媒體協議RTMP、HTTP-FLV、HLS、WebRTC 的區別和應用場景…
閱讀更多...
【系統架構設計師】測試方法

【系統架構設計師】測試方法

目錄 1. 說明2. 靜態測試3. 動態測試4. 黑盒測試5. 白盒測試6. 灰盒測試7. 自動化測試8.例題8.1 例題1 1. 說明 1.軟件測試方法的分類有很多種&#xff0c;以測試過程中程序執行狀態為依據可分為靜態測試&#xff08;Static Testing&#xff0c;ST&#xff09;和動態測試&…
閱讀更多...
tomcat配置應用----server.xml文件具體配置

tomcat配置應用----server.xml文件具體配置

1.tomcat項目目錄 默認項目目錄&#xff1a;tomcat安裝目錄/webapps目錄 如上圖所示&#xff0c;在tomcat的項目目錄下有很多子文件夾&#xff0c;這些子文件夾中都有一個項目首頁。 如上圖所示&#xff0c;將來我們去使用IP加端口號的方式去訪問tomcat的時候&#xff0c;默認是…
閱讀更多...
Spring Boot 調用DeepSeek API的詳細教程

Spring Boot 調用DeepSeek API的詳細教程

目錄 前置準備步驟1&#xff1a;創建Spring Boot項目步驟2&#xff1a;配置API參數步驟3&#xff1a;創建請求/響應DTO步驟4&#xff1a;實現API客戶端步驟5&#xff1a;創建控制器步驟6&#xff1a;異常處理步驟7&#xff1a;測試驗證單元測試示例Postman測試請求 常見問題排查…
閱讀更多...
多維數據聚合方案：SQL GROUPING SETS深度解析

多維數據聚合方案：SQL GROUPING SETS深度解析

一、什么是GROUPING SETS&#xff1f; GROUPING SETS是SQL標準中的多維聚合運算符&#xff0c;允許在單個查詢中實現多維度組合的分組統計。相較于傳統UNION ALL方案&#xff0c;性能可提升3-10倍&#xff08;TPC-DS基準測試&#xff09;。 二、核心語法解析 SELECT column1,…
閱讀更多...
Excel中國式排名，3種方法！

Excel中國式排名，3種方法！

大家好&#xff0c;我是小魚。 什么是中國式排名呢&#xff1f; 舉個例子比如說公司一共有10名員工進行成績考核&#xff0c;如果9個人考核成績都是90分&#xff0c;你是89分&#xff0c;按照國際慣用的排名法則&#xff1a;9 個人考核成績并列第一&#xff0c;你第10名&…
閱讀更多...
哪些業務場景更適合用MongoDB？何時比MySQL/PostgreSQL好用？

哪些業務場景更適合用MongoDB？何時比MySQL/PostgreSQL好用？

哪些業務場景更適合用MongoDB&#xff1f;何時比MySQL/PostgreSQL好用&#xff1f; 就像淘寶的個性化推薦需要靈活調整商品標簽&#xff0c;MongoDB這種"變形金剛"式的數據庫&#xff0c;在處理以下三類中國特色業務場景時更具優勢&#xff1a; 一、動態數據就像&q…
閱讀更多...
深度解讀：OpenAI發布GPT-5的技術突破與商業影響

深度解讀：OpenAI發布GPT-5的技術突破與商業影響

引言 2025年2月&#xff0c;OpenAI正式發布GPT-5&#xff0c;這一被譽為“AI新紀元開篇之作”的模型&#xff0c;不僅實現了技術架構的顛覆性創新&#xff0c;更以免費開放策略引發行業地震。本文將從技術突破、商業影響、行業競爭格局及未來挑戰四個維度&#xff0c;全面解析…
閱讀更多...
網絡防火墻是什么有什么用_網絡防火墻：守護信息安全的重要屏障

網絡防火墻是什么有什么用_網絡防火墻：守護信息安全的重要屏障

網絡防火墻的基本概念 網絡防火墻是網絡安全領域的重要組成部分&#xff0c;它充當著內部網絡和外部網絡之間的安全防護層。防火墻能夠監控和控制進出網絡的數據流&#xff0c;只允許符合安全策略的信息通過&#xff0c;從而有效阻止潛在威脅的入侵。簡而言之&#xff0c;網絡…
閱讀更多...
C# WPF 串口通信

C# WPF 串口通信

C# WPF 串口通信 安裝依賴庫 安裝依賴庫 System.IO.Ports using System.Diagnostics; using System.IO.Ports; using System.Text; using System.Windows; using System.Windows.Controls; using System.Windows.Data; using System.Windows.Documents; using System.Windo…
閱讀更多...
【玩轉23種Java設計模式】結構型模式篇：組合模式

【玩轉23種Java設計模式】結構型模式篇：組合模式

軟件設計模式&#xff08;Design pattern&#xff09;&#xff0c;又稱設計模式&#xff0c;是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性、程序的重用性。 匯總目錄鏈接&…
閱讀更多...
如何選取合適的 NewRatio 值來優化 JVM 的垃圾回收策略

如何選取合適的 NewRatio 值來優化 JVM 的垃圾回收策略

目錄 一、垃圾回收模型簡介 &#xff08;一&#xff09;新生代&#xff08;Young Generation&#xff09; &#xff08;二&#xff09;老年代&#xff08;Old Generation&#xff09; &#xff08;三&#xff09;NewRatio 的作用與影響 &#xff08;四&#xff09;圖解&am…
閱讀更多...
Element Plus中的樹組件的具體用法（持續更新！）

Element Plus中的樹組件的具體用法（持續更新！）

const defaultProps {//子樹為節點對象的childrenchildren: children,//節點標簽為節點對象的name屬性label: name, } 屬性 以下是樹組件中的常用屬性以及作用&#xff1a; data&#xff1a;展示的數據&#xff08;數據源&#xff09; show-checkbox&#xff1a;節點是否可…
閱讀更多...
第十一屆藍橋杯單片機國賽

第十一屆藍橋杯單片機國賽

什么&#xff1f;4T模擬賽和省賽做起來輕輕松松&#xff1f;不妨來挑戰一下第十一屆國賽&#xff0c;這一屆的國賽居然沒考超聲波、串口通信&#xff01;只要你正確地理解了題目的意思&#xff0c;規避出題人挖的坑&#xff0c;拿個國一輕輕松松。 附件&#xff1a;第十一屆藍橋…
閱讀更多...
大彩串口屏開發 —— MODBUS通信

大彩串口屏開發 —— MODBUS通信

目 錄 Modbus通信方式 1 使用變量與協議設置方式 2 使用LUA腳本方式 3 兩者結合 Modbus通信 大彩串口屏可以采用三種方式實現與其它設備進行modbus通信和邏輯處理。 方式 1 使用變量與協議設置 步驟1 在協議設置里進行設置&#xff0c;包括開啟modbus協議&#xff0c;屏做為主…
閱讀更多...
【Linux docker】關于docker啟動出錯的解決方法。

【Linux docker】關于docker啟動出錯的解決方法。

無論遇到什么docker啟動不了的問題 就是 查看docker狀態sytemctl status docker查看docker日志sudo journalctl -u docker.service查看docker三個配置文件&#xff08;可能是配置的時候格式錯誤&#xff09;&#xff1a;/etc/docker/daemon.json&#xff08;如果存在&#xf…
閱讀更多...
怎么實現： 大語言模型微調案例

怎么實現： 大語言模型微調案例

怎么實現： 大語言模型微調案例 目錄 怎么實現： 大語言模型微調案例輸入一個反常識的問題：首都在北京天安門之后對輸出模型進行測試：首都在北京天安門微調代碼：測試微調模型代碼：微調輸出模型結構輸出模型參數大小對比Qwen 2.5_0.5:53MB輸出模型：951MB 是一樣的，沒有進行…
閱讀更多...
rdiff-backup備份

rdiff-backup備份

目錄 1. 服務器備份知識點 1.1 備份策略 1.2 備份步驟和寶塔面板簡介 1.3 CentOS7重要目錄 2. 備份工具 2.1 tar -g 備份演示 2. rsync 備份演示 3. rdiff-backup 備份演示 4. 差異和優缺點 3. rdiff-backup安裝和使用 3.1 備份命令rdiff-backup 3.2 恢復命令--…
閱讀更多...
Claude：AI領域的多面手，從語言模型到智能編碼

Claude：AI領域的多面手，從語言模型到智能編碼

文章目錄 引言Claude的起源與發展1. Claude的誕生2. Claude 3.7 Sonnet的突破 版本迭代技術原理Claude的獨特優勢混合推理模式成本與性能的平衡開發者友好的工具 功能及應用Claude的未來展望結論 引言 Claude是由Anthropic公司開發的大型語言模型&#xff0c;在人工智能領域&a…
閱讀更多...
最新文章

Copyright @ 2022~2023