HTML无法直接实现@用户提示，需JavaScript监听input事件分析光标前文本并调用后端接口获取用户列表，用contenteditable div插入带data-user-id的不可编辑span实现mention。
HTML 本身不支持直接实现“@用户”输入提示（比如像微博、飞书那样键入 @ 后弹出成员列表），它只是静态标记语言；真正实现该功能必须配合 JavaScript，且需后端提供用户数据接口。别被“超详细”误导——核心不在 HTML，而在交互逻辑和前后端协作。
HTML 只负责提供基础输入容器和语义结构
你唯一需要在 HTML 做的，是准备一个可编辑的内容区域，并明确标注其用途。用 contenteditable 比 <input> 或 <textarea> 更合适，因为 @ 提示常需内嵌高亮、插入富文本（如带 avatar 的 mention 节点）。
常见错误：直接给 <textarea> 绑定 @ 监听——它无法渲染 HTML、不支持光标精确定位、无法高亮已插入的 mention。
- 用
<div contenteditable="true">作为编辑区，设role="textbox"保持可访问性 - 避免设
white-space: pre-wrap外的其他换行控制，否则影响光标计算 - 不要用
innerHTML直接拼接用户输入内容，防止 XSS；插入 mention 时应创建安全的span元素并设置data-user-id
JavaScript 怎么检测 @ 并触发建议框
关键不是监听 keydown，而是监听 input 事件 + 实时分析光标前的词边界。因为用户可能粘贴文本、用方向键移动、或在中间插入 @。
立即学习“前端免费学习笔记（深入）”；
常见错误：只在 keydown 中判断 e.key === '@'——漏掉粘贴 @xxx、或从别处复制带 @ 的段落。
- 在
input回调中调用getSelection()+getRangeAt(0)获取光标位置 - 向前遍历文本节点，提取光标前最近的“单词”，正则用
/@(\w*)$/（注意：\w 不含中文，如需支持中文用户名，改用/@([\w\u4e00-\u9fa5]*)$/） - 仅当匹配到非空
@xxx且光标紧贴其后时，才调用showMentionPanel() - 建议框本身用绝对定位
<div class="mention-panel">渲染，挂载在document.body下，避免被父容器overflow: hidden截断
为什么不能只靠前端 mock 用户列表
真实场景下，@ 输入往往需模糊搜索（如输“张”列出“张三”“李小张”）、区分部门/角色、限制可见范围（如私聊只能 @ 对方）。这些逻辑必须由后端完成。
常见错误：前端硬编码 const users = [{id:1,name:'张三'}] ——上线即失效，且无法做权限过滤。
- 每次输入变化（如
@zha）应节流（setTimeout300ms）后发请求，路径类似GET /api/users?keyword=zha&context=chat_123 - 响应必须包含
id、name、avatar_url，最好带is_online用于状态标识 - 前端收到后只做渲染，不自行过滤或排序；后端应返回已按相关度排序的结果
- 若用户量大（>1000），首次打开对话时可预加载高频用户，但搜索仍走接口
插入 mention 后怎么保持编辑体验不崩
插入成功后最常出问题的是光标丢失、回车换行异常、删除键行为错乱——根源在于把 mention 当成纯文本处理。
常见错误：用 el.innerText += '[@张三](id:1)' 这类字符串拼接，导致后续无法精准定位或删除整个 mention 块。
- 插入时创建独立
span，添加 classmention和data-user-id="1"，内部用<img>+<span>组合渲染 - 给该
span设contenteditable="false"，确保用户无法误编辑其中文字 - 监听
keydown事件，在e.key === 'Backspace'且光标位于 mention 左侧时，阻止默认行为并删除整个span - 按
Enter时，检查光标是否在 mention 内或紧邻其后，避免把 mention 当作普通字符换行
最易被忽略的一点：移动端 Safari 对 contenteditable 的光标 API 支持极差，getSelection().getRangeAt(0) 在 iOS 16+ 才稳定可用；如需兼容旧版 iOS，得降级为 textarea + 自定义光标模拟，成本陡增——上线前务必真机验证。
