mailto协议不发送邮件,仅调用默认邮件客户端并预填字段;需严格URL编码参数,支持to/cc/bcc/subject/body,多收件人用英文逗号分隔,不支持附件与自动发送。
协议本身不发邮件,只是告诉浏览器“请调用系统默认邮件客户端,并预填字段”。它不经过服务器、不校验
邮箱
有效性、也不反馈是否真的发送成功——这点必须一开始就明确。
mailto 链接的正确写法与参数格式
最简形式是
,但只要加参数,就必须严格遵循 URL 查询字符串规则:第一个参数用
开头,后续用
连接,且所有非 ASCII 字符(中文、空格、换行、标点)必须
编码。
常见错误包括:
直接拼接中文 subject 或 body,导致链接被截断或客户端解析失败
误用
代替
表示空格(
是表单
的规则,
不认)
body 中换行用
而不是
(CR+LF),部分客户端(如 Outlook)会忽略纯
正确示例(TypeScript 中构造):
多个收件人、抄送与密送的写法差异
参数其实可以省略,直接把邮箱写在
后面;但
和
必须显式声明,且多个地址之间用英文逗号
分隔(不是分号,不是顿号)。
注意点:
判断邮箱是否合法类
判断邮箱是否合法类
下载
收件人列表过长(比如超过 5 个)时,某些邮件客户端(尤其是移动端 Mail app)可能只识别第一个
在部分旧版 Outlook 中不生效,建议优先用
或服务端发送
不要在
中混用
和路径后直接写邮箱,例如
是无效的,应写成
为什么用
标签而不用
+
虽然 HTML 规范允许
,但实际中问题更多:
会导致字段名和值以
形式平铺进 body,格式丑陋、不可控,且无法插入换行或结构化内容
表单提交会刷新页面(即使 target="_blank"),中断用户当前操作流
无法动态构造内容——表单字段名是静态的,不能根据 JS 计算结果实时生成 subject 或 body
所以更可控的做法是:用 JS 拼好完整
链接,再绑定到一个
上,点击时设置
或创建临时
并
。
容易被忽略的兼容性与体验细节
看似简单,但真实项目里常踩的坑集中在这些地方:
Mac 上 Safari 对长
(超 2000 字符)可能截断,iOS Mail 则更敏感,建议控制在 1000 字以内
没有默认邮件客户端的设备(如某些 Chromebook、无 Outlook 的 Windows 纯浏览器环境)点开会报错或静默失败,无法捕获异常
用户可能用 Webmail(Gmail、Outlook Web)作为默认“邮件程序”,此时
会跳转到网页版,但新版 Gmail 已限制自动填充
,只保留
和
如果页面本身是 HTTPS,而用户本地邮件客户端不支持安全上下文调用,极少数情况下会触发警告(虽少见,但测试时得覆盖)
真正上线前,至少要在 Windows(Outlook)、macOS(Mail)、iOS(Mail)、Chromebook(Gmail Web)上各点一次,看预填内容是否完整、换行是否生效、中文是否乱码——截图比文档管用。
mailto:href="mailto:support@example.com"?&encodeURIComponent()+%20+application/x-www-form-urlencodedmailto\n%0D%0A\nconst email = 'support@example.com';
const subject = encodeURIComponent('咨询订单 #12345');
const body = encodeURIComponent('客户姓名:张三\n订单状态:待发货\n联系方式:138****1234');
const mailtoLink = `mailto:${email}?subject=${subject}&body=${body}`;tomailto:ccbcc,bccccmailto:to=xxxmailto:?to=a@b.com&to=c@d.commailto:a@b.com,c@d.comformaction="mailto:"enctype="text/plain"name=valuemailto:location.href.click()bodymailto:bodytosubject