本教程旨在解决响应式导航中子菜单在窗口调整大小（尤其从桌面视图切换到移动视图时）时意外自动展开的问题。通过引入状态跟踪类和分离的媒体查询事件监听器，我们能够精确管理导航菜单的开合状态，确保其行为符合用户预期，避免不必要的界面干扰。
响应式导航子菜单自动展开问题解析与解决方案
在开发响应式网站时，导航菜单的交互行为是用户体验的关键一环。一个常见的问题是，当用户调整浏览器窗口大小，特别是从桌面视图切换到移动视图时，原本应该由用户点击汉堡菜单才打开的子菜单却意外地自动展开。这不仅违反了用户预期，也可能导致界面混乱。本教程将深入分析这一问题，并提供一个基于JavaScript的优化解决方案，确保导航菜单在不同屏幕尺寸下的行为更加智能和可控。
问题的根源分析
为了实现响应式导航，我们通常会利用 window.matchMedia API 来监听视口尺寸的变化，并根据不同的媒体查询条件来调整导航菜单的样式或行为。原始代码中存在一个关键的逻辑缺陷，导致了子菜单的自动展开：
// 简化后的原始问题代码片段
widthMatch.addEventListener('change', function(mm) { // 监听 min-width >= 1080px
if (mm.matches) {
// ... 桌面视图下的清理逻辑 ...
} else if (!burgerDivEle.classList.contains('on') && !navUlEle.classList.contains('nav-active')) {
// ⚠️ 问题所在：在此处嵌套了另一个事件监听器
widthMatch2.addEventListener('change', function(mm) { // 监听 max-width <= 1080px
if (mm.matches) {
// 当屏幕缩小到移动视图时，无论用户是否点击过，都会添加这些类
nav.classList.add("nav-active");
burger.classList.add('on');
}
});
}
});上述代码的问题在于：
- 嵌套事件监听器： 在 widthMatch 的 change 事件内部，又为 widthMatch2 添加了一个新的 change 事件监听器。这意味着每次 widthMatch 状态变化时，都可能重复添加 widthMatch2 的监听器，导致潜在的性能问题和不可预测的行为。
- 不准确的条件判断： else if (!burgerDivEle.classList.contains('on') && !navUlEle.classList.contains('nav-active')) 旨在判断菜单当前是否未打开。然而，当屏幕从大变小时，如果菜单之前并未被用户打开过，这个条件会成立，然后内部的 widthMatch2 监听器会在屏幕缩小到移动尺寸时无条件地添加 nav-active 和 on 类，从而强制打开菜单。
解决方案：基于状态标记的优化
为了解决上述问题，我们需要一种机制来区分两种情况：
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 菜单是用户主动打开的。
- 菜单是由于屏幕尺寸变化而被系统关闭的。
通过引入一个“状态标记”类（例如 been-removed），我们可以精确地跟踪菜单的状态。其核心思想是：当菜单在桌面视图下被系统关闭时，给它添加一个 been-removed 标记；当屏幕再次缩小到移动视图时，只有当这个 been-removed 标记存在时，才重新打开菜单。这确保了只有那些因屏幕变大而被“暂时隐藏”的菜单才会在屏幕变小时重新显示，而从未被用户打开的菜单则会保持关闭状态。
优化后的逻辑步骤：
- 分离事件监听器： 将针对 min-width 和 max-width 的媒体查询事件监听器完全分离，避免嵌套，提高代码清晰度和可维护性。
-
桌面视图下的处理 (min-width >= 1080px)：
- 当屏幕尺寸达到或超过 1080px 时（桌面视图），如果导航菜单当前是打开状态（即包含 on 和 nav-active 类），则将其关闭。
- 同时，为导航菜单和汉堡按钮添加一个 been-removed 类。这个类作为状态标记，表示“这个菜单曾因屏幕变大而被系统关闭”。
-
移动视图下的处理 (max-width <= 1080px)：
- 当屏幕尺寸缩小到 1080px 或以下时（移动视图），检查导航菜单和汉堡按钮是否包含 been-removed 类。
- 如果包含，则说明这个菜单之前在桌面视图下是被系统关闭的，此时应该将其重新打开（添加 on 和 nav-active 类）。
- 重新打开后，立即移除 been-removed 类，以重置状态，防止后续不必要的行为。
优化后的代码实现
以下是基于上述逻辑优化后的 JavaScript 代码：
// 定义媒体查询对象
let widthMatch = window.matchMedia("(min-width: 1080px)");
let widthMatch2 = window.matchMedia("(max-width: 1080px)");
// 监听屏幕宽度大于等于 1080px 的变化
widthMatch.addEventListener('change', function(mm) {
if (mm.matches) {
// 如果当前视口宽度 >= 1080px
// 并且导航菜单处于打开状态
if (burgerDivEle.classList.contains('on') && navUlEle.classList.contains('nav-active')) {
// 移除打开状态的类，将导航菜单重置到初始状态
nav.classList.remove("nav-active");
burger.classList.remove('on');
// 添加 'been-removed' 标记类，表示菜单因视口变大而被系统关闭
nav.classList.add('been-removed');
burger.classList.add('been-removed');
}
}
});
// 监听屏幕宽度小于等于 1080px 的变化
widthMatch2.addEventListener('change', function(mm) {
if (mm.matches) {
// 如果当前视口宽度 <= 1080px
// 并且导航菜单曾被系统关闭过（即包含 'been-removed' 类）
if (burgerDivEle.classList.contains('been-removed') && navUlEle.classList.contains('been-removed')) {
// 重新添加打开状态的类，恢复导航菜单的打开状态
nav.classList.add("nav-active");
burger.classList.add('on');
// 移除 'been-removed' 标记类，因为菜单已经恢复，该标记不再需要
nav.classList.remove("been-removed");
burger.classList.remove("been-removed");
}
}
});
// 请确保 'burgerDivEle', 'navUlEle', 'nav', 'burger' 等变量已正确定义并指向对应的DOM元素。
// 例如：
// const burgerDivEle = document.querySelector('.burger-div'); // 汉堡菜单容器
// const navUlEle = document.querySelector('.nav-ul'); // 导航列表
// const nav = document.querySelector('nav'); // 导航元素 (可能是 navUlEle 的父元素或其本身)
// const burger = document.querySelector('.burger'); // 汉堡菜单按钮注意事项与最佳实践
- 避免嵌套事件监听器： 始终保持事件监听器的独立性。嵌套监听器不仅难以理解和调试，还可能导致资源泄漏或重复触发等问题。
- 清晰的状态管理： 使用明确的类名（如 been-removed）来表示组件的特定状态，这使得代码的意图更加清晰，便于维护和扩展。
- 初始化状态处理： 确保页面加载时，菜单的初始状态是正确的，并且不会因为首次加载时的媒体查询匹配而意外打开。
