type="email" 不提供后缀提示功能，仅支持格式校验、typeMismatch验证及唤起带@的软键盘；需用type="text"配合JavaScript监听input/keydown事件、匹配预设数组、动态更新DOM实现可控补全。

input type="email" 本身不提供后缀提示功能，仅做基础格式校验；要实现“输入用户名后自动显示 @qq.com、@gmail.com 等后缀选项”，必须额外引入 JavaScript 行为层，不能只靠 HTML 属性。

为什么 type="email" 不会自动弹出后缀列表

浏览器对 type="email" 的原生支持仅限于：提交时检查是否含 @ 和域名结构、调用 checkValidity() 时触发 typeMismatch、移动端唤起带 @ 符号的软键盘。它不解析用户已输内容、不匹配常见域名、也不渲染下拉菜单——这些全是自定义交互逻辑。

• 即使加了 list 属性指向 <datalist>，Chrome/Safari 也**不支持 type="email" 与 datalist 联动**（仅 type="text" 或未设 type 时生效）
• placeholder="name@example.com" 是静态提示，不会随输入动态补全
• 所谓“自动提示”实际是监听 input 事件 + 匹配预设数组 + 手动插入 DOM 或更新 input 值

用 type="text" + 自定义 JS 实现后缀提示更可控

把输入框设为 type="text"，反而更容易接管行为：可自由截取 @ 前内容、过滤 mailArr 数组、高亮匹配项、响应键盘操作。关键点不是“伪装成 email”，而是“在 text 框里模拟邮箱输入体验”。

anything-to-html

将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。

下载

• 监听 input 和 keydown 事件，区分用户是打字、按上下键还是回车
• 输入值不含 @ 时，才基于预设数组生成提示项；一旦含 @，立即隐藏下拉层（避免出现 user@@qq.com）
• 用 setSelectionRange() 控制光标位置，让补全后光标停在 @ 后，方便继续输入域名
• 不要直接修改 input.value 触发无限循环，改用 input.setRangeText() 或先 preventDefault() 再赋值

常见兼容性坑：移动端键盘与焦点管理

iOS Safari 对 input 动态聚焦/失焦极其敏感，强行 focus() 可能导致软键盘闪退；Android 部分 WebView 则可能忽略 blur()。后缀提示层必须严格绑定到当前 input 实例，且销毁时机明确。

立即学习“前端免费学习笔记（深入）”；

• 点击 document 隐藏下拉层时，需排除点击目标是提示项或 input 本身（用 e.target.closest() 判断）
• 触摸设备上，mouseenter/mouseleave 不可靠，优先用 touchstart + classList.toggle()
• 避免在 input 事件中频繁创建/移除 DOM 节点，建议复用一个 <ul class="email-suggestions"> 并只更新 innerHTML
• 若页面有多个邮箱框，每个实例的 mailArr 应可独立配置，而非共享全局数组

真正难的不是列出几个后缀，而是让用户在快速输入时，既不打断节奏、又不误触选项、还能在失去焦点后恢复原始值——这些细节决定了提示功能是锦上添花，还是反向劝退。