base href行为与Web服务器无关，完全由浏览器按HTML规范解析；其生效取决于href是否为合法绝对URL或根相对路径（结尾带斜杠）、是否置于<head>最前，且仅影响HTML中纯相对URL的解析。
base href 在不同 Web 服务器上根本不会“行为不同”
浏览器解析 <base href> 的逻辑是标准化的，与 Nginx、Apache、Caddy、IIS 或任何后端服务器无关。服务器只负责把 HTML 文件原样发给浏览器，<base> 是否生效、如何拼接路径，完全由客户端（Chrome/Firefox/Safari）按 HTML 规范执行——服务器不参与、不干预、不重写。
真正导致“看起来行为不同”的其实是部署路径和静态资源服务方式
你观察到的差异，往往来自以下组合问题，而非服务器本身：
-
<base href="/subapp/">写对了，但 Nginx 的location /subapp/没配alias或root，导致/subapp/index.js返回 404 - Apache 的
.htaccess启用了mod_rewrite，把所有请求 fallback 到index.html，但没排除/subapp/js/这类静态资源路径，结果 JS 文件被当成 HTML 返回 - Caddy 直接用
file_server，但没设root为构建输出目录，导致/subapp/下的资源 404，而你误以为是<base>失效 - IIS 的 URL Rewrite 规则把
/subapp/api/错误重写成/api/，前端 fetch 请求 404，你以为是 base 影响了 JS——其实它根本不影响 fetch
验证 base 是否生效，只看 Network 面板里 HTML 解析出的资源 URL
打开 DevTools → Network → 刷新页面，找一个 <img src="logo.png"> 请求：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 如果看到请求地址是
https://example.com/subapp/logo.png，说明<base href="/subapp/">生效了 - 如果看到的是
https://example.com/current-dir/logo.png（即按当前 HTML 所在目录拼的），那要么<base>写错了（比如缺结尾/），要么它被放到了<link>后面，压根没起作用 - 注意：这个 URL 是浏览器自己拼的，Network 里显示的就是最终发出的地址，不经过服务器重写
最常被忽略的交叉点：SPA 路由 fallback 和 base 的协同
当部署到子路径（如 https://example.com/admin/）时，两个机制必须同时对齐：
立即学习“前端免费学习笔记（深入）”；
-
<base href="/admin/">确保<script src="js/app.js">加载/admin/js/app.js - Web 服务器必须把所有非资源路径（如
/admin/settings）fallback 到/admin/index.html，否则刷新页面直接 404 - 但 fallback 规则不能覆盖
/admin/js/、/admin/css/这些真实存在的静态路径，否则资源也 404
这三者只要漏掉一环，就会表现为“有的链接能点、有的不能刷、JS 加载失败”，容易归咎于 base 标签本身——其实它只是整个链条里最透明、最守规矩的一环。
