<p>用 input 事件配合 selectionStart 或 window.getSelection() 定位光标，反向匹配最近的 # 后关键词，contenteditable 需手动派发 input 事件，建议框应锚定文本节点而非绝对定位像素。</p>
HTML 中如何监听 # 输入并触发话题标签建议？
靠原生 input 事件 + 光标位置判断就能实现，不需要框架或复杂库。关键不是“监听按键”，而是“在用户输入 # 后，立刻识别它是否处于词首位置，并提取后续未完成的关键词”。
常见错误是只监听 keydown 或 keypress：它们无法可靠获取当前输入后的完整值（尤其涉及中文输入法、粘贴、撤销等场景）。必须用 input 事件，配合 selectionStart 定位光标。
- 只在
input事件中检查值变化，避免漏掉粘贴、剪切板操作 - 每次触发都用正则从光标位置往前匹配最近的
#\w*，而不是简单地split('#').pop() - 注意中文输入法下
compositionstart/compositionend会干扰，建议在compositionend后再执行一次建议逻辑
contenteditable 区域里怎么准确定位 # 后的文本？
普通 input 或 textarea 有 selectionStart，但 contenteditable 需要自己算光标在文本中的偏移。直接读 innerText 会丢格式、换行、空格；读 innerHTML 又混着标签。
推荐做法：用 window.getSelection() 获取当前 Range，再用 Range.toString() 和前后文本拼接出“光标前的纯文本”，再反向查找最后一个 # 的位置。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 别用
document.caretPositionFromPoint()—— 兼容性差，且不适用于触摸设备 - 如果编辑区域有富文本（比如加粗、链接），建议把建议逻辑限定在纯文本节点内，跳过
script、style、iframe等非内容节点 - 性能敏感时，加个
requestIdleCallback节流，避免每输一个字都重算
为什么按了 # 没反应？常见兼容性陷阱
最常踩的坑不是逻辑写错，而是事件没绑对地方或被拦截了。
-
contenteditable元素默认不触发input事件 —— 必须手动dispatchEvent(new Event('input', { bubbles: true }))在keyup或compositionend后补发 - 移动端软键盘回车键可能触发
form.submit()，导致页面刷新，建议给表单加onsubmit="return false"或event.preventDefault() - Safari 对
selectionStart在contenteditable中的支持不稳定，iOS 15+ 才较可靠；降级方案是监听beforeinput（但 Chrome/Firefox 支持度不一）
建议列表 DOM 插入和定位怎么不抖动？
建议框绝对定位本身没问题，但“跟随光标”容易因滚动、字体加载、动态高度而跳动。不要用 getBoundingClientRect() 直接套光标位置 —— 光标在行末换行时，它的 bottom 值会突变。
更稳的做法：把建议框插入到编辑容器内部、紧挨当前光标所在文本节点之后，用 insertBefore 或 appendChild，再用 position: absolute + transform: translateY(-100%) 上推一层，这样它始终锚定在文档流里。
- 避免用
top/left算像素位置 —— 字体加载延迟会让第一次计算失准 - 建议列表
z-index至少设为1000，否则可能被fixed导航栏盖住 - 用户点击建议项后，记得清除选中态并恢复光标到插入位置末尾，否则下次输入会覆盖刚插进去的标签
