无法通过纯 javascript 完全准确复现浏览器原生 `` 的文本编辑逻辑；依赖 `string.fromcharcode()` 或手动 dispatch 事件均不可靠，因箭头键、退格、组合键等行为缺乏统一标准实现。
在前端开发中，有时需要根据一连串 KeyboardEvent（如 keydown、keypress、input）推断出其最终产生的字符串内容——例如在远程调试、自动化测试、无障碍辅助或自定义编辑器场景中。但关键限制在于：这些事件已真实触发在某个聚焦元素上，而你无法访问该元素的 DOM 引用，也无法安全地创建并重放事件到一个临时 中（Chrome 等现代浏览器会忽略非用户激活上下文下的部分合成事件）。
表面上看，似乎可通过监听 key 或 code 属性 + 维护光标位置 + 模拟编辑操作来“手写”一个字符串状态机。但实践证明，这极易偏离浏览器实际行为。例如：
- Backspace 和 Delete 的作用范围取决于当前选区（selectionStart/selectionEnd），而选区状态本身由历史事件隐式决定；
- ArrowLeft/ArrowRight 不改变字符串，但影响后续输入位置；Shift + Arrow 则扩展选区，进而影响下一次 Backspace 或输入的覆盖范围；
- Tab 键默认会移焦，但在 contenteditable 或表单中可能插入制表符（取决于 event.preventDefault() 是否被调用）；
- Ctrl+V / Cmd+V 触发粘贴，其内容来自剪贴板（异步、受权限限制），且格式可能含 HTML 或富文本；
- IME 输入（如中文拼音）会产生 compositionstart → compositionupdate → compositionend 流程，中间的 keydown 并不直接对应可见字符。
因此，不存在标准化、跨浏览器、可靠且轻量的 API 能仅凭 KeyboardEvent 序列还原最终字符串。浏览器内核的编辑逻辑深度耦合于渲染引擎（如 Blink 的 EditingCommand）、布局状态与用户交互上下文，无法被 JS 层完整抽象。
✅ 正确应对策略：
- 优先复用原生 或 ：若可控制宿主环境，将事件代理至隐藏但真实可聚焦的 input 元素，并实时读取其 .value（注意需同步触发 input 事件以确保值更新）；
- 采用成熟编辑器库：如 CodeMirror 6 或 Tiptap，它们封装了完整的编辑状态机、选区管理与命令系统，支持插件化扩展，且持续适配浏览器变更；
- 服务端协同处理：在可信环境中（如 Electron、WebView 或浏览器扩展 content script），通过消息通道将原始事件序列发送至具备 DOM 上下文的模块执行并返回结果。
⚠️ 注意事项：
- 避免基于 event.key 的简单映射（如 "a" → "a"），它无法处理 Shift+A → "A"、CapsLock 状态、AltGr 键位等；
- 不要尝试用 document.execCommand()（已废弃）或 InputEvent 构造函数模拟编辑——多数浏览器会静默忽略或产生不一致行为；
- 若必须做轻量模拟（如仅处理 ASCII 字母+数字+退格），请明确限定输入场景，并在文档中声明其不兼容性（如：“不支持 IME、不处理选区、不兼容 macOS Cmd 快捷键”）。
归根结底，文本编辑不是字符串拼接，而是状态驱动的交互协议。与其重复造轮子，不如信任浏览器，或交由经过千锤百炼的专业编辑器处理。
