WebView 的 file:// 协议不支持 Cache-Control 且路径解析不一致，导致 CSS 加载失败、url() 404、缓存不更新等问题；需用绝对路径、构建哈希、JS 动态注入并禁用中文/空格路径。
WebView 的 file:// 协议不认 Cache-Control，也不按标准解析路径
混合 App 里用 link rel="stylesheet" 加本地 CSS，常出现“明明文件存在却加载失败”——根本原因是 WebView 对 file:// 协议的处理和普通浏览器完全不同。Android 系统 WebView（尤其旧版）直接忽略 HTTP 响应头如 Cache-Control，iOS WKWebView 则对相对路径、@import、url() 中的图片路径支持不一致，甚至同个 CSS 文件在两个平台表现不同。
常见错误现象：
-
link标签 href 写对了，但 Network 面板里请求状态是cancelled或根本没发出 - CSS 加载成功，但里面的
url("icon.png")全部 404 - 首次打开正常，杀进程重进后样式丢失（缓存未更新）
CSS 里的 url() 路径基准点混乱：不是 HTML，也不是项目根
在 file:// 下，url() 的解析基准不是 HTML 页面位置，也不是你想象的“项目根目录”，而是由 WebView 自行决定：Android 默认以 assets 目录为根，iOS WKWebView 可能指向 bundle root 或临时解压路径，且不继承父 CSS 的路径上下文。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 所有
url()必须写成绝对路径，例如url("file:///android_asset/www/images/logo.png")，不能写url("./images/logo.png") - 避免
@import，它不会沿用当前 CSS 文件所在目录；改用构建时 inline 或合并 - 调试时先执行
console.log(location.href)，再比对 Network 中实际请求的Request URL是否匹配
中文/空格路径在 file:// 下大概率被拦截或编码失败
@charset 解决不了路径里的中文问题，它只控制 CSS 文本解码。而 file:// 协议下，含中文或空格的路径会被浏览器尝试百分比编码，但 Android WebView 和 iOS WKWebView 对编码后的路径解析能力极弱，Chrome 双击打开时甚至直接拒绝加载。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 开发阶段必须起 HTTP 服务（如
npx serve或 VS Code Live Server），地址必须是http://localhost:xxx/，不能是file:/// - 生产环境彻底禁用中文/空格路径：把
按钮.css改成button.css，把url("背景图.jpg")改成url("bg.jpg") - 如果团队强依赖中文路径，必须确保 Nginx 配置
charset utf-8;，且所有中间代理层禁用 URL 解码重写
构建阶段不加哈希，WebView 会永远拿旧缓存
WebView 对 file:// 下资源的缓存策略极其激进，哪怕你替换了 CSS 文件内容，只要文件名不变，它就可能复用内存中旧版本。这不是 bug，是设计使然。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 构建时给 CSS 文件名加内容哈希，例如输出为
app.a1b2c3.css，而非固定名app.css - 不用
link直接引入，改用 JS 动态创建style标签并内联注入（尤其首屏关键样式） - Android 端可调用
webView.getSettings().setCacheMode(WebSettings.LOAD_NO_CACHE)，但注意setAppCacheEnabled(false)已废弃
