HTTP 緩存策略：強緩存與協商緩存的深入解析

在HTTP緩存策略中，強緩存和協商緩存是兩種常用的機制，用于減少數據傳輸和提高網頁加載速度。它們通過在客戶端和服務器之間建立緩存來避免不必要的網絡請求，從而優化性能并提高用戶體驗。本文將詳細介紹這兩種緩存策略的原理、優勢和適用場景，并提供一些最佳實踐建議。

?強緩存(Strong Cache / Local Cache)

強緩存是一種預先設定緩存時間的機制，允許瀏覽器在設定的時間內直接使用本地緩存數據，而無需向服務器發送請求。強緩存通過在HTTP響應頭中設置Expires和Cache-Control字段來實現。

核心理念

"不用問服務器，直接用自己的！" 瀏覽器在發起請求前，先檢查本地是否有緩存副本，并判斷該副本是否還在有效期內。如果有效，則完全不發送任何請求到服務器，直接從本地緩存中讀取資源。這是速度最快、對服務器壓力最小的緩存方式。

實現方式

主要通過 HTTP 響應頭設置有效期,即HTTP Header 中的 Expires 或 Cache-Control

Expires字段

指定資源的過期時間，是一個絕對時間點。例如：Expires: Wed, 21 Oct 2023 07:28:00 GMT。

該字段指定了緩存數據的過期時間，瀏覽器在過期時間之前不會向服務器發送請求。

需要注意的是，Expires字段基于服務器的時間，因此如果服務器時間不準確，可能會導致緩存失效。

Cache-Control字段

該字段提供了更強大和靈活的緩存控制功能。

通過設置不同的指令，如max-age、no-cache、no-store等，可以控制緩存的行為。

其中，max-age指令指定了緩存數據的最大有效期，no-cache指令表示需要向服務器進行驗證，而no-store指令則禁止瀏覽器存儲任何數據。

常用的屬性有 max-age，以秒為單位指定資源的有效期。例如：Cache-Control: max-age=31536000 表示資源在 31536000 秒內（1 年）有效。

強緩存的優勢在于它能夠顯著減少不必要的網絡請求，提高網頁加載速度。

然而，它也存在一些局限性。例如，當緩存數據過期時，瀏覽器仍然需要向服務器發送請求進行驗證。此外，對于動態內容或需要根據用戶個性化設置的內容，強緩存可能不是最佳選擇。

強緩存案例

📌瀏覽器發起請求

1.用戶訪問頁面需要加載 logo.png

2.示例請求: GET /static/logo.png

📌檢查緩存頭

// 可能的響應頭示例
HTTP/1.1 200 OK
Cache-Control: max-age=31536000  // 1年有效期
Expires: Wed, 21 Oct 2026 07:28:00 GMT
Content-Type: image/png

📌緩存驗證決策樹

📌強緩存命中場景

? 內存緩存: Status: 200 (from memory cache)
(小文件/高頻訪問資源)

? 磁盤緩存: Status: 200 (from disk cache)
(大文件/低頻訪問資源)

📌強緩存未命中場景

? 首次訪問: 無緩存記錄

? 緩存過期: max-age/Expires超時

? 用戶強制刷新: Ctrl+F5

📌關鍵特征流程

1.時間軸對比
資源獲取時間點: [2025-06-14 10:00:00]
max-age: 31536000秒 (1年)
────●───────────────────────────────●────> 時間線獲取時間                        過期時間2025-06-14 10:00:00            2026-06-14 10:00:00
2.緩存位置區分
┌──────────────────────────┐
│       Memory Cache       │
│  (高頻訪問的小資源)        │
│  ● logo.png (10KB)       │
│  ● user-avatar.png (5KB) │
└──────────┬───────────────┘│
┌──────────▼───────────────┐
│        Disk Cache        │
│  (低頻訪問的大資源)        │
│  ● banner.jpg (2MB)      │
│  ● video-intro.mp4 (8MB) │
└──────────────────────────┘
3.HTTP頭對比表
類型示例值優先級
Cache-Controlmax-age=31536000, public高
ExpiresWed, 21 Oct 2026 07:28:00 GMT低
4.強緩存完整流程圖

