autofocus在在线运行工具中基本不可靠，因其仅在html解析时生效，而动态渲染、隐藏区域、多tab切换及ios safari拦截等均使其失效；应改用js在用户触发后显式focus并校验activeelement。
autofocus 属性在在线运行工具中基本不可靠，尤其在移动端和 SPA 场景下几乎必然失效；真正有效的做法是用 JavaScript 在用户触发动作后显式调用 focus()，并加 document.activeElement !== input 校验。
为什么在线运行工具里 autofocus 几乎总是不工作
在线运行工具（比如代码编辑器 + 运行按钮的组合页）通常具备几个关键特征：动态渲染、多 Tab 切换、初始隐藏区域、以及频繁的 DOM 重绘。这些都会让 autofocus 失效：
-
autofocus只在 HTML 解析阶段生效，而在线工具的编辑器区域（如<textarea></textarea>或<div contenteditable>）往往是 JS 动态插入或条件渲染的，此时属性被完全忽略 <li>常见布局中，代码编辑区初始为 <code>display: none（比如在“编辑”Tab 下），等用户切换过去时，autofocus已错过时机 - iOS Safari 对非手势触发的聚焦一律拦截——页面一打开就弹键盘？浏览器直接拒绝
- 即使桌面 Chrome 暂时成功，密码管理器、翻译插件、或框架内部逻辑（如 Monaco Editor 的 focus 管理）也可能在几毫秒内抢走焦点，你根本看不到报错
- 如果页面是“编辑 → 运行”流程，且编辑区是主操作区，
<textarea name="code"></textarea>或带contenteditable的容器可作为聚焦目标 - 但如果工具提供预设模板（如“Hello World”按钮），点击后应聚焦编辑区，而非依赖页面加载时的
autofocus - 避免给运行按钮加
autofocus——它不是输入控件，且用户不会用键盘连续点击运行 - 绝对不要给输出区域（
<pre class="brush:php;toolbar:false;"></pre>或<div class="output">）加 <code>autofocus，它们不可聚焦，加了也无效可靠替代方案：用 JS 控制聚焦时机
把聚焦行为绑定到明确的用户意图之后，才能跨设备稳定生效：
- 监听“新建文件”或“打开模板”按钮的
click事件，在回调中执行editorEl.focus() - 在 Tab 切换（如从“结果”切回“编辑”）后，用
setTimeout(() => editorEl.focus(), 0)延迟聚焦，确保 DOM 已就绪且可见 - 若使用 React/Vue，用
useEffect或mounted钩子 +ref调用.focus()，但务必加if (editorRef.value && document.activeElement !== editorRef.value)防覆盖 - 对
contenteditable元素，需额外调用getSelection().collapse(editorEl, 0)确保光标在开头，否则聚焦后可能无光标
容易被忽略的细节：软键盘与可访问性冲突
在线工具常被开发者忽略两点实际影响：
- 移动端聚焦后软键盘弹出，可能遮挡运行按钮或输出区——这不是
autofocus的问题，而是没做scrollIntoView({ block: 'nearest' })或 viewport 适配 - 屏幕阅读器用户还没听到“代码编辑器”这个角色描述，光标就跳进去了，导致上下文丢失；应在聚焦前确保
aria-label或aria-labelledby已就位，并考虑首次加载时延迟 300ms 再聚焦
- 监听“新建文件”或“打开模板”按钮的
应该聚焦哪个元素：别默认选代码编辑框
不是所有“第一个输入框”都该自动聚焦。在在线运行工具中，要按用户真实动线判断：
