link rel="prerender" 在2026年已基本不可用：Chrome v110+默认禁用，Edge同步弃用，Firefox/Safari从未支持；它不下载HTML，仅可能做DNS/TCP预连接，且受同源、无参、前台空闲等严苛限制，实际业务难以满足；真正有效的替代方案是prefetch + 服务端缓存 + preload。
link rel="prerender" 在当前（2026年5月）已基本不可用，不建议在生产环境依赖它来加速导航。
Chrome v110+ 默认禁用，Edge 同步弃用，Firefox/Safari 从未支持
该标签自 Chrome 110 起被默认关闭，仅保留实验性开关（chrome://flags/#prerender2），且需手动启用；Edge 基于 Chromium 已同步移除默认行为；Firefox 和 Safari 完全忽略该声明。你在 HTML 中写：<link rel="prerender" href="/product/123">，浏览器大概率直接跳过，Network 面板里看不到任何对应请求，控制台也无提示——不是“没生效”，而是根本没执行逻辑。
- 即使强制开启，也只在前台页面空闲、内存充足、未节电时才可能触发，用户切 Tab 或滚动即中止
- 目标页必须同源、无查询参数（
/product✅，/product?id=123❌）、无 hash，实际业务几乎无法满足 - 预渲染过程不触发服务端日志、不跑 GA、不被爬虫识别，对 SEO 和数据统计零贡献
它和“预渲染（prerendering）”是两件事，别被名字骗了
link rel="prerender" 是浏览器原生的“隐藏 tab 渲染”机制：开个隐身页加载完整 HTML + 执行 JS + 构建 DOM + 下载资源，等点击就秒切。但它 ≠ 构建时生成静态 HTML 的 prerendering（如 prerender-spa-plugin 或 generateStaticParams）。前者是客户端运行时投机行为，后者是构建产物里的真实 HTML 文件。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 如果你的构建目录里没有生成
/product/index.html这类文件，那你就没做真正的预渲染 - 想解决首屏白屏、LCP 慢、SEO 抓取失败？
rel="prerender"一概不管 - 它甚至不保证 HTML 被下载——现代 Chrome 实际只做 DNS 预解析或 TCP 预连接，连 HTML 都不 fetch
真正能落地的替代方案：prefetch + 服务端缓存 + 关键资源 preload
要让导航“快到无感”，得组合使用更可靠、广泛支持的机制：
立即学习“前端免费学习笔记（深入）”；
- 对下一页 HTML 使用
<link rel="prefetch" href="/product/123" as="document">：所有主流浏览器都支持，只下载 HTML 不执行，配合前端路由可手动 hydrate - 关键入口页（如首页）hover/focus 时主动
fetch()目标页 HTML，缓存到sessionStorage或Cache API，点击时直接复用 - 用
<link rel="preload" href="main.css" as="style">提前拉首屏必需 CSS，避免渲染阻塞；字体必须加crossorigin，否则白屏 - 动态关键页（如用户仪表盘）优先走 SSR + CDN 缓存（
Cache-Control: s-maxage=300），比客户端瞎猜“用户下一步点哪”靠谱得多
真正难的不是写一行 link rel="prerender"，而是判断：这个页面是否值得为它增加构建复杂度、缓存失效风险、以及 hydration 错乱的调试成本。多数时候，精准的 prefetch + 服务端缓存 + 内联关键 CSS，比寄希望于浏览器偷偷帮你开个隐身页实在得多。
