HTML文档在混合开发模式下的本地资源重定向与映射方案-html教程-PHP中文网

鸿蒙 webview 中 rawfile 资源路径必须用以 / 开头的绝对路径（如 /pages/book.css），不可用相对路径或；跳转需拦截 onwillnavigate 并拼接完整 file:// 路径；刷新白屏需显式 loadurl 完整路径。

html文档在混合开发模式下的本地资源重定向与映射方案

鸿蒙 WebView 中 rawfile 资源路径怎么写才不 404？

鸿蒙 WebView 加载本地 HTML 时，file:// 协议下资源路径解析非常敏感——直接写 ./css/app.css 或 img/logo.png 极易失败，尤其当 HTML 不在根目录、或 JS 动态拼接路径时。

根本原因：鸿蒙 WebView 的 file:// 加载器不支持相对路径的“当前文件所在目录”推导，它默认以应用 rawfile 根为基准，且忽略 <base href>（Chrome 都静默忽略，鸿蒙更严格）。

实操建议：

所有资源路径必须用 绝对路径写法：以 / 开头，对应 rawfile 目录结构。例如 HTML 在 rawfile/pages/book.html，引用同级 CSS 应写 /pages/book.css，而非 ./book.css
避免在 JS 中用 location.href 或 document.currentScript 推导路径——这些在 file:// 下不可靠；改用固定前缀，如 const BASE_PATH = '/pages/';
图片、字体等二进制资源若放在 resources/base/media/，需通过 ohos.resourceManager 原生 API 获取 URI 再传给 Web，不能直接用 /resources/xxx

如何让 HTML 页面跳转时保持在本地资源域内？

用户点击一个 <a href="chapter2.html"></a>，WebView 默认会尝试加载 file:///chapter2.html（即 rawfile 根），而不是你期望的同目录下的 rawfile/pages/chapter2.html。这是混合开发中最常见的“跳转出域”问题。

关键不是改链接，而是控制 WebView 的导航拦截逻辑：

在鸿蒙 WebView 实例上注册 setWebMessageCallback 或更关键的 setNavigationCallback，监听 onWillNavigate
对所有非 http://、https:// 的 URL，手动解析其路径：若为纯文件名（如 chapter2.html），则拼接为 file:///data/storage/el1/bundle/resources/rawfile/pages/chapter2.html（实际路径需用 getContext().getResourceManager().getRawFileDir() 动态获取）
调用 event.preventDefault() 阻止默认跳转，再用 webView.loadUrl() 加载修正后的路径
注意：不要拦截 javascript: 或 data: 协议，否则破坏页面内联逻辑

`<base href>` 在鸿蒙 WebView 里到底有没有用？

没用。至少截至 2026 年 6 月的 DevEco Studio 4.1 和 API Version 12，<base href="/pages/"> 对 file:// 加载的 HTML 完全无效——浏览器既不报错，也不生效，所有 ./style.css 仍按 rawfile 根解析。

html-deploy

使用 htmlcode.fun 将 HTML 内容或文件部署到网页，适用于用户要求“部署到网页”“托管此 HTML”“生成此前端...的实时链接”等场景。

下载

这不是 bug，是规范限制：<base> 仅在 HTTP(S) 场景下由服务器响应头或文档上下文触发，而鸿蒙 WebView 的 file:// 加载器不实现该解析链。

替代方案只有两个：

静态资源全部用绝对路径（如上所述），并配合构建脚本自动重写 HTML 中的 href/src 属性
把 HTML 改为通过 loadDataWithBaseURL 加载字符串内容，并传入真实 base URL（如 file:///data/xxx/pages/），此时 <base> 才可能起效，但失去 rawfile 热更新能力

为什么 index.html 刷新后变成白屏或 404？

这不是路由问题，是鸿蒙 WebView 的缓存与路径双重校验机制导致的：首次加载 file:///pages/index.html 成功，但刷新时 WebView 可能复用旧的 base URL 上下文，或因 rawfile 资源未预加载而无法重新解析相对路径。

最稳妥的解法是放弃“刷新即重载”的假设，改为显式控制：

在页面 JS 中监听 beforeunload，保存关键状态到 localStorage 或 @ohos.app.ability.common 的临时存储
在 onPageStarted 回调中检查当前 URL 是否为 index.html，若是，则主动调用 webView.reload() 并立即 loadUrl 带完整路径的版本
更彻底的做法：禁用 WebView 的默认刷新行为，用原生按钮触发 loadUrl("file:///pages/index.html")，确保每次都是干净路径