我盯着屏幕上那道“请用原生JavaScript实现一个拖拽组件”的题目，手指悬在键盘上方停了整整十秒。考场里空调嗡嗡作响，后排有人已经开始噼里啪啦敲代码了，那声音像雨点砸在铁皮屋顶上。

这道题我见过。上周熬夜刷题时，在某个技术博客的评论区看到过类似思路。可此刻脑子里只剩一团浆糊——mousedown、mousemove、mouseup三个事件的名字明明就在嘴边，却怎么也对不上坐标计算的逻辑。我深吸一口气，先写下最简单的结构：一个容器，一个被拖拽的方块，然后强迫自己从零开始推演。

web考试的诡异之处就在这里。它从不问你“什么是事件冒泡”这种能靠背诵过关的概念题，而是直接丢给你一个半成品页面，让你在四十分钟内把它变成能交互的活物。上学期期末考flex布局，题目是“用三种方式实现圣杯布局”。我用了flex+margin负值，隔壁同学用了grid，还有个狠人直接写float+position硬怼。最后我们都过了，但老师评语里写了句扎心的话：“你们都会用工具，但没几个人说得清为什么flex的order属性会影响视觉顺序而不是DOM顺序。”

这大概就是web考试的真相——它考的不是代码量，而是你脑子里有没有那张知识地图。记得有次模拟考，题目是“优化这个页面的加载速度”。我洋洋洒洒写了压缩图片、合并CSS、加CDN，结果扣了八分。标准答案第一条是“减少HTTP请求”，第二条是“把CSS放在头部、JS放在尾部”。我那些花哨操作全在优化边界之外，属于“做了没用，不做也行”的锦上添花。那次之后我才明白，考试里的每个条件都有它存在的意义，就像生产环境的代码，每一行都得对最终呈现负责。

今天这道拖拽题，我最后用了最笨的办法：先给方块绑定mousedown记录初始坐标，再在document上监听mousemove计算位移，最后mouseup时解绑。写完抬头一看，还剩十二分钟。检查时发现个细节——如果鼠标移出浏览器窗口再松开，mouseup事件会丢失，方块会卡在半空。我赶紧补了个mouseleave的兜底逻辑，心里暗骂自己差点漏掉这个真实场景里必踩的坑。

交卷时我瞟了眼旁边同学的屏幕，他用了pointer events替代传统鼠标事件，还加了触摸屏适配。那一刻我意识到，web考试从来不是终点线，它更像一面镜子，照出你平时写代码时的习惯和盲区。那些在项目里得过且过的地方，那些靠复制粘贴蒙混过关的样式，都会在考试的压力下原形毕露。反过来，真正理解浏览器工作原理的人，哪怕遇到没见过的题目，也能像拆解乐高一样，把需求拆成一个个基础API的组合。

走出考场，手机弹出一条推送：“2025年Web开发趋势预测”。我笑了笑，没点开。毕竟下个月还有一场关于性能优化的考试，而眼下最要紧的，是去食堂抢最后一份红烧肉。