应修改 .navbar-collapse.show 的 transition 属性，如 .navbar-collapse.show { transition: max-height 0.6s cubic-bezier(0.25, 0.46, 0.45, 0.94) !important; }，并同步设 max-height: 120vh !important，避免因起止值不匹配导致跳变或截断。
怎么改 .navbar-collapse.show 的 transition 时长
Navbar 移动端菜单的动画时长不是靠 JS 控制，也不是改 data-bs-* 属性，而是由 .navbar-collapse.show 的 max-height 过渡决定。Bootstrap 默认用的是类似 max-height 0.35s ease-in（5.3+ 版本通过 CSS 变量 --bs-navbar-collapse-transition 定义），但直接覆盖类选择器更可靠。
- 必须在 Bootstrap CSS 加载之后引入自定义样式，否则被内置规则压制
- 写法要完整：
.navbar-collapse.show { transition: max-height 0.6s ease-in-out !important; }—— 不能只写transition-duration，它无法单独覆盖原有transition声明 - 推荐缓动函数：
cubic-bezier(0.25, 0.46, 0.45, 0.94)比ease-in-out更自然，避免“弹跳感” - 低于
0.2s显得突兀；超过0.8s在小屏触控场景下易感知延迟
为什么改了时长，动画还是卡顿或跳变
常见现象是：首次点击展开时内容先闪一下、再收缩、最后缓慢下拉；或收起时高度归零前明显停顿。这不是时长问题，而是 max-height 起始值（0）和终点值不匹配导致的过渡断裂。
-
.navbar-collapse收起态是max-height: 0，但展开目标若设得太小（如300px），而真实内容高度超限，浏览器会强制截断插值，造成“跳变” - 必须同步增大
.navbar-collapse.show的max-height，例如max-height: 120vh !important;——vh单位可随视口缩放，比固定像素更稳妥 - 禁止用
max-height: none、100%或fit-content，它们不参与 CSS transition，会导致动画立即生效或失效 - 检查是否给
.navbar-collapse手动加了height、border或overflow: hidden，这些会干扰max-height渲染上下文
下拉菜单（.dropdown）让动画错位怎么办
折叠区里嵌 .dropdown 时，.dropdown-menu 默认是 position: absolute，不占容器高度，但它的父级（如 .nav-item）若有 padding 或 min-height，视觉上撑高了却没被 max-height 包含，点开二级菜单就容易“突然撑高”或“被切半”。
- 临时方案：给
.navbar-collapse.show .dropdown-menu加position: static !important;，让它随文档流撑高容器 - 更轻量做法：在
<ul class="dropdown-menu"></ul>上加data-bs-popper="static"，禁用 Popper.js 动态定位 - 避免在
@media (max-width: 991.98px)下误写.dropdown-menu { top: 100% }—— 移动端折叠态不需要手动调位置 - 如果用了 SVG 图标，确保其
vertical-align和height与文本对齐，否则会额外抬高行盒
要不要改 --bs-navbar-collapse-transition 变量
Bootstrap 5.3+ 确实暴露了这个 CSS 变量，但它的作用有限：它只影响 JS 初始化时读取的默认过渡值，且仅在启用原生 Collapse JS 时生效。如果你用纯 CSS 实现折叠（比如删了 data-bs-toggle），这个变量完全不生效。
- 直接写
.navbar-collapse.show { transition: ... !important; }更稳定，不依赖 JS 是否加载 - 变量写法示例：
.navbar { --bs-navbar-collapse-transition: max-height 0.6s cubic-bezier(0.25, 0.46, 0.45, 0.94); }，但它无法覆盖已存在的transition声明，仍需配合!important或更高 specificity - 真正麻烦的不是改变量，而是改完后必须同步验证所有断点下的点击区域大小、焦点管理、以及字体加载延迟是否导致首次展开高度估算偏小