?協商緩存

協商緩存是一種基于請求和響應的緩存機制，允許瀏覽器和服務器根據特定的規則和條件來確定是否使用緩存數據。協商緩存通過在HTTP請求和響應頭中設置Etag和If-None-Match字段來實現。

協商緩存是在緩存過期后，瀏覽器發送請求到服務器，由服務器根據請求頭中的特定字段判斷資源是否更新。如果資源未更新，服務器返回?304 Not Modified，瀏覽器繼續使用本地緩存

協商緩存核心理念

?"問問服務器，我本地的這個副本還能不能用？" 當強緩存失效（過期）或者響應頭明確要求使用協商緩存（如?Cache-Control: no-cache）時，瀏覽器會向服務器發送一個請求。但這個請求不是直接要求完整資源，而是攜帶一些“驗證令牌”，詢問服務器：我本地這個版本還新鮮嗎？?如果服務器判斷資源沒變，就返回一個輕量級的?304 Not Modified?響應，告訴瀏覽器“直接用你本地的吧！”；如果資源變了，服務器就返回完整的?200 OK?響應和新資源。

💡協商緩存目標

在強緩存失效或不可用時，避免傳輸未修改資源的完整內容，只傳輸必要的頭信息，節省帶寬

💡協商緩存實現方式

HTTP Header 中的 Last-Modified / If-Modified-Since 和 ETag / If-None-Match。
Last-Modified / If-Modified-Since：

Last-Modified

服務器在響應中返回資源的最后修改時間。


If-Modified-Since

瀏覽器在請求中攜帶上次的 Last-Modified 值，服務器根據此值判斷資源是否更新。

Etag字段

該字段是一個由服務器生成的唯一標識符，用于標識緩存數據的版本。當客戶端向服務器發送請求時，它會將Etag值包含在If-None-Match字段中。如果服務器判斷客戶端的Etag值與當前數據版本不一致，則會返回新的數據；否則，服務器會返回一個304 Not Modified狀態碼，表示客戶端可以使用本地緩存數據。

If-None-Match字段

該字段用于在客戶端向服務器發送請求時傳遞Etag值。通過比較客戶端和服務器的Etag值，服務器可以決定是否返回新的數據或讓客戶端使用本地緩存數據。

協商緩存的優勢在于它能夠更好地處理動態內容和用戶個性化設置。

當數據發生更改時，服務器會返回新的Etag值，從而更新客戶端的緩存數據。此外，協商緩存還支持多級緩存代理的使用，提高了緩存的效率和可靠性。

如果資源未修改，服務器返回?304，瀏覽器使用緩存,如果資源已修改，服務器返回?200?和新的資源內容

協商緩存案例

📌驗證流程

📌HTTP頭交互示例

首次請求響應頭：
HTTP/1.1 200 OK
ETag: "abc123"
Last-Modified: Wed, 21 Oct 2025 07:28:00 GMT
Cache-Control: no-cache
Content-Type: application/json
條件請求頭：
GET /api/data.json HTTP/1.1
If-None-Match: "abc123"
If-Modified-Since: Wed, 21 Oct 2025 07:28:00 GMT

📌狀態碼說明

┌────────────┬─────────────────────────────────────┐
│  狀態碼    │ 含義                                │
├────────────┼─────────────────────────────────────┤
│   304     │ 資源未修改，節省帶寬                 │
│            │ 響應頭會更新緩存有效期               │
├────────────┼─────────────────────────────────────┤
│   200     │ 資源已修改，返回完整數據              │
│            │ 更新本地緩存                        │
└────────────┴─────────────────────────────────────┘

?📌時間線示意圖

