判断并高亮当前导航项需基于 URL 路径匹配：用 window.location.pathname 与链接路径前缀比对（startsWith），注意处理子目录部署、SPA 路由响应式同步（如 React Router 的 NavLink 或 useMatch），并排查 CSS 优先级问题。
如何判断当前页面并设置 active 类
导航栏高亮本质是「让当前路由对应的菜单项拥有唯一标识类（如 active）」，JavaScript 需基于当前 URL 做匹配。最直接的方式是读取 window.location.pathname，再与每个导航链接的 href 属性比对。
注意：不能只用 === 全等，因为路径可能带查询参数或哈希（如 /user?id=123 或 /user#profile），而导航项通常只写基础路径（/user）。建议用 startsWith() 判断前缀匹配：
const currentPath = window.location.pathname;
document.querySelectorAll('nav a').forEach(link => {
const href = new URL(link.href).pathname;
link.classList.toggle('active', currentPath.startsWith(href));
});
- 用
new URL(link.href).pathname统一提取 href 的路径部分，避免相对路径解析错误 - 用
startsWith()而非includes()，防止/user错误匹配到/users - 如果项目有子目录部署（如部署在
/my-app/下），需先从pathname中剔除 base path，否则匹配失败
如何处理 SPA 路由（React/Vue）中的动态高亮
在 React Router 或 Vue Router 等前端路由中，URL 变化不触发页面刷新，window.location 监听无效。必须借助路由库提供的响应式机制。
React Router v6 推荐用 useLocation + useEffect 手动同步 class；但更稳妥的是直接在组件内用 NavLink，它内置了 end 属性控制是否严格匹配结尾：
立即学习“Java免费学习笔记（深入）”；
isActive ? "nav-link active" : "nav-link"}> 用户管理
-
end设为true时，/user不会匹配/user/profile；不加则默认模糊匹配子路径 - 若需自定义高亮逻辑（如根据 URL 参数决定），可用
useMatch("/user/*")配合条件渲染 - 纯 JS 实现时，监听
popstate事件不够可靠（pushState 时不触发），应优先使用路由库的导航守卫或状态订阅
CSS 高亮样式为什么没生效？常见陷阱
即使 JS 正确添加了 active 类，样式也可能不显示——问题常出在 CSS 优先级或选择器范围上。
- 检查是否被更具体的选择器覆盖，比如
nav a:hover权重高于.active，可改用nav a.active或加!important（仅调试用） - 确保 CSS 文件已加载且无语法错误，用浏览器开发者工具确认元素上确实存在
active类，并查看 computed 样式中 color/background 是否被其他规则覆盖 - 如果导航是生成的（如通过
v-for或map()），注意 class 绑定写法：:class="{ active: item.path === currentPath }"，别漏掉冒号和花括号 - 不要依赖
:visited伪类实现高亮——它只对历史访问链接生效，且现代浏览器限制其样式能力（只能改 color）
要不要用 IntersectionObserver 或 scroll 事件做滚动高亮？
滚动高亮（如锚点导航中随滚动自动切换 active）和路由高亮是两回事。前者基于元素可视区域位置，后者基于 URL。混用容易出错。
- 如果只是单页锚点跳转（如
#section1），用window.location.hash匹配id更轻量，无需 Observer - 真要用
IntersectionObserver，注意节流：默认每帧都触发回调，大量 section 会导致性能抖动；可设threshold: [0.1]并在回调里用entries[0].isIntersecting判断 - 滚动高亮无法替代路由高亮——用户手动输入 URL 或刷新页面后，滚动位置丢失，JS 无法还原 active 状态，必须回退到 URL 匹配逻辑
路由匹配才是高亮的唯一可信来源，滚动只是辅助视觉反馈。别为了“酷”把两套逻辑耦合在一起。
