html无法直接实现@用户提示，需javascript监听input事件分析光标前文本并调用后端接口获取用户列表，用contenteditable div插入带data-user-id的不可编辑span实现mention。
HTML 本身不支持直接实现“@用户”输入提示（比如像微博、飞书那样键入 @ 后弹出成员列表），它只是静态标记语言；真正实现该功能必须配合 JavaScript，且需后端提供用户数据接口。别被“超详细”误导——核心不在 HTML，而在交互逻辑和前后端协作。
HTML 只负责提供基础输入容器和语义结构
你唯一需要在 HTML 做的，是准备一个可编辑的内容区域，并明确标注其用途。用 contenteditable 比 <input> 或 <textarea></textarea> 更合适，因为 @ 提示常需内嵌高亮、插入富文本（如带 avatar 的 mention 节点）。
常见错误：直接给 <textarea></textarea> 绑定 @ 监听——它无法渲染 HTML、不支持光标精确定位、无法高亮已插入的 mention。
- 用
<div contenteditable="true"> 作为编辑区，设 <code>role="textbox"保持可访问性 - 避免设
white-space: pre-wrap外的其他换行控制，否则影响光标计算 - 不要用
innerHTML直接拼接用户输入内容，防止 XSS；插入 mention 时应创建安全的span元素并设置data-user-id - 在
input回调中调用getSelection()+getRangeAt(0)获取光标位置 - 向前遍历文本节点，提取光标前最近的“单词”，正则用
/@(\w*)$/（注意：\w 不含中文，如需支持中文用户名，改用/@([\w\u4e00-\u9fa5]*)$/） - 仅当匹配到非空
@xxx且光标紧贴其后时，才调用showMentionPanel() - 建议框本身用绝对定位
<div class="mention-panel"> 渲染，挂载在 <code>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>组合渲染 - 给该
span设contenteditable="false"，确保用户无法误编辑其中文字 - 监听
keydown事件，在e.key === 'Backspace'且光标位于 mention 左侧时，阻止默认行为并删除整个span - 按
Enter时，检查光标是否在 mention 内或紧邻其后，避免把 mention 当作普通字符换行
最易被忽略的一点：移动端 Safari 对
contenteditable的光标 API 支持极差，getSelection().getRangeAt(0)在 iOS 16+ 才稳定可用；如需兼容旧版 iOS，得降级为 textarea + 自定义光标模拟，成本陡增——上线前务必真机验证。 - 每次输入变化（如
JavaScript 怎么检测 @ 并触发建议框
关键不是监听 keydown，而是监听 input 事件 + 实时分析光标前的词边界。因为用户可能粘贴文本、用方向键移动、或在中间插入 @。
常见错误：只在 keydown 中判断 e.key === '@'——漏掉粘贴 @xxx、或从别处复制带 @ 的段落。