客戶端緩存時間軸：
[獲取資源]           [條件請求]2025-10-21 10:00    2025-10-22 10:00│                   │└─────未修改────────┘服務器修改時間軸：
[最后修改時間]        [當前時間]2025-10-21 07:28    2025-10-22 07:28│                   │└─────未觸發更新─────┘

📌協商緩存完整流程圖

協商緩存性能提示

+-----------------------------+
| 協商緩存優化點：              |
| 1. 304響應僅傳輸約300B的頭信息 |
| 2. 200響應平均節省60%帶寬      |
|    (相比無緩存重復傳輸完整數據) |
+-----------------------------+

?強緩存和協商緩存關鍵點對比

關鍵區別總結

特性強緩存 (Strong Cache)協商緩存 (Conditional Cache)
是否發請求不發請求?(直接本地讀取)發請求?(帶驗證頭詢問服務器)
目標完全避免網絡交互避免傳輸未修改資源的完整內容 (節省帶寬)
關鍵頭Cache-Control?(max-age,?public,?private,?immutable),?ExpiresLast-Modified?/?If-Modified-Since,?ETag?/?If-None-Match
狀態碼200 (from disk/memory cache)304 (Not Modified) 或 200 (OK)
速度最快?(零延遲)較快?(有驗證請求的延遲，但比傳輸完整資源快)
服務器壓力最小?(無請求)較低?(處理輕量級驗證請求)
更新及時性較低?(過期前用戶看不到更新)較高?(每次過期都會檢查服務器)
典型配置Cache-Control: max-age=31536000, immutable?(帶哈希的靜態資源)Cache-Control: no-cache?或?Cache-Control: max-age=0?+?ETag?(需要及時更新的資源)

HTTP 狀態碼可視化

+-------------------+---------------------+
|     狀態碼        |      含義           |
+-------------------+---------------------+
| 200 (from cache) | 強緩存命中           |
|      304         | 協商緩存未修改       |
|      200         | 全新資源            |
+-------------------+---------------------+

緩存頭作用域

┌───────────────────────────────────────┐
│          Cache-Control 指令           │
├──────────────┬────────────────────────┤
│   public     │ 允許所有緩存           │
│   private    │ 僅瀏覽器緩存           │
│   max-age=3600 │ 緩存1小時            │
│   immutable  │ 永久強緩存             │
│   no-cache   │ 強制協商緩存           │
│   no-store   │ 禁用所有緩存           │
└──────────────┴────────────────────────┘

?緩存位置 (Disk Cache vs. Memory Cache)

當瀏覽器決定使用緩存（無論是強緩存還是協商緩存后的 304）時，資源可能來自：

  • Memory Cache (內存緩存)：

    • 存儲位置： RAM。

    • 特點： 讀取極快，但容量小，生命周期短（隨 Tab 關閉或進程結束而釋放）。

    • 常見資源： 當前導航中已下載的子資源（腳本、樣式、圖片），特別是較小的、高頻訪問的資源。開發者工具中顯示?(from memory cache)。

  • Disk Cache (磁盤緩存)：

    • 存儲位置： 硬盤。

    • 特點： 讀取相對慢（但仍遠快于網絡），容量大，生命周期長（可跨會話、跨重啟）。

    • 常見資源： 大文件（如較大的 JS/CSS、圖片、字體）、訪問頻率較低的文件、設置了長時間?max-age?或?immutable?的文件。開發者工具中顯示?(from disk cache)?或?(from ServiceWorker)（如果通過 Service Worker 緩存）。

瀏覽器根據自身算法（資源大小、使用頻率、可用內存等）決定將資源放入 Memory Cache(內存緩存) 還是 Disk Cache(磁盤緩存)。開發者通常無法直接控制。

在實際應用中，強緩存和協商緩存可以結合使用，以充分利用它們的優點。例如，對于靜態資源（如圖片、CSS和JavaScript文件），可以使用強緩存來減少不必要的網絡請求；而對于動態內容和用戶個性化設置，可以使用協商緩存來確保數據的實時性和準確性。

