应避免在 input 事件中直接 setstate，改用 onchange 并结合 compositionstart/compositionend 手动管理 iscomposing 状态，仅在非组合态时更新 state 和执行清洗逻辑。
input 事件里直接 setState 就会打断 IME
React 函数组件中，useState 每次调用都会触发重渲染；而中文输入法（如拼音“shu”）在 composition 过程中，每按一个键就发一次 input 事件。高频更新不仅卡顿，更会让浏览器判定 DOM 被外部篡改，强制终止当前 IME 会话——表现为刚输“zh”，候选框消失、光标跳走、值变空。
实操建议：
- 不要在
input事件回调里直接调用setState({ value: e.target.value }) - 改用
onChange事件：它天然忽略 composition 中间态，只在用户确认选词（compositionend）或直接输入完成时触发 - 若需实时响应（如搜索建议），加防抖，并仅在
e.isComposing === false时执行请求
compositionstart/compositionend 必须手动监听
原生 JS 或自定义 Hook 场景下，没有框架帮你拦截 IME 状态。一旦漏掉 compositionstart，后续所有 input 都会被当成“真实输入”，导致清洗逻辑误删未完成的拼音串。
实操建议：
- 用
useRef缓存isComposing状态，初始化为false - 在
compositionstart中设为true，在compositionend中设为false，并在该回调里同步最终值到 state - 所有对
e.target.value的清洗、截断、格式化操作，都加守卫：if (!isComposing.current) { /* 执行 */ }
textarea 和 input 对 IME 的行为差异很小，但 contenteditable 完全不可靠
textarea 和 input[type="text"] 在主流浏览器中对 IME 的支持基本一致，可放心使用。但 contenteditable 是另一回事：WebKit（Safari）、Blink（Chrome）、Gecko（Firefox）对其光标定位、候选框锚点、回车换行的处理各不相同，极易出现光标漂移、换行失效、候选框错位。
实操建议：
- 除非必须富文本（如 @ 用户、语法高亮），否则别用
div[contenteditable]替代input或textarea - 若必须用，禁用任何动态 DOM 修改（比如实时插入
span高亮），这会重置 IME 上下文 - 提交前务必把内容提取为纯文本（
element.textContent），并塞进隐藏的<input type="hidden">字段
list + datalist 不影响 IME，但 type 值选错会间接破坏输入体验
datalist 本身不干预 IME 流程，但它绑定的 input 类型若选错，可能触发校验或输入限制，干扰用户输入。例如 type="email" 会在输入“@”后强制校验，导致拼音未上屏就被截断；type="number" 则可能屏蔽中文字符输入。
实操建议：
- 联想输入场景统一用
type="text"或type="search"，语义清晰且无额外限制 - 确保
list属性值与<datalist id="..."></datalist>的id完全一致（大小写、空格、符号均敏感） -
<option></option>只认value，且必须是非空、去首尾空格字符串；value=""或value=" "都不会出现在下拉中
跨浏览器 IME 适配最易被忽略的一点：不是事件没监听，而是状态没隔离。composition 过程中的中间值本就不该进 state，也不该参与任何清洗或格式化逻辑——哪怕只是 trim() 一下，都可能让浏览器丢掉整个候选上下文。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
