首屏白屏超1秒主因是css加载阻塞html parser，须内联关键css（≤14kb）至style标签，禁用@import等异步引用，并确保bem类名不被编译改写，离线包需html与内联css原子下发。
首屏白屏超1秒，八成是CSS加载阻塞了HTML parser——哪怕CSS文件就在assets里，link标签同步加载仍要走IO路径、触发解析等待。真想“秒开”，就得让首屏样式在HTML parser吐出第一个字节时就已就位。
为什么不能用css">加载首屏CSS
WebView加载HTML时，遇到外部link会暂停parser，等CSSOM构建完成才继续；Android WebView 75+甚至对本地file://协议的CSS也做同步IO阻塞。实测一个12KB的base.css在低端机上可引入80–150ms延迟，远超首屏100ms黄金阈值。
- 即使加了
rel="preload"，也不能绕过parser blocking行为 -
media="print"或disabled属性虽能跳过阻塞，但样式不生效，失去意义 - Webpack/Vite的CSS提取插件默认生成
link，需手动干预构建流程
必须内联首屏关键CSS，且控制体积在14KB以内
内联即把CSS文本直接写进<style></style>标签，让浏览器无需额外请求、无IO等待、无解析调度，parser边读边构CSSOM。但别无脑全量内联——V8对<style></style>内容有解析上限，iOS WKWebView在超过14KB时会出现样式截断或渲染错乱。
- 只保留首屏可见区域（above-the-fold）所需的class：比如
.user-card__header、.banner--active，剔除.modal__footer这类滚动后才出现的规则 - 禁用
@import、@font-face、url()图片引用——这些会触发额外网络/IO，破坏内联意义 - 用PostCSS插件如
postcss-critical-css自动提取，避免人工漏判
JS动态注入CSS在WebView里基本不可靠
有人想用document.createElement('link') + appendChild延迟加载非首屏CSS，这在Chrome桌面端可行，但在Hybrid WebView中问题集中：
- Android WebView 61–74：
link插入后不触发重排，样式不生效，需强制getComputedStyle触发 - iOS WKWebView：若在
DOMContentLoaded前插入link，可能被UA脚本拦截（尤其微信、钉钉壳） - 所有平台：动态插入的CSS无法参与FOUC（Flash of Unstyled Content）抑制，用户会看到先白后色的抖动
- 更致命的是：TBS/X5内核对
document.write和innerHTML注入style标签有兼容性陷阱，部分机型直接静默失败
离线包更新时CSS与HTML必须原子替换
很多团队把CSS单独打包进离线zip，HTML里仍写<link href="app_v2.css">，结果更新时HTML先解压、CSS后到位，页面加载瞬间报Failed to load resource: net::ERR_FILE_NOT_FOUND，白屏延长至3s+。
- 正确做法：把内联CSS字符串硬编码进HTML模板，整个
index.html作为单个原子单元下发 - 若必须分离CSS（如AB测试），则用
fetch('file:///android_asset/app_v2.css')+new CSSStyleSheet()+document.adoptedStyleSheets = [sheet]（仅Android WebView 84+/iOS 16.4+支持） - 验证方式：adb shell进入APK解压目录，确认
assets/index.html里<style></style>块存在且内容完整，无/* injected by build */占位符残留
最易被忽略的一点：BEM类名必须原样出现在内联<style></style>里，不能被cssModules或scoped编译改写——否则宿主壳注入的.text { color: #666 !important }会直接命中你的user-card__title，而你还在查JS有没有执行成功。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
