微动效响应纪律与 Sub-100ms 瞬时悬停

在桌面端生产力软件中，微动效（Micro-motion）的目标是帮助人脑建立空间连续性，任何拖泥带水的过渡都会破坏专业用户的操作节奏。

动效是空间锚点，绝非娱乐表演

宣传片或消费级应用可以有长达 600ms 的翻转卡片。但在 Tuff 中，用户每天需要完成成百上千次高频点击：

• 动效存在的唯一价值是作为空间锚点：告知视线信息“从何处展开、收纳至何处”。
• 绝大部分微动效应控制在 90ms～180ms 之间。
• 动效绝不允许阻塞下一次交互。

悬停（Hover）必须 0ms 瞬间响应

鼠标指针在屏幕上移动是用户极具目的性的探索动作。 铁律：鼠标滑入元素热区的瞬间，背景色高亮与文字墨水必须在 0ms 内立即可见！

任何试图在悬停状态上添加渐变淡入淡出的做法，都会让操作手感变得像“泡在浆糊里移动”，严重破坏操控跟手性。

为什么在 Hover 上过渡颜色会导致迟滞感？

人脑神经传导对光标视觉反馈的预期在 100ms 以内（Sub-100ms Threshold）。 如果开发者声明了：

// 违规反模式！
.btn { transition: background-color 200ms ease; }

当光标滑过一排按钮时，按钮颜色慢吞吞地变色。大脑在尚未看到完整反馈前指针已经离开，产生强烈的“界面响应迟钝、系统很卡”的生理错觉。

状态形变（Morphing）的过渡类名隔离

那么，什么时候才允许平滑过渡颜色？仅在组件发生长周期的语义状态切换时（例如普通态切换为危险确认态）。

为了防止状态过渡污染正常的悬停交互，TuffEx 的规则是：颜色过渡属性必须挂载在临时形变类上，绝不可写在元素本体上。下面是 TxModeChip 的写法（略去了变量的兜底值）：

.tx-mode-chip {
  // 悬停必须瞬间生效，零延迟
  &:hover:not(:disabled) {
    background-color: var(--tx-mode-chip-fill-hover);
    color: var(--tx-mode-chip-ink-hover, var(--tx-mode-chip-ink));
  }

  // 仅在状态形变期间由 JS 挂载 .is-morphing
  &.is-morphing {
    transition: 
      background-color 240ms var(--tx-ease-out-strong), 
      color 240ms var(--tx-ease-out-strong);
  }
}

通过类名隔离，悬停保持了 0ms 的雷厉风行，而业务状态切换则享有平滑优雅的形变。

现在 TuffEx 的组件都守这条规则：悬停一律瞬间换色。颜色过渡要么只在 .is-morphing 存在时生效（选中、展开、聚焦这类状态切换时挂上，最长的一段颜色过渡走完就摘掉），要么只写在悬停根本不改颜色的元素上。跟着指针走的高亮也算悬停，例如 TxSearchPanel 的候选项、TxCascader 展开的路径，同样瞬间换色。