不会。base标签仅影响HTML解析阶段的纯相对路径（如src="logo.png"），对第三方广告iframe的绝对URL、根相对路径及JS运行时路径（fetch、import等）完全无效。
base 标签会让第三方广告 iframe 的 src 路径错乱吗？
不会。只要广告代码里用的是绝对 URL 或根相对路径（如 src="https://ad.example.com/ads.js" 或 src="/ads/frame.html"），
真正被改写的，只有广告代码中那些「纯相对路径」：比如 <img src="banner.png">、<script src="loader.js"> 这类没协议也没开头 / 的写法。而正规广告 SDK 几乎从不这么写，它们要么走 CDN 绝对地址，要么由服务端动态注入完整 URL。
所以别指望 <base href="/cdn/"> 能“统一管理”广告资源；也别怪它导致广告挂掉——问题大概率出在广告自己写了脆弱的相对路径，或者你误把 <base> 放到了广告容器内部（比如 SSR 模板拼接时重复注入）。
广告 iframe 的 title 属性为什么在 base 下失效？
<base> 和 title 本身无关，但广告 iframe 的 title 失效，常是因为 <base> 间接暴露了更深层的问题：广告 SDK 在运行时重写整个 iframe 节点，原始 HTML 中写的 title="广告" 被丢弃；或者广告内容嵌套多层 iframe，外层 title 对内层无穿透力。
立即学习“前端免费学习笔记（深入）”；
解决方式不是改 <base>，而是分情况处理：
- 同源广告：广告加载完成后，用
iframe.contentDocument注入aria-labelledby或显式设置role="application" - 跨域广告（如 GPT）：外层容器必须加
aria-hidden="true"，并配替代文本说明“此处为第三方广告位，内容由外部服务提供，不参与本页无障碍导航” - 禁止写
title=""或title="•"—— 屏幕阅读器会读作“空白”或“项目符号”，比不设更糟
base 标签会干扰广告 JS 动态加载的资源吗？
完全不会。广告脚本里调用的 fetch('./click?ad_id=123')、new Image().src = 'pixel.gif'、import('./tracker.js') 全部绕过 <base>。
原因很明确：<base> 只在 HTML 解析阶段起作用，只改写硬编码在标签属性里的纯相对路径（如 <img src="logo.png">）。JS 运行时路径解析，一律以当前页面 URL 或模块自身位置为基准，和 document.baseURI 无关。
如果你发现广告的像素请求 404 或 tracker 加载失败，问题一定出在：
- 广告 JS 自己拼错了路径（比如用了
location.pathname + '/pixel.gif'却没考虑子路径部署） - 你的 Service Worker 缓存策略没适配广告域名，拦截了跨域请求
- 广告 SDK 版本老旧，对现代
import.meta.url或new URL()支持不全
为什么给广告容器加 Shadow DOM 后可访问性反而更差？
因为 Shadow DOM 会切断无障碍树（accessibility tree），让屏幕阅读器无法感知其中任何结构——哪怕你给广告 iframe 加了 title、aria-label，只要它被包进 shadowRoot，这些语义标记就彻底失效。
这不是 <base> 的锅，但容易被混淆：有人以为用 Shadow DOM 封装广告能“隔离样式+隔离语义”，结果语义全丢了。
真实可行的隔离方式只有三种：
- 用
<iframe>容器，确保同源时可注入语义，跨域时显式声明aria-hidden="true" - 用
aria-hidden="true"+ 替代文本包裹广告 div，不封装、不 shadow、不假装可访问 - 采购阶段就在合同里写死广告商必须提供 WCAG 2.1 AA 级合规证明，拒绝接入不可控的黑盒 SDK
最麻烦的从来不是技术方案，而是广告商连 aria-label 都懒得加——这时候再怎么调 <base href>，也救不了整站可访问性。