?實踐建議與注意事項

對靜態資源使用強緩存 + 內容哈希：?這是性能優化的黃金法則。給文件名添加內容哈希（如?app.[contenthash:8].js）。設置很長的?max-age?(如一年?max-age=31536000) 或?immutable。文件內容變，哈希變，URL變，瀏覽器自動請求新文件。

對 HTML 文件謹慎使用強緩存：?HTML 是入口文件，通常需要及時更新。可以：

設置較短的?max-age?(如幾分鐘?max-age=300) 或?no-cache?+?ETag。這樣用戶刷新能看到更新。

或者完全?no-store?(但犧牲了性能)。

或者利用服務器配置（如 nginx 的?expires -1）設置?Cache-Control: no-cache。

優先使用?Cache-Control?而非?Expires：?max-age?更精確可靠。

優先使用?ETag?而非?Last-Modified：?ETag?更精確，能避免時間戳問題。

理解?no-cache?和?no-store?的區別：?no-cache?不是不緩存，是強制驗證。no-store?才是真正的不緩存。

利用?Vary?頭處理內容協商：?如果資源內容會根據請求頭（如?Accept-Language,?User-Agent) 變化，使用?Vary?頭告知緩存系統哪些請求頭會影響響應內容。例如?Vary: User-Agent。

調試工具：?瀏覽器開發者工具 (F12) 的?Network?面板是調試緩存行為的關鍵：

查看請求和響應的完整 Headers (Cache-Control,?ETag,?Last-Modified,?Expires)。

觀察?Status?列 (200,?304,?200 (from cache))。

觀察?Size?列 ((from disk cache),?(from memory cache), 實際字節數)。

勾選?Disable cache?選項可完全禁用緩存（用于開發調試）。

服務器配置：?緩存策略主要在服務器端配置（Web 服務器如 Nginx/Apache，或應用框架中間件）。

Nginx 配置靜態資源強緩存示例：

location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ {expires 1y; # 設置 Expires 頭 (一年)add_header Cache-Control "public, max-age=31536000, immutable"; # 更優的 Cache-Control
}

Nginx 配置 HTML 協商緩存示例：

location / {# ... other config ...add_header Cache-Control "no-cache"; # 或 max-age=0etag on; # 啟用 ETag 生成# 通常 also_last_modified on; 是默認的，但明確 ETag 優先
}

用戶行為影響：

  • 正常導航/跳轉：?遵循緩存策略。

  • 地址欄回車：?瀏覽器通常會發送請求，可能觸發協商緩存 (If-None-Match/If-Modified-Since)，但可能使用較新的本地緩存副本（如果可用且未過期）。

  • 刷新 (F5 / Ctrl+R / 瀏覽器刷新按鈕)：?瀏覽器通常會發送請求，且可能在請求頭中添加?Cache-Control: max-age=0?或?Pragma: no-cache，跳過強緩存檢查，直接觸發協商緩存。

  • 強制刷新 (Ctrl+F5 / Cmd+Shift+R / 清除緩存并硬性重新加載)：?瀏覽器在請求頭中添加?Cache-Control: no-cache?和?Pragma: no-cache，跳過所有緩存（強緩存和協商緩存），強制從服務器下載完整新資源。同時清除當前頁面的本地緩存（僅對該次請求有效）

使用順序

  1. 瀏覽器首先查看資源是否命中強緩存，如果命中則直接使用緩存，不發送請求。
  2. 如果強緩存未命中，瀏覽器會發送請求到服務器，進入協商緩存流程。
  3. 服務器根據請求頭判斷資源是否更新，返回?304?或新的資源。
  4. 瀏覽器根據服務器響應，決定使用緩存或更新緩存。

?對比總結

通過理解強緩存和協商緩存的原理、優勢和適用場景，我們可以更好地優化網頁性能和改善用戶體驗。在實際應用中，根據不同的需求選擇合適的緩存策略是非常重要的。

