HTML缓存不提升首屏加载率，只影响首屏加载速度和资源复用率；真正提升成功率需HTTP缓存兜底+Service Worker精控+WebView适配。
HTML 缓存机制本身不直接提升「首屏加载率」，它影响的是「首屏加载速度」和「资源复用率」。真正能提升首屏加载成功率（即降低白屏/加载失败率）的，是让关键资源在弱网、离线或服务端抖动时仍能稳定返回——这需要分层设计：HTTP 缓存兜底 + Service Worker 精控 + WebView 特殊适配。
为什么 Cache-Control 对 index.html 不能强缓存
index.html 是 HTML 应用的入口，一旦被强缓存（如 Cache-Control: max-age=31536000），后续 JS/CSS 文件即使带 hash，WebView 或浏览器也不会重新请求它——导致永远加载旧版本资源，首屏白屏或报错 ChunkLoadError。
- 服务端必须禁用 index.html 缓存：
Cache-Control: no-cache, must-revalidate或no-store - Nginx 示例：
location = /index.html { add_header Cache-Control "no-cache, no-store, must-revalidate"; } - CDN 上也要显式配置 index.html 缓存时间为 0，不能依赖默认策略
- uni-app 的
manifest.json中version字段更新，对 WebView 加载无效，纯属误导
Service Worker 用 caches.open 预存哪些接口才真正加速首屏
不是所有 API 都适合塞进 CacheStorage。预存错误接口反而拖慢首屏，比如返回 401 或含动态 token 的响应会污染缓存。
- 只缓存明确符合以下条件的 GET 接口：
/api/v1/banner、/api/v1/menu、/api/v1/regions - URL 必须静态或带固定版本参数，如
/api/v1/config?v=2.3.0；避免/api/user?token=xxx - 响应体大小控制在 7MB 内；含 base64 图片的富文本建议先抽离为 CDN 地址再缓存
- 写入前必须调用
response.clone()，否则后续读取会报TypeError: Failed to execute 'clone' on 'Response': Response body is already used
Android WebView 下 cacheMode 设置不生效的常见原因
webView.setCacheMode("LOAD_CACHE_ELSE_NETWORK") 在 Android 端必须满足两个硬性条件才会起作用，漏掉任一环节都会退化为直连网络，首屏卡死。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
- 必须在
webview.addEventListener('loaded', ...)回调内调用，不能在创建后立刻设 - 仅对 App 内嵌 WebView 有效，H5 页面中该 API 完全无意义
- 低端 Android（6–9）系统 WebView 默认是
LOAD_DEFAULT，会忽略本地缓存，必须显式覆盖 - 网络断开时需监听
uni.getNetworkType并主动切换回该模式，否则页面空白且无错误提示
preload link 和 uni.preloadPage 的本质区别
两者都叫“预加载”，但底层机制完全不同：前者由浏览器解析 HTML 时触发，后者由 uni-app 原生容器提前初始化 webview 实例。
-
<link rel="preload" href="/static/js/app.js" as="script">只下载不解析，不解决 HTML 解析阻塞问题 -
uni.preloadPage({ url: '/pages/index/index' })会在后台提前创建 webview、加载 HTML、解析 DOM、执行 JS 初始化，首屏渲染几乎无等待 -
uni.preloadPage必须在onLaunch调用，onShow太晚，首次打开已来不及 -
uni.preloadImage不校验 URL 是否真实存在，失败静默，验证方式只有 DevTools Network 面板看是否重复请求
真正卡住首屏的，往往不是网络带宽，而是缓存链路中的某个环节没对齐：服务端缓存头、客户端 fetch credentials、Response 克隆时机、WebView 生命周期钩子……这些点单独看都很小，但串起来就是白屏和秒开的分水岭。
