结论：textarea中文输入体验问题与table布局无关，根源在于事件监听方式和DOM操作时机；input事件仅在“上屏”时触发，需配合compositionstart/compositionend判断输入状态，并在isComposing为false时执行清洗逻辑，blur兜底，自适应高度需setTimeout延迟设置。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
直接说结论：<table> 布局本身和输入法完全无关，真正影响中文输入体验的是 <code><textarea></textarea> 的事件监听方式与 DOM 操作时机；用 <table> 做表单只是结构问题，别让它背锅。
<h3>textarea 中文输入法下 input 事件只在“上屏”时触发</h3>
<p>用户打“上海”，拼音过程 <code>b-e-i-h-a-i 不会触发 input 事件，只有按下空格或回车让“上海”真正写入 value 时才触发一次。这不是 bug，是浏览器对 Composition API 的标准实现。
常见错误现象：
- 在
input回调里直接改textarea.value（比如截断、格式化），会导致光标跳走、候选框消失 - 用
keydown做字数限制，完全拦不住粘贴、拖入、语音输入 - 表格布局里把
<label></label>和<textarea></textarea>放不同<td>，但没设 <code>for/id关联，导致点击 label 无法聚焦 —— 这不是输入法问题，是可访问性缺失compositionstart / compositionend 必须配对监听
这两个事件才是判断“用户是否正在用输入法组词”的唯一可靠信号。仅靠
input无法区分“真实输入完成”和“中间拼音状态”。立即学习“前端免费学习笔记（深入）”；
实操建议：
- 用
useRef（React）或闭包变量缓存isComposing状态，在compositionstart设为true，compositionend设为false - 所有清洗逻辑（如字数截断、敏感词过滤）只在
isComposing === false且input触发时执行 -
blur事件要做兜底：失焦时若value变了但没触发过input（比如 Safari 切换标签后回来），手动补一次处理
表格布局中 textarea 自适应高度的坑
<table> 本身不阻碍自适应，但它的 <code>display: table行为会让scrollHeight计算异常，尤其在 iOS Safari 下。关键点：
- 不要在
input回调里同步设height = scrollHeight + 'px'，iOS 渲染有延迟，必须包一层setTimeout(() => {}, 0) - 避免给
<textarea></textarea>父<td> 设固定 <code>height或vertical-align: bottom，这会压扁内容区，导致滚动条不可见 - 如果用了
resize: none，记得加overflow-y: auto，否则超出部分直接被裁掉，用户看不见自己输的内容
最常被忽略的一点：表格布局里
<textarea></textarea>的rows属性只是初始渲染提示值，它不影响事件行为，也不参与输入法兼容性——别指望靠调大rows来“改善输入体验”，该卡还是卡，该跳还是跳。 - 用