對于靜態資源，強緩存是一種有效的優化手段；

而對于動態內容和用戶個性化設置，協商緩存則提供了更好的解決方案。

同時，結合使用這兩種緩存策略可以進一步提高網頁加載速度和響應能力。

  • 強緩存：?快如閃電，過期前不問服務器。靠?Cache-Control?(尤其是?max-age) 和?Expires?控制。

  • 協商緩存：?過期后問服務器“還能用嗎？”。靠?ETag/If-None-Match?(推薦) 和?Last-Modified/If-Modified-Since?配合工作。304 表示能用，200 表示要下載新的。

  • 核心策略：?帶指紋（內容哈希）的靜態資源用強緩存（長 max-age/immutable），HTML 文件用協商緩存（no-cache + ETag）。

  • 調試：?瀏覽器 Network 面板是你的好朋友。

  • 配置：?在服務器端（Nginx/Apache/應用服務器）設置正確的響應頭

?????????HTTP 狀態碼與緩存類型對照表

強緩存和協商緩存在瀏覽器開發者工具中的可視化差異對比

特征項強緩存 (200 from cache)協商緩存 (304 Not Modified)
狀態碼顯示200?(灰色) 且顯示?(from disk cache)?或?(from memory cache)304?(淺藍色)
Size 列顯示緩存來源
（如?disk cache/memory cache）		顯示實際傳輸大小
（通常幾百字節，僅頭信息）
請求頭無?If-None-Match/If-Modified-Since必含以下之一：
??If-None-Match: <ETag>
??If-Modified-Since: <時間>
響應頭無?ETag/Last-Modified（直接從本地讀取）包含：
??ETag（即使未修改）
??Last-Modified（即使未修改）
時間消耗0ms（無網絡請求）幾毫秒~幾百毫秒（僅驗證請求）
Waterfall 瀑布流無請求條目（或顯示灰色短條）顯示完整請求條，但傳輸量極短
觸發條件Cache-Control: max-age?未過期Cache-Control: no-cache?或強緩存過期

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

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

相關文章

Node.js 中的 Token 認證機制詳解

Node.js 中的 Token 認證機制詳解

文章目錄 Node.js 中的 Token 認證機制詳解1. Token 認證基礎1.1 什么是 Token 認證&#xff1f;1.2 Token 認證流程 2. JWT (JSON Web Token) 實現2.1 安裝依賴2.2 生成 Token2.3 驗證 Token 中間件 3. 完整實現示例3.1 登錄接口3.2 受保護的路由 4. Token 安全最佳實踐5. Tok…
閱讀更多...
23 - HaLoAttention模塊

23 - HaLoAttention模塊

論文《Scaling Local Self-Attention for Parameter Efficient Visual Backbones》 1、作用 HaloNet通過引入Haloing機制和高效的注意力實現&#xff0c;在圖像識別任務中達到了最先進的準確性。這些模型通過局部自注意力機制&#xff0c;有效地捕獲像素間的全局交互&#xf…
閱讀更多...
2025Mybatis最新教程（五）

2025Mybatis最新教程（五）

第5章 ORM映射 5.1 MyBatis自動ORM失效 MyBatis只能自動維護庫表”列名“與”屬性名“相同時的對應關系，二者不同時，無法自動ORM。 自動ORM失效建表 create table t_managers(mgr_id int primary key auto_increment,mgr_name varchar(50),mgr_pwd varchar(50) ); 添加數據…
閱讀更多...
解決lombok注解失效問題

解決lombok注解失效問題

Lombok 注解失效是 Java 開發中的常見問題&#xff0c;通常由依賴配置、IDE 支持或構建工具設置引起。最近在拉取別人springboot3jdk21版本的項目時遇到了lombok注解失效&#xff0c;導致項目無法啟動的問題&#xff0c;以下是我的解決方案&#xff1a; 首先檢查idea 的lombok…
閱讀更多...
3分鐘搭建LarkXR實時云渲染PaaS平臺，實現各類3D/XR應用的一鍵推流

