:target-within 目前（2024 年中）几乎不可用——从未被任何主流浏览器实现，mdn 和 can i use 均无记录，chrome/firefox/safari 均不识别；其本意是容器内子元素成为 :target 时触发样式，但现实只能靠 :has(h2:target)（现代浏览器支持）或 js 模拟。
`:target-within` 浏览器支持现状
它目前（2024 年中）**几乎不可用**——:target-within 从未被任何主流浏览器实现，连实验性 flag 都没开放。你查 MDN 或 Can I Use，根本找不到这条伪类；Chrome、Firefox、Safari 的开发者工具里输进去也完全不生效。
常见错误现象：:target-within 写在 CSS 里毫无反应，控制台无报错，样式就是不触发；有人误以为是写法问题，反复检查选择器，其实根源是“这东西压根不存在”。
使用场景本意是：当某个容器内任意子元素成为 :target（即 URL 锚点定位到其内部），该容器整体获得样式响应。但现实是：没有浏览器认这个语法。
替代方案只能靠 JS 模拟，或退回到更保守的结构设计：
立即学习“前端免费学习笔记（深入）”；
- 用
:target直接作用于锚点元素本身（如<h2 id="section1"></h2>），再通过相邻/后代选择器影响父容器（有限制，依赖 HTML 结构） - 监听
hashchange事件，用 JS 判断当前location.hash对应的元素是否在某容器内，再手动加 class - 放弃“容器级响应”需求，改用显式 class 控制（比如点击导航时 JS 同时给 section 和 wrapper 加 class）
为什么不能靠 polyfill 补上 :target-within
CSS 伪类的运行机制决定了它无法被 JS 安全模拟：伪类匹配发生在样式计算阶段，而 JS 无法在不触发重排/重绘的前提下，实时、同步地告诉浏览器“这个容器此刻应视为 :target-within 状态”。
性能影响明显：如果用 MutationObserver + getBoundingClientRect() 轮询检测 hash 变化后目标元素位置，容易引发布局抖动；尤其页面滚动或 hash 频繁变更时，卡顿可感知。
兼容性陷阱更隐蔽：某些 SSR 框架（如 Next.js、Nuxt）在服务端渲染时，location.hash 是空字符串，JS 初始化逻辑若没做防御，首屏就漏掉样式，直到用户手动点一次链接才“突然生效”。
真正能用的锚点联动方案（轻量、可靠）
绕过 :target-within 这个幻影，用现有标准能力组合出等效效果：
- HTML 结构上，让锚点元素（如
<h2 id="step2"></h2>）和需要高亮的容器（如<section class="step"></section>）保持父子关系，然后用section:has(h2:target)—— 注意：:has()已在 Chrome 105+、Safari 15.4+、Firefox 121+ 支持，且无需 flag - 如果需兼容老浏览器，CSS 侧只写基础样式（如
section默认态），JS 侧监听hashchange，用document.querySelector(location.hash)找到目标元素，再向上遍历.closest('.step')，添加临时 class - 避免把逻辑耦合进 scroll 事件——锚点跳转本身会触发
hashchange，比监听 scroll 更精准、更省资源
示例（现代浏览器）：
section:has(h2:target) { background-color: #f8f9fa; }
容易被忽略的细节：URL 中的 `#` 和空 hash
当 URL 是 https://example.com/page#（末尾只有 #，无 ID），:target 不匹配任何元素，:has(h2:target) 也会失效；但很多人测试时只用完整锚点（如 #section1），上线后发现首页带 # 就崩了。
JS 方案里也得判断：if (location.hash && location.hash !== '#') { ... }，否则 querySelector('#') 报错或返回 null，后续 .closest() 调用直接失败。
还有个冷门坑：Vue Router 或 React Router 的 hash 模式下，路由变化可能不触发原生 hashchange，得用框架提供的导航守卫或 useLocation 等钩子替代。
