window.print()在表单提交后常失败，因默认提交会触发页面跳转或刷新，中断打印；须用event.preventDefault()拦截，再通过fetch提交并更新DOM后同步调用。
window.print() 可以在表单提交后立即触发打印，但必须确保它发生在用户交互上下文中，且 DOM 已完全渲染；直接在 submit 事件里调用常因页面跳转或刷新而失效。
表单提交后调用 window.print() 为什么经常失败
常见现象是点击“提交”按钮后没弹出打印对话框，或只打印空白页。根本原因是：表单默认提交会触发病理性页面跳转（action 导航）或重载，window.print() 调用被中断或执行在即将销毁的文档上。
- 不要写
<form onsubmit="window.print(); return true;">—— 即使加了return true，多数浏览器仍会在 JS 执行完后立刻导航，导致打印窗口来不及弹出 - 如果表单
action是空字符串或"#"，部分浏览器仍会触发 reload，打断打印流程 - 使用
event.preventDefault()是必要前提，否则 submit 行为无法被拦截 - 若后端返回的是新 HTML 页面（非 JSON），前端已失去对新文档的控制权，无法再调用
window.print()
推荐做法：用 JavaScript 拦截提交 + 打印 + 手动处理结果
适用于需要提交数据、同时打印确认页/回执单等场景。核心是把“提交”和“打印”解耦，确保两者都在同一文档生命周期内完成。
- 给表单绑定
submit事件监听器，第一时间event.preventDefault() - 用
fetch或XMLHttpRequest提交数据，避免页面跳转 - 在
fetch的then回调中，确保关键内容已插入 DOM（比如显示“提交成功”提示块） - 再调用
window.print()—— 此时页面未刷新，DOM 稳定，打印内容可控 - 示例关键代码：
document.getElementById('myForm').addEventListener('submit', async (e) => { e.preventDefault(); const res = await fetch('/api/submit', { method: 'POST', body: new FormData(e.target) }); if (res.ok) { document.getElementById('print-area').innerHTML = '<h2>提交成功</h2><p>订单号：' + Date.now() + '</p>'; window.print(); } });
@media print 必须针对表单结构做定制
表单通常含输入框、按钮、验证提示等，这些在打印时几乎全无意义。仅靠通用 .no-print 类容易遗漏，需结合语义明确隐藏。
立即学习“前端免费学习笔记（深入）”；
- 输入控件一律隐藏：
@media print { input, select, textarea, button, [type="submit"], [type="reset"] { display: none !important; } } - 保留只读值而非编辑态——提交后应将
<input value="xxx">替换为<span class="print-value">xxx</span>，再统一设样式 - 验证错误信息（如
aria-invalid提示）必须在打印前移除或隐藏，否则可能泄露敏感逻辑 - 用
@page { margin: 15mm; }控制纸张边距，避免表单字段被裁切 - 避免在打印样式中使用
flex或grid布局——老版 Safari 和 IE 对打印上下文中的弹性布局支持极差
移动端 Safari 和某些 Chromium 衍生浏览器不弹窗怎么办
这不是代码 bug，而是浏览器策略限制：Safari 在非主文档上下文（如 iframe）、或非直接用户手势（如 setTimeout 延迟后调用）中会静默忽略 window.print()。
- 确保打印触发点是用户真实点击（
touchend/click），不要用mouseenter或自动轮播触发 - 避免在
fetch的finally或setTimeout中调用；改用Promise.then()直接链式调用 - 对 iOS Safari，可降级方案：生成 PDF 链接（需后端支持）或引导用户手动按
Cmd/Ctrl + P - 测试时务必真机验证——模拟器常误报成功
最易被忽略的一点：表单提交后若用 location.reload() 或 location.href = ... 跳转，window.print() 一定失败。哪怕只延迟 1ms，也得确保它发生在 DOM 更新完成、且页面尚未开始卸载的窗口期内。