3分鐘搭建LarkXR實時云渲染PaaS平臺，實現各類3D/XR應用的一鍵推流

LarkXR是由Paraverse平行云自主研發的去中心化實時云渲染平臺&#xff0c;以其卓越的性能和豐富完備的功能插件&#xff0c;引領3D/XR云化行業風向標。LarkXR適用于3D/XR開發者、設計師、終端用戶等創新用戶&#xff0c;可以在零硬件負擔下&#xff0c;輕松實現超高清低時延的3…
閱讀更多...
vue3 watch監視詳解

vue3 watch監視詳解

watch監視 一 &#xff1a;watch監視{ref}定義的基本類型結構 <template><div class"person"><h1>情況一:watch監視{ref}定義的基本類型結構</h1><h1>當前的和為{{ sum }}</h1><button click"changeSum">點我…
閱讀更多...
TensorFlow Serving學習筆記2: 模型服務

TensorFlow Serving學習筆記2: 模型服務

本文深入剖析 TensorFlow Serving 的核心架構與實現機制&#xff0c;結合源碼分析揭示其如何實現高可用、動態更新的生產級模型服務。 一、TensorFlow Serving 核心架構 1.1 分層架構設計 TensorFlow Serving 采用模塊化分層設計&#xff0c;各組件職責分明&#xff1a; 組件…
閱讀更多...
共享云桌面為什么能打敗傳統電腦

共享云桌面為什么能打敗傳統電腦

近年來&#xff0c;隨著云桌面技術的快速發展&#xff0c;共享云桌面作為一種新型的計算模式&#xff0c;正在逐步改變人們的工作和生活方式。它憑借其獨特的優勢&#xff0c;正在逐步取代傳統電腦&#xff0c;成為企業和個人用戶的新選擇。之所以在部分場景中展現出替代傳統電…
閱讀更多...
B站PWN教程筆記-12

B站PWN教程筆記-12

完結撒花。 今天還是以做題為主。 fmtstruaf 格式化字符串USER AFTER FREE 首先補充一個背景知識&#xff0c;指針也是有數據類型的&#xff0c;不同數據類型的指針xx&#xff0c;所加的字節數也不一樣&#xff0c;其實是指針指的項目的下一項。如int a[20]&#xff0c;a是…
閱讀更多...
零基礎設計模式——總結與進階 - 3. 學習資源與下一步

零基礎設計模式——總結與進階 - 3. 學習資源與下一步

第五部分&#xff1a;總結與進階 - 3. 學習資源與下一步 到這里&#xff0c;你已經完成了設計模式主要內容的學習。但這僅僅是一個開始&#xff0c;設計模式的精髓在于實踐和持續學習。本節將為你提供一些優質的學習資源和后續學習的建議&#xff0c;幫助你在這條道路上走得更…
閱讀更多...
多模態大語言模型arxiv論文略讀（125）

多模態大語言模型arxiv論文略讀（125）

Uni-Med: A Unified Medical Generalist Foundation Model For Multi-Task Learning Via Connector-MoE ?? 論文標題&#xff1a;Uni-Med: A Unified Medical Generalist Foundation Model For Multi-Task Learning Via Connector-MoE ?? 論文作者&#xff1a;Xun Zhu, Yi…
閱讀更多...
【學習筆記】NLP 基礎概念

【學習筆記】NLP 基礎概念

1.1 什么是 NLP 定義&#xff1a; 自然語言處理&#xff08;NLP&#xff09;**是一種讓計算機理解、解釋和生成人類語言的技術。它是人工智能領域中極為活躍且重要的研究方向&#xff0c;旨在模擬人類對語言的認知和使用過程 特點&#xff1a; 多學科交叉&#xff1a;結合計…
閱讀更多...
RNN為什么不適合大語言模型

RNN為什么不適合大語言模型

