mailto:链接通过协议级跳转唤起系统默认邮件客户端，需正确编码参数并避免JS模拟点击；失败主因是默认客户端未设置、扩展拦截或URL未编码，无可靠成功检测机制。
用 mailto: 链接触发系统邮件客户端
直接用 HTML 按钮调用系统默认邮件程序，本质是让浏览器跳转到 mailto: 协议 URL。这不是 JavaScript 调用，而是协议级跳转 —— 浏览器识别后交由操作系统处理，最终唤起 Outlook、Mail.app、Thunderbird 等默认客户端。
关键点：按钮必须绑定一个 mailto: 链接，不能靠 JS 模拟点击或调用 API（浏览器禁止此类系统级访问）。
-
<button onclick="location.href='mailto:test@example.com'">发邮件</button>可行，但语义弱、无障碍支持差 - 更推荐用
<a href="mailto:..."><button>...</button></a>，语义清晰且天然支持键盘导航和屏幕阅读器 - 避免在
onclick里写window.open('mailto:...')—— 多数浏览器会拦截新窗口，且mailto:不支持window.open的目标参数
mailto: 参数怎么填才生效
URL 中的查询参数（如 ?subject=xxx&body=yyy）必须 URL 编码，否则空格、换行、中文等会导致截断或乱码。浏览器对未编码字符的容错差异大，尤其 Windows 上 Outlook 对编码要求严格。
-
subject和body是最常用参数；cc、bcc、to（可省略，直接写在协议头）也支持 - 换行必须用
%0D%0A（CR+LF），不能用\n或%0A单独 —— 否则部分客户端（如 macOS Mail）忽略换行 - 中文务必用
encodeURIComponent()处理，例如：encodeURIComponent('你好\n附件请查收')→%E4%BD%A0%E5%A5%BD%0D%0A%E9%99%84%E4%BB%B6%E8%AF%B7%E6%9F%A5%E6%94%B6 - 避免在
body中拼接大量动态内容 —— URL 长度超 2048 字符时，IE/Edge 会截断，现代浏览器虽放宽但仍建议控制在 4000 字以内
为什么点了没反应？常见失败原因
不是代码写错，而是环境或协议限制导致“静默失败”：没有报错，但邮件客户端根本不弹。
立即学习“前端免费学习笔记（深入）”；
- 用户没设置默认邮件客户端（尤其 Win10/Win11 新装系统，默认可能是 Web 版 Outlook，不响应
mailto:） - 浏览器扩展（如广告拦截器、隐私插件）主动屏蔽
mailto:协议跳转 - 在某些 PWA 或 iframe 沙箱环境中，
mailto:被禁用 —— 查看控制台是否有Not allowed to navigate top frame to data URL类似提示 - URL 中含非法字符（如未编码的
?、=、&）导致解析中断，此时实际发起的是不完整 URL，客户端收不到有效参数 - 移动端 iOS Safari 对
mailto:支持稳定，但 Android Chrome 在某些定制 ROM 上可能回落到 Gmail 网页版而非本地客户端
要不要加 JavaScript 回退逻辑？
纯 mailto: 无降级能力 —— 它要么唤起客户端，要么什么也不做。如果业务强依赖邮件发送，且需确保用户收到反馈，就得主动探测并提供备选。
- 无法可靠检测“是否唤起成功”，因为协议跳转后 JS 执行即中断，页面卸载前最多发个
beforeunload事件，但无法区分是邮件打开还是用户关掉了标签页 - 较务实的做法：按钮旁加小字提示 “将使用您的默认邮件程序”，并在点击后立即显示加载态（比如按钮变灰 + 文字变为“正在启动邮件…”），哪怕最终失败，用户也有感知
- 真正需要兜底时（如客服场景），应放弃
mailto:，改用后端 API 提交表单 + SMTP 发送，再通过前端 toast 提示“邮件已发送”
协议跳转本身很简单，麻烦全在环境适配和用户预期管理上 —— 默认客户端是否就位、参数是否被正确解码、移动端是否按预期行为，这些没法靠一行代码解决。
