按钮按下去没反应，用户骂的互总是后端接口慢。其实后端日志显示请求根本没到——前端事件绑错了元素。交结感这种事我碰过不下十次，互总每次排查到最后都发现是交结感交互层的小裂缝，不是互总性能瓶颈。Web交互的交结感坑，大多埋在你以为“理所当然”的互总地方。

刚入行时觉得交互就是交结感写写 onclick，后来才明白，互总用户手指戳屏幕的交结感那一下，背后是互总事件冒泡、焦点管理、交结感状态同步、互总无障碍属性一堆东西在打架。交结感比如一个简单的下拉菜单，用 mouseover 还是 click？移动端上 hover 基本是废的，但桌面端用户又习惯悬停展开。最后我干脆用 pointerdown + 延迟判断，虽然代码丑了点，但至少不会让用户觉得“这破菜单怎么点不动”。

还有一次做表单校验，实时提示输入错误。结果用户打字快的时候，每个字符都触发一次正则匹配，页面卡成幻灯片。后来改成 debounce 加 200ms，顺滑了。但新的问题来了：用户输完立刻点提交，校验还没跑完，直接提交了错误数据。你看，交互的节奏感比逻辑正确更折磨人。你得猜用户下一步要干嘛，还得留后路。

键盘交互更是个隐形战场。你试试只用 Tab 键操作一个自定义下拉框——很多组件库直接跪了。焦点陷阱、Esc 关闭、方向键选择，这些在鼠标用户眼里根本不存在，但对依赖键盘的人来说就是能不能用的区别。我现在的习惯是，写完任何交互组件，先拔掉鼠标，只用键盘走一遍流程。走不通就重构，没商量。

移动端的触摸反馈也很有意思。你给按钮加个 :active 样式，iOS 上默认会延迟 300ms 才触发，因为要等双击缩放。后来用 touch-action: manipulation 干掉延迟，但安卓某些浏览器又抽风。最后干脆用 pointer 事件统一处理，再配合 user-select: none 防止长按选中文本。这些破事文档里不会写，全靠踩坑踩出来。

动画也是重灾区。用 CSS transition 做侧边栏滑出，结果在低端安卓机上掉帧到 20fps。换成 transform: translateX 加 will-change 才好点。但 will-change 不能滥用，用多了内存暴涨。交互流畅度是个玄学，有时候加个 backface-visibility: hidden 就能救回来，有时候得直接上 requestAnimationFrame 手动控制。没有银弹。

最后说个反直觉的：不是所有交互都要“即时反馈”。比如搜索框输入时，你每敲一个字就发请求，用户反而觉得卡。延迟 300ms 再发，体验更好。但删除操作必须立刻给反馈——哪怕只是按钮变个颜色。用户对“破坏性操作”的容忍度极低，对“查询类操作”反而有耐心。这个度，只能靠用户测试调，拍脑袋定不了。

现在我看任何 Web 页面，第一反应不是“好不好看”，而是“Tab 键能不能走通”、“点快了会不会重复提交”、“断网了有没有兜底提示”。交互这东西，做得好没人夸，做得差人人骂。但每次看到用户顺畅地完成一个复杂操作，那种“他们根本没意识到交互存在”的感觉，还挺上瘾的。