在自然語言處理&#xff08;NLP&#xff09;領域中&#xff0c;循環神經網絡&#xff08;RNN&#xff09;及衍生架構&#xff08;如LSTM&#xff09;采用序列依序計算的模式&#xff0c;這種模式之所以“限制了計算機并行計算能力”&#xff0c;核心原因在于其時序依賴的特性&a…
閱讀更多...
微信小程序一款不錯的文字動畫

微信小程序一款不錯的文字動畫

效果圖 .js Page({data: {list:[],animation:[text-left,text-right,text-top,text-bottom],text:[[春眠不覺曉&#xff0c;處處聞啼鳥。,夜來風雨聲&#xff0c;花落知多少。 ],[床前明月光&#xff0c;疑是地上霜。,舉頭望明月&#xff0c;低頭思故鄉。],[千山鳥飛絕&#…
閱讀更多...
循環神經網絡（RNN）：序列數據處理的強大工具

循環神經網絡（RNN）：序列數據處理的強大工具

在人工智能和機器學習的廣闊領域中&#xff0c;處理和理解序列數據一直是一個重要且具有挑戰性的任務。循環神經網絡&#xff08;Recurrent Neural Network&#xff0c;RNN&#xff09;作為一類專門設計用于處理序列數據的神經網絡&#xff0c;在諸多領域展現出了強大的能力。從…
閱讀更多...
手機SIM卡通話中隨時插入錄音語音片段（Windows方案）

手機SIM卡通話中隨時插入錄音語音片段（Windows方案）

手機SIM卡通話中隨時插入錄音語音片段&#xff08;Windows方案&#xff09; --本地AI電話機器人 上一篇&#xff1a;手機SIM卡通話中隨時插入錄音語音片段&#xff08;Android方案&#xff09;??????? 下一篇&#xff1a;???????編寫中 一、前言 書接上文《手…
閱讀更多...
阿里云通義大模型：AI浪潮中的領航者

阿里云通義大模型：AI浪潮中的領航者

通義大模型初印象 在當今 AI 領域蓬勃發展的浪潮中&#xff0c;阿里云通義大模型宛如一顆璀璨的明星&#xff0c;迅速崛起并占據了重要的地位。隨著人工智能技術的不斷突破&#xff0c;大模型已成為推動各行業數字化轉型和創新發展的核心驅動力。通義大模型憑借其強大的技術實…
閱讀更多...
【算法篇】逐步理解動態規劃模型7（兩個數組dp問題）

【算法篇】逐步理解動態規劃模型7（兩個數組dp問題）

目錄 兩個數組dp問題 1.最長公共子序列 2.不同的子序列 3.通配符匹配 本文旨在通過對力扣上三道題進行講解來讓大家對使用動態規劃解決兩個數組的dp問題有一定思路&#xff0c;培養大家對狀態定義&#xff0c;以及狀態方程書寫的思維。 順序&#xff1a; 題目鏈接-》算法思…
閱讀更多...
什么是 HTTP Range 請求（范圍請求）

什么是 HTTP Range 請求（范圍請求）

HTTP Range 請求&#xff0c;即范圍請求&#xff0c;是一種 HTTP 請求方法&#xff0c;允許客戶端請求資源的部分數據。這種請求在處理大型文件&#xff08;如視頻、音頻、或大文件下載&#xff09;時特別有用&#xff0c;因為它可以有效地進行斷點續傳和按需加載數據&#xff…
閱讀更多...
java集合（十） ---- LinkedList 類

java集合（十） ---- LinkedList 類

目錄 十、LinkedList 類 10.1 位置 10.2 特點 10.3 與 ArrayList 的區別 10.4 構造方法 10.5 常用方法 十、LinkedList 類 10.1 位置 LinkedList 類位于 java.util 包下 10.2 特點 是 List 接口的實現類是 Deque 接口的實現類底層使用雙向循環鏈表結構 10.3 與 Arra…
閱讀更多...
最新文章

Copyright @ 2022~2023