下拉菜单这个话题前端新手基本都绕不开。很多人习惯打开Bootstrap官网复制一段现成代码或者直接拉一个jQuery插件过来用真到面试时被问到手写一个下拉菜单或者在轻量页面里不允许引第三方库时就露怯了。这篇内容我就按自己平时带人的节奏把这个30分钟手写下拉菜单的路子完整走一遍先讲原理再写代码最后把我实测时踩过的坑全部翻出来。1. 别急着写代码先搞清下拉菜单到底由哪几个独立问题组成很多人写不下来下拉菜单不是不会写HTML而是脑子里没有一个清晰的拆解框架。下拉菜单表面上是个点一下弹出来的小交互实际上由三个独立的问题拼在一起。1.1 显示隐藏、定位和交互触发是三个独立问题第一个问题是显示隐藏。菜单平时是看不见的点击某个按钮之后才出现再点击别处或者再次点击按钮它就收回去。这是状态管理问题。第二个问题是定位。弹出的菜单面板必须出现在按钮的附近不能跑到页面别的位置去。这里要处理好父子元素的位置关系稍不注意就会得到菜单出现在页面最底部这种离谱效果。第三个问题是交互触发。点击按钮切换点击菜单外的地方要收起按Esc键也要能收起键盘用户能用Tab键进到菜单里操作。这属于事件和可访问性范畴。把这三个问题分开想每一步要做什么就很清晰。反过来如果不拆解东写一行西写一行最后代码跑起来全靠运气。1.2 为什么我劝你手写而不是直接上Bootstrap或者jQuery插件Bootstrap的dropdown确实做得成熟功能也全但它的代码被压缩在组件库里很多细节被封装掉了。我说句实在话如果你连一个基础版都手写不出来直接去读Bootstrap源码反而容易一头雾水因为组件库要考虑的主题、API兼容性、边界情况太多。另外在实际业务里你不是每次都能引一个完整组件库的。很多后台项目、活动页、营销页要求就是轻量、无依赖、加载快这个时候一个手写的下拉菜单反而比引个框架更划算。维护起来也简单——出了问题你打开文件就知道哪儿写错了不会抓瞎。从面试角度看就更直接。2026年还能看到前端面试八股文里大量出现手写下拉菜单、手写轮播图、手写Tab切换这类问题说明面试官默认你是要能手写基础交互的。Bootstrap下拉菜单面试题是一个很经典的考察点但能讲清楚原理的人确实不多。1.3 30分钟的时间分配逻辑这个时间不是拍脑袋定的是按三个问题划分的前10分钟搭HTML和基础CSS把结构问题解决中间10分钟写CSS动画把丝滑度做出来最后10分钟写JavaScript交互逻辑并且处理几个必要的健壮性问题。新手最容易犯的错是前10分钟就钻进细节里反复调样式比如纠结边框圆角到底用8像素还是10像素。我的建议是先让功能跑通再优化视觉代码能正常工作之后再谈好不好看。2. 十分钟搭骨架HTML结构决定后续少改代码结构是最不能偷懒的部分HTML写对了后面CSS和JavaScript都会很顺手。这一步我按一个典型的导航栏场景来做。2.1 这份HTML为什么用button而不是a标签看下面这个结构菜单项是按钮不是链接。nav classsite-nav aria-label主导航 ul classmenu-list li classmenu-item button typebutton classmenu-btn aria-haspopuptrue aria-expandedfalse 产品中心 /button div classsubmenu a href/products/a产品 A/a a href/products/b产品 B/a a href/products/c产品 C/a /div /li /ul /nav触发下拉的入口用button有两个原因。一是语义化button天生具备键盘可聚焦、可回车触发的能力无障碍适配的成本最低。二是这个入口本身不负责页面跳转它的职责是展开和收起菜单用a标签去承接点击反而容易产生既跳转又展开的混乱。2.2 三级嵌套结构的写法逻辑这个结构是nav套ulul里每个li放一个按钮加一个菜单面板。菜单面板用div或ul都可以但要注意li和div的层级关系面板必须和按钮处于同一个li内部这样后续定位时相对关系才干净。再说一下为什么不把面板挂到body下面去。有些方案喜欢用JavaScript把面板移动到body然后根据按钮位置计算坐标再弹出来好处是能突破父级overflow的裁剪限制但代价是每次页面滚动、窗口缩放都得重新计算位置代码复杂度直线上升。手写速成版完全没必要这么做把面板留在li里用绝对定位解决简单可靠。2.3 基础样式和定位上下文这里要先把一个关键属性定下来li设成相对定位菜单面板设成绝对定位并以按钮底部为锚点。* { box-sizing: border-box; margin: 0; padding: 0; } .site-nav { background: #1f2933; padding: 0 24px; } .menu-list { list-style: none; display: flex; gap: 8px; } .menu-item { position: relative; } .menu-btn { background: transparent; border: none; color: #f5f7fa; font-size: 15px; line-height: 48px; padding: 0 16px; cursor: pointer; } .submenu { position: absolute; top: 100%; left: 0; min-width: 168px; background: #ffffff; border-radius: 8px; box-shadow: 0 8px 24px rgba(0, 0, 0, 0.12); padding: 8px 0; }定位是absolutetop取了100%也就是紧贴着按钮的下边缘。left保持0让面板左边和按钮左侧对齐。min-width给一个相对保守的值避免面板内容太窄。这一阶段完成后页面应该能正常显示导航栏菜单面板是看得到的还没处理隐藏逻辑。你别急着隐藏先看明白它长什么样子再进入下一步。3. 丝滑的核心用CSS过渡写出一套不卡顿的展开收起动画丝滑这个词不是玄学它的本质是当菜单状态从隐藏切换到显示时中间经历了一段连续的视觉变化。这一步是全篇的关键我会把原理讲透。3.1 为什么display:none切换会让动画直接失效很多新手的第一个版本是这样写的隐藏时display:none显示时display:block。这个方案功能上没问题但动画没法做。原因很直白——display是个只能离散切换的属性元素要么在布局里要么不在不存在一半在布局里这种中间状态。所以当你试图给display加过渡浏览器根本处理不了。结果就是菜单一瞬间出现、一瞬间消失视觉效果硬邦邦的谈不上丝滑。正确的思路是把元素的可见性和元素在布局中的存在这两件事拆开只对可以被差值计算的属性做动画。3.2 opacity、transform、visibility的三件套方案我用的是很多前端项目中实际采用的组合opacity控制透明度transform控制位移动画visibility控制元素是否参与事件和可访问性树的构建。.submenu { position: absolute; top: 100%; left: 0; min-width: 168px; background: #ffffff; border-radius: 8px; box-shadow: 0 8px 24px rgba(0, 0, 0, 0.12); padding: 8px 0; /* 隐藏状态 */ opacity: 0; visibility: hidden; transform: translateY(-8px); pointer-events: none; transition: opacity 0.25s ease, transform 0.25s ease, visibility 0.25s ease; } .menu-item.open .submenu { opacity: 1; visibility: visible; transform: translateY(0); pointer-events: auto; }这组样式里有几个细节值得单独说。第一transform用了translateY(-8px)让菜单从比最终位置高8像素的地方向下移动到位。这个从上方滑下来再停住的运动过程大脑会感知成从上往下展开丝滑感主要就来自这里。第二visibility也写进了transition列表里。visibility是个离散属性浏览器处理transition时会让它在一段动画周期结束时才切换到visible收起时则在一开始就切回hidden。实际效果是展开时整个滑入动画完整走完最后才变为可见收起时先马上不再可交互再走淡出和上移动画。这个组合让显示和隐藏都不露馅。第三pointer-events:none很关键。如果不加这个菜单虽然视觉上是透明的、不可见的但依然会拦截鼠标事件可能出现明明看不见菜单却点中了菜单里的链接这种莫名其妙的情况。加了它隐藏时菜单完全穿透鼠标事件显示时再恢复。3.3 动画参数怎么调才有质感我用的时长是0.25秒这是实测下来比较舒服的区间。再来看看ease曲线它是cubic-bezier(0.25, 0.1, 0.25, 1)特点是开始加速快、结束减速慢正好匹配下拉菜单那种被重力拉下来的手感。如果你想更有弹性质感可以试cubic-bezier(0.34, 1.56, 0.64, 1)这个曲线会有一个轻微的回弹但建议回弹幅度不要太大否则会显得浮夸。如果你希望菜单从左下角那个方向生长出来而不是垂直往下掉可以把transform-origin设置为top left再把初始transform改成scale(0.9)配合位移。具体用哪种取决于页面交互风格但核心思路相通控制好初始状态和结束状态的中间插值就能获得连续动画。4. JavaScript的边界控制点击切换、点外关闭与键盘可达CSS把视觉状态做好了但什么时候切换状态这件事得由JavaScript来决定。这里不依赖jquery就用原生ES6代码量非常少。4.1 点击按钮切换open状态并处理好互斥点击产品中心按钮菜单展开再点一次菜单收起。这个逻辑用class的增删来实现有一个容易忽略的点是互斥——当打开第一个菜单时必须确保第二个菜单位置是关闭的否则两个菜单同时在页面上挂着视觉上会很难看。const menuItems document.querySelectorAll(.menu-item); function closeAllMenus() { menuItems.forEach((item) { item.classList.remove(open); const btn item.querySelector(.menu-btn); btn.setAttribute(aria-expanded, false); }); } menuItems.forEach((item) { const btn item.querySelector(.menu-btn); btn.addEventListener(click, (e) { e.stopPropagation(); // 如果当前这一项本来就是开的那这次点击应该把它关掉 const willOpen !item.classList.contains(open); closeAllMenus(); if (willOpen) { item.classList.add(open); btn.setAttribute(aria-expanded, true); } }); });这里有两个值得展开讲的细节。一是e.stopPropagation()必须加。如果不加点击按钮的事件会冒泡到document上的点击监听器那个监听器的逻辑又是点击菜单外部就关闭结果就是刚点开菜单立刻被外部关闭逻辑收回去了看起来就像按钮失灵。这是新手最容易踩的坑之一。二是用willOpen变量在closeAllMenus()之前保存状态。因为closeAllMenus()会把所有open移除如果不先记录点击时的状态后面就没法判断这次点击是要开还是关了。4.2 点击菜单外部自动收回用事件委托实现接下来处理点其他地方收起这个交互。有种做法是给每个可能出现的外部元素都绑监听这显然太笨了。正确的做法是在document上挂一个点击监听器判断点击目标是不是落在菜单内部。document.addEventListener(click, (e) { if (!e.target.closest(.menu-item)) { closeAllMenus(); } });closest方法从目标元素向上查找直到遇见指定的选择器。如果啥都没找到说明这次点击发生在菜单外部直接全部关闭。这个写法一行代码解决了所有情况也没有性能问题。4.3 键盘可达性Esc关闭和Tab切换前端基础交互还有一个经常被忽略的维度键盘可操作性。至少在菜单这个场景里三个键是必须处理的。Tab键可以让焦点自然移动到按钮上这是button元素的语义原生能力不需要额外代码。真正要处理的是Esc键用户打开菜单后想快速关闭按Esc应该是直觉操作。document.addEventListener(keydown, (e) { if (e.key Escape) { closeAllMenus(); // 把焦点还给触发菜单的按钮方便下一次快捷操作 const openItem document.querySelector(.menu-item.open); if (openItem) { openItem.querySelector(.menu-btn).focus(); } } });菜单面板里的链接本身也能通过Tab键依次聚焦这样键盘用户用完整覆盖。还要在菜单项失焦到外部时自动关闭菜单用focusout事件监听一下就行但这个属于锦上添花基础版可以先不做。5. 避坑指南六个在实测中真实出现过的翻车现场这部分是我实际写这个组件时踩过的坑。每个坑都曾经让我莫名其妙地排查了好一阵子把所有现象和解决方案列出来你在自己写的时候可以直接对照排查。5.1 父级overflow:hidden把菜单剪掉了有些导航栏为了做横向滚动会给导航容器加overflow-x:auto或者overflow:hidden。而这个属性一旦加上子元素的绝对定位如果越出了容器边界就会被裁剪掉。菜单明明是展开状态却只露出被裁剪的一小块看不见完整内容。我当时是被导航栏的横向滚动需求逼着踩了这个坑。解决方案分情况如果只是为了隐藏滚动条考虑用scrollbar-width等样式隐藏而不是给父级加overflow:hidden如果确实需要overflow那就要考虑把菜单面板挪到不会被裁剪的层级或者在容器内预留足够空间。基础版的下拉菜单最省事的做法是别在导航容器上滥用overflow。5.2 点击按钮后菜单闪一下就被收回了这个现象很经典就是我在讲stopPropagation的时候提到的那个坑。症状是点击按钮菜单啪地展开了一瞬间又啪地消失了整个过程快得好像只是闪了一下。原因是点击事件既触发了按钮自己的监听器也冒泡到了document的监听器。document的监听器一执行发现点击目标在最外层没匹配到.menu-item就把菜单关了。排查思路就是检查有没有类似的全局事件监听器并且确认按钮监听器里有没有调用stopPropagation。5.3 快速重复点击产生了粘滞感当你以非常快的速度连点按钮两次时菜单有时会表现得很奇怪感觉像卡住了一样。原因在于动画需要时间而你的两次点击在很短时间内切换了两次open状态。第一次点击添加open菜单开始展开动画第二次点击移除open菜单掉头播放收起动画。这种来回切换确实会产生卡顿感。这个问题要分两部分看。如果只是快速点击同一个按钮用willOpen方案可以保证逻辑正确视觉上也能接受因为每次点击都是明确的从当前状态切换。真要彻底优化可以引入一个锁变量在动画进行期间忽略点击事件但这对一个下拉菜单来说有点过度设计。基础版能保证状态正确性就够了不必追求过度优化。5.4 页面滚动或窗口缩放后菜单面板位置不对了这个坑在菜单面板脱离布局容器的时候特别容易出现。如果你没有把面板放在li内部而是用JavaScript手动挂到body上再配合position:fixed和按钮的getBoundingClientRect()去定位那么页面一滚动或者窗口一缩放面板就留在原地和它该依附的按钮脱节了。我的解决方案前面已经说了把面板保留在li内部用position:absolute配合position:relative定位。这样无论页面怎么滚动面板都会跟着li一起走不需要写任何重定位的代码。5.5 hover触发的下拉菜单有延迟和误触问题桌面端很流行鼠标悬停就展开菜单看起来挺方便但有个致命伤用户不小心划过导航栏时菜单可能会被误触发而且子菜单和按钮之间的空白地带会把鼠标移过去的过程打断。我给自己的项目的处理方式是沿用点击触发不使用hover。如果产品经理一定要求hover也需要加一个150到200毫秒的延时逻辑让鼠标在一段时间内没有离开才展开同时用定时器处理菜单区域的悬停保持。这些逻辑写起来不难但会显著增加测试成本所以基础版本里做到点击触发就够了。5.6 移动端点不出菜单或出现300毫秒延迟我在测试移动端的时候遇到过点按钮偶尔没反应的情况后来发现是在移动端模拟器里没有把按钮的click事件正确处理。现代移动端浏览器对click事件的支持已经很完善正常情况下不会出现300毫秒延迟但如果你是拿旧文档里的代码或者某些老项目改的要留意有没有touch事件处理干扰了click的正常触发。如果你的页面需要非常精确的移动端点击响应可以在按钮上考虑使用pointerdown事件来替代click但要注意这可能会影响滚动操作。对普通项目来说click事件仍然是优先级最高、适配最好的选择。6. 从速成到进阶这段代码还能往哪个方向扩展30分钟写完基础版之后思路不应该就此打住。把这段代码向几个方向延伸一下能帮助你更透彻地理解前端组件化的本质。6.1 把菜单改造成一个数据驱动的组件现在代码里菜单项是写死的。实际项目里导航数据通常会从后端接口拿这时候可以去掉静态HTML改成用一个数组渲染菜单。const menuData [ { title: 产品中心, children: [ { label: 产品 A, href: /products/a }, { label: 产品 B, href: /products/b } ] } ];然后通过数组的map方法生成对应的DOM结构。这样菜单内容变化时不需要改HTML改数据就行。如果再用上框架或者组件化方案数据驱动就成了常态。这可以说是从写一个小功能向设计一个可维护模块迈出的关键一步。6.2 hover展开、手风琴模式、移动端抽屉菜单的衍生下拉菜单这个交互模式稍加变化就能套用到好几个场景。把click换成mouseenter和mouseleave就可以得到hover展开版本把同一时间只允许有一个菜单打开的逻辑抽出来就变成了手风琴效果把菜单面板改成从屏幕左侧滑入的全屏抽屉配合transform做位移动画就成了移动端常见的抽屉导航。无论怎么变核心还是那三件事状态管理、定位方案、动画平滑度。你把基础版吃透了这些衍生场景理解起来都不会有障碍。6.3 一个额外的小优化菜单内的搜索过滤如果用在下拉选择器场景里可以在面板顶部加一个输入框监听输入事件去过滤菜单项。这时候你会在状态管理之外再学到派生状态的更新逻辑对理解前端框架里的数据流非常有帮助。再补充一个我在实际项目中踩过的小坑如果你在菜单里加了输入框注意点击输入框本身不能被当成点击外部而关闭菜单用closest(.menu-item)判断依然有效但也要记得处理输入框内部的点击冒泡问题。这个30分钟的练习你做一遍、做两遍、做三遍每一遍理解都会不一样。我第一次写完也丢了不少细节后面反复测试才发现这些坑。动手把它跑通一次比看十遍文章都有用。