本文揭示了一个隐蔽但常见的 css 布局故障：当页面切换配合 `transition` 使用时，自动聚焦 `` 元素（尤其是 `ch` 单位宽度的搜索框）会触发浏览器强制滚动/重定位容器，导致绝对定位容器“无故左移”，且 devtools 中完全不可见原因。
在构建多页问卷式 Web 应用时，采用 CSS transition 实现页面滑动（如通过 left: 0% / left: 100% 切换绝对定位子页）是一种轻量、高性能的方案。然而，你可能突然遭遇一种“幽灵位移”——页面容器在切换到某一页时无提示地向左偏移约 70–100%，且该偏移仅在启用 transition 时出现；禁用 transition 后一切正常；更令人困惑的是：DevTools 的 Styles、Computed、Layout 等面板中查不到任何相关样式变更或 transform/offset 值，仿佛位移凭空发生。
根本原因并非 CSS 写错，也非 JavaScript 操作 DOM，而在于一个被广泛忽视的浏览器行为：聚焦（focus）可聚焦元素时，浏览器会主动尝试将其滚动进视口（scroll into view），即使该元素本就可见、甚至被 overflow: hidden 的父容器裁剪。这一行为在 transition 动画执行期间尤为敏感——当页面容器正通过 left 变化进行动画时，浏览器的“自动聚焦对齐逻辑”会与 CSS 定位机制产生竞态，强行调整容器位置以满足“让 input 可见”的隐式目标，从而覆盖你的 left 声明，造成视觉跳变。
尤其危险的是：若该 使用 ch 单位定义宽度（如 width: 24ch），不同浏览器对 ch 的计算存在细微差异（参考 Stack Overflow 讨论），叠加聚焦触发的布局重排，会进一步放大位移偏差（Chrome ≈ -100%，Firefox ≈ -70%）。
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
✅ 可靠解决方案（经实测验证）：
将 的聚焦时机与启用状态解耦，避免在 transition 过程中存在“已渲染但未启用 + 被聚焦”的中间态：
<!-- 初始状态：禁用且不聚焦 --> <input type="search" id="search-field" disabled aria-hidden="true" />
/* 确保禁用态不影响布局（可选） */
input:disabled {
opacity: 0.01; /* 避免 display:none 导致 layout shift */
pointer-events: none;
}// 在 transitionend 事件中统一处理：
element.addEventListener('transitionend', () => {
const input = document.getElementById('search-field');
input.disabled = false; // 先启用
input.removeAttribute('aria-hidden');
input.focus(); // 再聚焦（此时容器已静止）
});⚠️ 关键注意事项：
立即学习“前端免费学习笔记（深入）”；
- ❌ 不要在 transition 开始前或进行中调用 input.focus()；
- ❌ 不要依赖 autofocus 属性（它会在元素插入 DOM 时立即触发，早于 transition）；
- ✅ 使用 disabled + focus() 组合，是目前最稳定、跨浏览器兼容的规避方式；
- ? 若需深度诊断类似问题，可启用 Chrome DevTools 的 Rendering > Paint Flashing 和 Layout Shift Regions，并监听 scroll 事件检查是否被意外触发；Firefox 可使用 Layout View > Box Model > Scroll Into View 调试选项。
总结来说，这不是 CSS 的 bug，而是浏览器对可访问性（聚焦即可见）的强干预与 CSS 动画控制权之间的冲突。理解这一底层机制，能帮你快速识别同类问题——只要页面切换涉及 transition + focus() + overflow: hidden 容器 + 可聚焦表单控件，就应优先排查聚焦时机。将“启用”与“聚焦”分离，是让动画回归可控的黄金实践。
