移动端APP菜单必须物理分离桌面与移动结构，禁用d-none类，改用offcanvas并严格遵循HTML结构、属性及JS交互规范，确保无障碍与响应式正确。
移动端 APP 菜单不是“加个 d-flex 就能响应式”，关键在结构隔离 + 行为解耦：桌面端菜单必须和移动端菜单物理分离，否则键盘焦点、屏幕阅读器、触控冒泡全会出问题。
为什么不能只用 flex-column + d-none d-sm-block
这种写法只是视觉隐藏，DOM 仍存在、仍占流、仍可聚焦。真实后果包括：
- 双指缩放时页面意外横向滚动（隐藏列仍参与 layout flow）
- 主内容区
.row高度被隐藏菜单拉高，导致滚动错乱 - offcanvas 展开后背景遮罩不显示（
d-none干扰了aria-hidden切换） - 屏幕阅读器持续朗读已“隐藏”的菜单项，违反 WCAG 2.1
移动端必须用 offcanvas，且结构要干净
offcanvas 不是样式开关，它对 HTML 结构和属性极其敏感：
- 关闭按钮必须是
<button type="button" class="btn-close" data-bs-dismiss="offcanvas">；手写×或onclick会丢掉 ESC 关闭和屏幕阅读器支持 - 别给
<div class="offcanvas">加自定义类如sidebar，尤其禁用position: relative、float、width—— 这些直接覆盖 transform 定位逻辑 - 宽度定制只能用 CSS 变量：
style="--bs-offcanvas-width: 280px;"；改width或max-width会导致偏移或截断 - 主内容区必须加
style="min-height: 100vh;"，否则 offcanvas 展开后页面塌陷、底部留白
菜单内部用 nav-pills flex-column + 手动二级展开
Bootstrap 原生 dropdown 在移动端嵌套时根本打不开（子项 data-bs-toggle="dropdown" 不会被 JS 初始化），必须手动接管：
- HTML 结构必须严格：
<li class="nav-item"><a class="nav-link">产品</a><ul class="submenu"><li><a>Web</a></li></ul></li> - 初始隐藏二级：
.submenu { display: none; }；桌面端用@media (min-width: 992px) { .submenu { display: block; } } - 移动端点击一级项时，只 toggle 对应
.submenu，并加e.stopPropagation()阻止冒泡（否则点一下整个菜单收起） - 监听建议用原生 JS：
document.addEventListener('click', e => { if (e.target.matches('.nav-link')) { e.target.nextElementSibling?.classList.toggle('show'); e.stopPropagation(); } });
桌面端侧边栏要用 position: sticky 或 fixed 锚定
仅靠 col-md-3 不够，它受父容器弹性布局干扰，容易崩：
- 给侧边栏容器加
position: sticky; top: 0;，但确保其父容器（如.row）没设overflow: hidden或transform（navbar-sticky-top会触发） - iOS Safari 中
sticky常静默失效，可降级为position: fixed; start-0 top-0 h-100，同时右栏加ms-md-3腾出安全间距 - 外层容器加
m-0 p-0清掉.container-fluid和.row的默认边距，否则fixed定位偏移 - 菜单过长时，侧边栏内部必须加
overflow-y-auto；别指望父容器自动截断
最易被忽略的点：offcanvas 的 show.bs.offcanvas 事件里，必须手动收起所有已展开的 .collapse.show，否则多级菜单在移动端切换时会残留打开状态——这个逻辑不会自动继承，也无 Bootstrap 类可替代。
