无法强制预览，浏览器行为由服务端响应头决定：content-type: application/pdf 触发预览可能，content-disposition: inline 才允许内嵌预览，attachment 则强制下载；同源下可用 iframe 或 pdf.js 实现可靠预览。
无法强制。浏览器决定是预览还是下载，<a></a> 标签本身没有能力“强制”在线预览；它只负责发起一个 HTTP 请求，后续行为完全由浏览器策略、响应头和用户设置共同决定。
为什么 <a href="doc.pdf"></a> 有时下载、有时预览
关键不在 HTML 标签，而在服务端返回的响应头：
-
Content-Type: application/pdf是必要条件，但不充分 —— 多数现代浏览器会据此尝试内嵌预览 -
Content-Disposition: attachment; filename="xxx.pdf"会直接触发下载（哪怕你加了target="_blank"） -
X-Content-Type-Options: nosniff若配合错误的Content-Type（比如text/plain），会导致浏览器拒绝 inline 渲染 - 某些 CDN 或 Nginx 配置默认对 PDF 加上
Content-Disposition: attachment，这是最常见翻车点
能做的实际控制手段（仅限同源 & 公开可访问 PDF）
如果你能控制服务端，这才是唯一有效的干预点：
- Nginx 配置中移除或覆盖 PDF 的
Content-Disposition：location ~* \.pdf$ { add_header Content-Disposition ''; } - Apache 中用
.htaccess清除该头：Header unset Content-Disposition - Node.js/Express 中显式设置：
res.setHeader('Content-Type', 'application/pdf'); res.setHeader('Content-Disposition', 'inline'); - 确保 PDF 路径是完整 URL（
https://domain.com/file.pdf），不是file://协议（本地开发时常见失败）
前端侧的“伪强制”技巧（有限且不可靠）
这些方法不能改变浏览器本质行为，但可小幅提升预览概率：
- 用
target="_blank"+rel="noopener"：新标签页打开时，Chrome/Firefox 更倾向调用内置 PDF 查看器而非下载 - 避免在 URL 后拼接查询参数如
?v=1.0，某些旧版 Safari 会因此忽略Content-Type - 不要用
download属性：<a href="x.pdf" download></a>明确告诉浏览器“必须下载”，与目标相反 - 移动端（尤其 iOS Safari）基本无视所有前端技巧 —— 它看到 PDF 就弹下载框，
target="_blank"也无效
真正需要稳定预览体验的场景（比如管理后台、文档中心），别指望 <a></a> 标签。要么服务端配好响应头后改用 <iframe></iframe>，要么直接上 pdf.js；前者轻量但依赖同源，后者重但可控。跨域、带认证、iOS 全页展示——这些需求下，<a></a> 就只是个跳转入口，不是预览方案。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
