H5 本地缓存策略：Cache API基础
1. 引言
在当今高度依赖网络连接的Web应用中，用户对 离线可用性 和 快速加载 的需求日益增长。无论是移动端还是桌面端，网络波动（如地铁隧道中的Wi-Fi中断）、弱网环境（如偏远地区的低速移动网络）或主动离线操作（如用户关闭网络节省流量）都可能导致Web应用无法正常访问服务器资源（如HTML页面、图片、API响应），进而影响用户体验。
H5 Cache API（全称 Cache Storage API）正是为解决这一痛点而生，它是HTML5提供的一种 客户端网络资源缓存机制，允许开发者将特定的HTTP请求（如页面、图片、脚本）及其响应（如HTML内容、二进制数据）存储在浏览器本地。当用户再次发起相同请求时，浏览器可直接从本地缓存中返回响应，无需重新访问服务器，从而实现 离线可用、快速加载和网络弹性 的核心目标。
Cache API不仅是 Progressive Web App (PWA) 的三大核心技术之一（另两个是 Service Worker 和 Web App Manifest），也是现代Web应用优化性能、提升用户体验的基础工具。本文将深入讲解Cache API的基础技术，涵盖其应用场景、代码实现、原理解析及实践指南，并探讨其未来趋势与挑战。
2. 技术背景
2.1 为什么需要Cache API？
-
离线场景的刚需：
用户期望Web应用在无网络时仍能提供基础功能（如查看已缓存的文章、使用离线地图导航）。例如，新闻类应用需要缓存最新的新闻列表和文章内容，以便用户在地铁中离线阅读；电商应用需要缓存商品详情页和图片，避免用户因网络中断无法浏览商品。
-
网络性能优化：
即使在网络正常的情况下，重复请求相同的静态资源（如网站的Logo图片、公共CSS/JS文件）会浪费带宽并增加加载延迟。通过Cache API缓存这些资源，后续请求可直接从本地返回，显著减少服务器负载并提升页面加载速度（尤其是移动端弱网环境）。
-
动态内容的可控缓存：
除了静态资源（如图片、字体），Cache API还支持缓存动态生成的响应（如API返回的JSON数据、个性化页面内容）。开发者可以通过策略控制哪些动态内容需要缓存（如用户个人中心的配置信息），哪些需要实时获取（如最新的订单状态）。
2.2 核心概念
|
概念 |
说明 |
类比 |
|---|---|---|
|
Cache API |
一种浏览器提供的本地网络资源缓存机制，允许开发者存储HTTP请求及其响应（如页面、图片、API数据），并在后续请求时优先返回缓存内容。 |
类似浏览器的“智能硬盘缓存”——自动存储常用资源，下次访问时直接读取本地副本。 |
|
缓存存储（Cache Storage） |
一个全局的缓存管理对象（通过 |
类似文件系统中的“文件夹”，每个Cache是一个独立的“存储桶”，用于存放特定类型的资源。 |
|
缓存（Cache） |
一个具体的缓存集合，存储一组HTTP请求-响应对（如 |
类似文件夹中的“文件集合”，每个Cache存储特定用途的资源（如静态资源、API响应）。 |
|
请求（Request） |
表示一个HTTP请求（包含URL、方法、头部等信息），是缓存的键（Key）。通过匹配请求的URL和方法（如GET），Cache API可以快速定位对应的缓存响应。 |
类似文件的“唯一标识符”（如URL+请求方法），用于精确查找缓存内容。 |
|
响应（Response） |
表示一个HTTP响应（包含状态码、头部、正文内容），是缓存的值（Value）。缓存的响应可以是静态资源（如图片二进制数据）或动态内容（如API返回的JSON）。 |
类似文件的“实际内容”，存储了请求对应的原始数据。 |
|
缓存策略 |
开发者定义的规则，决定何时缓存资源（如“仅缓存GET请求”）、何时使用缓存（如“优先返回缓存，失败再请求网络”）、何时更新缓存（如“网络响应更新后同步缓存”）。 |
类似“缓存规则手册”——规定哪些资源需要缓存、如何更新以及何时使用缓存。 |
2.3 应用使用场景
|
场景类型 |
Cache API示例 |
技术价值 |
|---|---|---|
|
PWA离线页面加载 |
将PWA的首页（如 |
实现真正的离线可用，提升用户在无网络环境下的体验。 |
|
静态资源加速 |
缓存网站的公共静态资源（如Bootstrap框架的CSS/JS、字体文件、公司Logo），后续页面加载时直接从本地返回这些资源，减少服务器请求和加载时间。 |
优化页面加载速度，尤其对移动端弱网环境效果显著。 |
|
API响应缓存 |
缓存用户个人中心的配置信息（如主题设置、语言偏好），或低频更新的API数据（如城市列表），避免每次访问都请求服务器，降低延迟并减少流量消耗。 |
提升动态内容的响应速度，平衡实时性与性能。 |
|
图片/视频预加载 |
提前缓存用户可能访问的图片（如电商商品详情页的轮播图）或视频缩略图，当用户点击查看时，直接从本地显示，避免等待网络加载。 |
改善多媒体内容的用户体验，减少等待时间。 |
|
网络弹性设计 |
当网络请求失败（如服务器宕机或超时），Service Worker通过Cache API返回缓存的旧版本资源（如旧版文章内容），确保用户仍能看到基本内容，而非空白页面。 |
增强应用的健壮性，避免因网络问题导致功能完全不可用。 |
3. 应用使用场景
3.1 场景1：PWA离线首页加载（核心资源缓存）
-
需求：开发一个PWA应用，要求用户在无网络时仍能访问首页（
/index.html），并显示基本的导航栏和“离线模式”提示。通过Cache API缓存首页及其依赖的CSS/JS文件，Service Worker在网络不可用时直接返回缓存的资源。
3.2 场景2：静态资源加速（公共文件缓存）
-
需求：网站的公共静态资源（如Bootstrap的CSS/JS、自定义字体文件、Logo图片）被多个页面复用。通过Cache API将这些资源缓存到本地，后续所有页面加载时直接从本地返回，减少服务器请求和加载延迟。
3.3 场景3：API响应缓存（动态内容优化）
-
需求：用户个人中心的配置信息（如主题颜色、通知开关）通过API获取，但该数据低频更新（如每天仅修改一次）。通过Cache API缓存API响应，后续请求优先返回缓存内容，若缓存过期（如超过24小时）再请求网络更新。
4. 不同场景下的详细代码实现
4.1 环境准备
-
开发工具：任意支持HTML5的现代浏览器（Chrome、Firefox、Edge、Safari），以及代码编辑器（如VS Code）。
-
技术栈：原生JavaScript（Cache API为浏览器原生提供，无需额外库），通常与 Service Worker 结合使用（Service Worker是拦截网络请求并管理缓存的脚本）。
-
核心API：
-
caches.open(cacheName)：打开或创建一个指定名称的缓存集合（Cache）。 -
cache.addAll(requests[])：一次性添加多个请求-响应对到缓存中（通常用于预缓存核心资源）。 -
cache.put(request, response)：添加单个请求-响应对到缓存中（适用于动态缓存）。 -
cache.match(request)：根据请求查找匹配的缓存响应（用于拦截请求并返回缓存内容）。 -
cache.delete(request)：删除指定的缓存请求-响应对。 -
caches.keys()：获取所有已创建的缓存集合名称（用于缓存版本管理）。
-
-
注意事项：
-
Cache API通常与Service Worker脚本（注册在主页面中）配合使用，Service Worker负责拦截网络请求并调用Cache API管理缓存。
-
缓存操作是异步的（基于Promise），需通过
then()或async/await处理结果。
-
4.2 场景1：PWA离线首页加载（核心资源缓存）
4.2.1 核心代码实现（结合Service Worker）
主页面（index.html）
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>PWA 离线缓存示例</title>
<!-- 引入Service Worker脚本 -->
<script>
if ('serviceWorker' in navigator) {
window.addEventListener('load', () => {
navigator.serviceWorker.register('/sw.js')
.then(registration => {
console.log('Service Worker 注册成功，作用域:', registration.scope);
})
.catch(error => {
console.error('Service Worker 注册失败:', error);
});
});
}
</script>
</head>
<body>
<h1>PWA 离线缓存示例</h1>
<p>当前页面将被Service Worker缓存，无网络时仍可访问。</p>
</body>
</html>Service Worker脚本（sw.js）
const CACHE_NAME = 'pwa-cache-v1'; // 缓存版本名称
const PRECACHE_URLS = [
'/', // 首页
'/index.html',
'/styles/main.css', // 核心CSS
'/scripts/main.js', // 核心JS
'/images/logo.png' // Logo图片
];
// Service Worker安装阶段：预缓存核心资源
self.addEventListener('install', event => {
console.log('[Service Worker] 安装阶段，开始预缓存资源');
event.waitUntil(
caches.open(CACHE_NAME)
.then(cache => {
return cache.addAll(PRECACHE_URLS); // 一次性添加所有预缓存资源
})
.then(() => {
console.log('[Service Worker] 预缓存完成');
})
.catch(error => {
console.error('[Service Worker] 预缓存失败:', error);
})
);
});
// Service Worker激活阶段：清理旧版本缓存
self.addEventListener('activate', event => {
console.log('[Service Worker] 激活阶段，清理旧缓存');
event.waitUntil(
caches.keys().then(cacheNames => {
return Promise.all(
cacheNames.map(cacheName => {
if (cacheName !== CACHE_NAME) {
console.log('[Service Worker] 删除旧缓存:', cacheName);
return caches.delete(cacheName); // 删除非当前版本的缓存
}
})
);
})
);
});
// Service Worker拦截请求阶段：优先返回缓存，失败再请求网络
self.addEventListener('fetch', event => {
event.respondWith(
caches.match(event.request) // 查找缓存中是否有匹配的请求
.then(response => {
if (response) {
console.log('[Service Worker] 从缓存返回:', event.request.url);
return response; // 直接返回缓存响应
}
console.log('[Service Worker] 缓存未命中，请求网络:', event.request.url);
return fetch(event.request) // 缓存未命中，请求网络
.then(networkResponse => {
// 可选：将网络响应缓存（适用于动态内容）
// 注意：仅缓存成功的GET请求
if (networkResponse && networkResponse.status === 200 && event.request.method === 'GET') {
const responseToCache = networkResponse.clone(); // 克隆响应（原响应只能使用一次）
caches.open(CACHE_NAME).then(cache => {
cache.put(event.request, responseToCache); // 缓存网络响应
});
}
return networkResponse; // 返回网络响应
})
.catch(error => {
console.error('[Service Worker] 网络请求失败:', error);
// 可选：返回自定义离线页面（如offline.html）
if (event.request.destination === 'document') {
return caches.match('/offline.html'); // 若请求的是页面，尝试返回离线页面
}
throw error; // 其他请求（如API）直接抛出错误
});
})
);
});4.2.2 代码解析
-
预缓存核心资源：在Service Worker的
install事件中，通过caches.open(CACHE_NAME)打开名为pwa-cache-v1的缓存集合，并使用cache.addAll(PRECACHE_URLS)一次性添加多个核心资源（首页、CSS、JS、图片）到缓存中。这些资源会在Service Worker安装完成后立即存储到本地。 -
清理旧版本缓存：在
activate事件中，通过caches.keys()获取所有已存在的缓存集合名称，删除非当前版本（CACHE_NAME）的旧缓存，避免缓存空间浪费和版本冲突。 -
拦截请求并返回缓存：在
fetch事件中，Service Worker拦截所有网络请求，首先通过caches.match(event.request)查找缓存中是否有匹配的请求-响应对。若命中缓存（如用户无网络时访问首页），直接返回缓存响应；若未命中（如首次访问或缓存过期），则请求网络并将成功的网络响应（如GET请求且状态码200）缓存到本地，供后续使用。
4.3 场景2：静态资源加速（公共文件缓存）
4.3.1 核心代码实现（动态缓存公共资源）
Service Worker脚本（sw.js）
const CACHE_NAME = 'static-resources-cache-v1';
const STATIC_RESOURCES = [
'/styles/bootstrap.min.css', // Bootstrap CSS
'/scripts/jquery.min.js', // jQuery库
'/fonts/roboto.woff2' // Roboto字体
];
// 安装阶段：缓存静态资源
self.addEventListener('install', event => {
event.waitUntil(
caches.open(CACHE_NAME)
.then(cache => {
return cache.addAll(STATIC_RESOURCES);
})
.then(() => {
console.log('[Service Worker] 静态资源缓存完成');
})
);
});
// 拦截请求：优先返回缓存的静态资源
self.addEventListener('fetch', event => {
const requestUrl = event.request.url;
// 仅拦截静态资源请求（根据URL路径判断）
if (requestUrl.includes('/styles/') || requestUrl.includes('/scripts/') || requestUrl.includes('/fonts/')) {
event.respondWith(
caches.match(event.request)
.then(response => {
if (response) {
console.log('[Service Worker] 静态资源从缓存返回:', requestUrl);
return response;
}
return fetch(event.request)
.then(networkResponse => {
if (networkResponse && networkResponse.status === 200) {
const responseToCache = networkResponse.clone();
caches.open(CACHE_NAME).then(cache => {
cache.put(event.request, responseToCache);
});
}
return networkResponse;
});
})
);
}
// 非静态资源请求（如API、页面）按默认方式处理
});4.3.2 代码解析
-
针对性缓存：仅对静态资源（如CSS、JS、字体文件）进行缓存，通过判断请求URL是否包含特定路径（如
/styles/、/scripts/、/fonts/）来区分静态资源和动态资源（如API、页面）。 -
动态缓存策略：在
fetch事件中，若请求的是静态资源且缓存未命中，则请求网络并将成功的网络响应缓存到本地（cache.put(event.request, responseToCache)），后续请求优先返回缓存内容，减少服务器负载。
4.4 场景3：API响应缓存（动态内容优化）
4.4.1 核心代码实现（缓存低频更新API）
Service Worker脚本（sw.js）
const API_CACHE_NAME = 'api-cache-v1';
const API_ENDPOINTS = [
'/api/user/preferences' // 用户偏好设置API（低频更新）
];
// 安装阶段：可不预缓存API（通常API响应动态变化）
// 拦截API请求：缓存响应并设置过期逻辑（简化示例）
self.addEventListener('fetch', event => {
const requestUrl = event.request.url;
if (API_ENDPOINTS.some(endpoint => requestUrl.includes(endpoint))) {
event.respondWith(
caches.match(event.request)
.then(cachedResponse => {
// 若缓存存在，直接返回（优先使用缓存）
if (cachedResponse) {
console.log('[Service Worker] API从缓存返回:', requestUrl);
return cachedResponse;
}
// 缓存未命中，请求网络
return fetch(event.request)
.then(networkResponse => {
if (networkResponse && networkResponse.status === 200) {
const responseToCache = networkResponse.clone();
// 缓存API响应（可根据需求设置更复杂的过期策略）
caches.open(API_CACHE_NAME).then(cache => {
cache.put(event.request, responseToCache);
});
}
return networkResponse;
});
})
);
}
});4.4.2 代码解析
-
API请求拦截：通过判断请求URL是否包含特定的API端点（如
/api/user/preferences），仅对低频更新的API响应进行缓存。 -
缓存优先策略：当用户请求API时，Service Worker首先查找缓存中是否有匹配的响应（如用户上次访问时缓存的偏好设置）。若命中缓存，直接返回缓存内容（减少网络请求）；若未命中，则请求网络并将成功的网络响应缓存到本地（
cache.put(event.request, responseToCache)），供后续请求使用。
5. 原理解释
5.1 Cache API的核心机制
-
缓存存储结构：Cache API通过
caches全局对象管理多个独立的缓存集合（Cache），每个Cache是一个键值对存储（键为HTTP请求对象Request，值为HTTP响应对象Response）。例如，一个名为pwa-cache-v1的Cache可能存储了{ 请求: /index.html, 响应: <HTML内容> }和{ 请求: /styles/main.css, 响应: <CSS内容> }。 -
请求匹配逻辑：当Service Worker拦截到网络请求时，通过
caches.match(event.request)查找缓存中是否有 完全匹配的请求（包括URL、请求方法（如GET）、请求头部等）。若匹配成功，则返回对应的缓存响应；若匹配失败，则继续执行网络请求。 -
缓存更新策略：开发者可通过逻辑控制缓存的更新时机（如“网络响应成功后自动缓存”、“定时清理旧缓存”、“根据版本号更新缓存”）。例如，在
fetch事件中，若网络请求成功且响应状态码为200，则将响应克隆并存储到缓存中（cache.put(event.request, responseToCache)），实现动态内容的缓存更新。
5.2 原理流程图（以PWA离线首页加载为例）
[用户访问PWA首页（/index.html）] → [Service Worker拦截请求]
↓
[Service Worker通过caches.match()查找缓存中是否有匹配的/index.html请求]
↓
[若命中缓存（如用户无网络时）] → [直接返回缓存的HTML内容，显示离线页面]
↓
[若未命中缓存（如首次访问或缓存过期）] → [请求网络获取最新首页]
↓
[网络请求成功后，将响应缓存到pwa-cache-v1中（可选）] → [返回网络响应给用户]6. 核心特性
|
特性 |
说明 |
优势 |
|---|---|---|
|
离线可用性 |
通过预缓存核心资源（如首页、CSS/JS），在无网络时直接返回本地副本，确保用户仍能访问基本功能。 |
提升用户在地铁、弱网等场景下的体验。 |
|
快速加载 |
缓存静态资源（如图片、字体）后，后续页面加载时直接从本地返回，减少服务器请求和加载延迟。 |
优化页面性能，尤其对移动端效果显著。 |
|
动态内容缓存 |
支持缓存API响应（如用户配置、低频更新数据），通过策略控制缓存更新，平衡实时性与性能。 |
减少不必要的网络请求，降低延迟。 |
|
版本控制 |
通过缓存名称（如 |
确保用户始终使用最新的缓存资源。 |
|
网络弹性 |
当网络请求失败（如服务器宕机），Service Worker可返回缓存的旧版本资源（如旧版文章内容），避免空白页面。 |
增强应用的健壮性，提升用户体验。 |
|
异步非阻塞 |
所有缓存操作（打开缓存、添加/匹配响应）均为异步（基于Promise），避免阻塞浏览器主线程。 |
保证页面交互的流畅性。 |
7. 环境准备
-
开发环境：现代浏览器（Chrome 40+、Firefox 39+、Edge 79+、Safari 11.1+），推荐使用Chrome进行开发和调试。
-
测试工具：
-
浏览器开发者工具（如Chrome的DevTools）中的 Application > Cache Storage 面板，可查看已创建的缓存集合及其内容（请求-响应对），便于调试。
-
离线模拟：在DevTools的 Network 面板中，将网络状态设置为“Offline”，测试Service Worker和Cache API的离线功能。
-
-
代码编辑器：VS Code、Sublime Text等支持HTML/JavaScript的编辑器。
-
依赖库：原生JavaScript（Cache API和Service Worker均为浏览器原生提供，无需第三方库）。
8. 实际详细应用代码示例实现（综合案例：博客PWA）
8.1 需求描述
开发一个博客PWA应用，要求：
-
用户首次访问时，Service Worker预缓存博客首页（
/index.html）、文章列表页（/articles.html）、核心CSS（/styles/blog.css）和Logo图片（/images/logo.png）。 -
当用户无网络时，仍可访问已缓存的首页和文章列表页，显示“离线模式”提示。
-
缓存博客文章的API响应（如
/api/articles），低频更新（如每天更新一次），优先返回缓存内容以减少网络请求。
8.2 代码实现
（结合预缓存、动态缓存和离线支持）
9. 运行结果
-
场景1（PWA离线首页）：用户无网络时访问博客首页，Service Worker通过Cache API返回缓存的
/index.html和相关资源，显示“离线模式”提示，页面正常渲染。 -
场景2（静态资源加速）：后续访问博客的其他页面（如文章列表页）时，静态资源（CSS、图片）直接从本地缓存返回，加载速度显著提升（尤其是移动端弱网环境）。
-
场景3（API响应缓存）：用户查看博客文章列表（通过API
/api/articles获取数据），首次请求后缓存响应，后续访问优先返回缓存内容，减少网络延迟。
10. 测试步骤及详细代码
-
基础功能测试：
-
离线访问：在浏览器中模拟离线状态（DevTools > Network > Offline），访问博客首页，验证是否显示缓存的页面内容。
-
缓存命中：通过DevTools的 Application > Cache Storage 面板，检查预缓存的核心资源（如
/index.html、/styles/blog.css）是否已存储。
-
-
性能测试：
-
加载速度：对比首次访问（无缓存）和后续访问（有缓存）的页面加载时间（通过DevTools的 Performance 面板），验证静态资源缓存的效果。
-
-
边界测试：
-
缓存更新：修改博客首页的HTML内容，更新Service Worker版本（如
pwa-cache-v2），验证旧缓存是否被清理，新缓存是否生效。 -
网络恢复：在离线状态下访问页面，然后恢复网络，验证Service Worker是否优先返回缓存，同时后台更新缓存（可选逻辑）。
-
11. 部署场景
-
PWA应用：博客、新闻网站、企业官网等需要离线可用和快速加载的Web应用，通过Cache API缓存核心资源和静态文件。
-
移动端Web应用：电商详情页、活动推广页等对加载速度敏感的场景，通过缓存图片和CSS/JS提升用户体验。
-
低网环境适配：偏远地区或弱网环境下的Web服务（如政府便民网站），通过缓存关键内容确保用户基本访问需求。
12. 疑难解答
-
Q1：Service Worker未注册成功（控制台报错“registration failed”）？
A1：检查浏览器是否支持Service Worker（Chrome/Firefox/Edge支持，Safari部分支持），确认Service Worker脚本路径（如
/sw.js）是否正确，且主页面与Service Worker同源（协议、域名、端口一致）。 -
Q2：缓存未生效（请求仍访问网络）？
A2：通过DevTools的 Application > Cache Storage 面板检查缓存集合是否存在，确认
caches.match(event.request)的请求URL是否与缓存中的请求完全匹配（包括方法、头部）。 -
Q3：旧缓存未清理（版本更新后仍使用旧资源）？
A3：在Service Worker的
activate事件中，通过caches.keys()获取所有缓存名称，并删除非当前版本的缓存（如cacheName !== CACHE_NAME）。
13. 未来展望
-
与IndexedDB协同：Cache API主要用于缓存网络响应（如HTML、图片），而IndexedDB适合存储结构化数据（如用户偏好、离线表单草稿）。未来两者可能更深度集成，实现“网络资源+业务数据”的统一离线管理。
-
更智能的缓存策略：通过机器学习算法（如基于用户访问频率预测哪些资源需要缓存），自动优化缓存内容和更新时机，减少开发者手动配置的成本。
-
跨浏览器标准化：尽管Cache API已被主流浏览器支持，但部分细节（如缓存过期策略、请求匹配规则）可能存在差异，未来可能进一步标准化以提升兼容性。
-
边缘计算结合：在边缘计算场景（如CDN节点缓存），Cache API可能与边缘缓存技术（如Service Worker + CDN）结合，实现更靠近用户的资源缓存和快速响应。
14. 技术趋势与挑战
-
趋势：
-
PWA的普及：随着越来越多的Web应用转向PWA（如Twitter Lite、Spotify Web），Cache API作为离线能力的核心，其重要性将持续提升。
-
动态内容缓存优化：开发者对API响应和动态页面的缓存需求增加（如个性化推荐内容），需要更精细的缓存策略（如基于用户身份的缓存隔离）。
-
-
挑战：
-
缓存版本管理：随着应用迭代（如HTML结构、API接口变更），需通过版本号（如
pwa-cache-v1→pwa-cache-v2）管理缓存，避免旧缓存导致功能异常。 -
安全与隐私：缓存可能存储敏感信息（如用户登录后的页面内容），需确保缓存数据的加密（如HTTPS传输）和访问控制（如仅缓存安全的请求）。
-
复杂场景适配：在多标签页、后台同步等复杂场景下（如用户同时打开多个页面），Cache API的缓存一致性和更新时机可能成为挑战。
-
15. 总结
H5 Cache API是现代Web应用实现 离线可用、快速加载和网络弹性 的核心技术，通过 缓存HTTP请求-响应对、拦截网络请求、优先返回本地副本，显著提升了用户体验和性能。其 “简单易用（基于Promise）、灵活策略（开发者可控）、与Service Worker深度集成” 的特性，使其成为PWA和性能优化项目的必备工具。尽管面临缓存版本管理、安全隐私等挑战，但随着PWA的普及和技术的演进，Cache API将继续在Web生态中发挥关键作用。开发者应深入理解其核心原理（如请求匹配、缓存更新），并结合实际业务需求设计合理的缓存策略（如预缓存核心资源、动态缓存低频数据），以构建更可靠、高效的Web应用。
- 点赞
- 收藏
- 关注作者
评论（0）