HTML 本身没有“设置文档推荐应用”的能力，所谓“推荐应用”是操作系统或浏览器根据文件扩展名、MIME 类型、Content-Disposition 响应头等综合判断的，HTML 页面无法强制指定哪个 App 打开下载文件。
为什么 <a> 链接点击后没用指定 App 打开？
用户常误以为加个 target 或 rel 就能控制本地 App 启动，其实不行。浏览器对 <a href="xxx.pdf"> 这类链接的处理逻辑是：
- 先检查该文件扩展名（如
.pdf、.xlsx）是否被系统注册了默认应用 - 再看响应头里有没有
Content-Type（如application/pdf）和Content-Disposition: attachment -
<a>标签自身没有任何属性能绕过这个机制
download 属性只影响保存行为，不触发外部应用
加上 download 属性（如 <a href="report.xlsx" download>下载报表</a>）只会让浏览器跳过预览、直接唤起“另存为”对话框——它禁用了内建 PDF 查看器、Office Online 等在线预览，也同时屏蔽了系统默认 App 的自动调用。
- 适用场景：你想确保用户保存文件，而不是在浏览器里打开
- 不适用场景：你想引导用户用 WPS 打开
.docx，或用 Adobe Acrobat 打开.pdf - 注意：
download对跨域资源无效（会退化为普通跳转）
真正能影响“推荐应用”的只有服务端响应头
前端 HTML 无权决定用什么 App 打开，但后端可以配合设置关键响应头，让浏览器更准确地识别文件类型并交由系统处理：
立即学习“前端免费学习笔记（深入）”；
-
Content-Type必须准确，比如application/vnd.openxmlformats-officedocument.spreadsheetml.sheet比application/octet-stream更容易唤起 Excel -
Content-Disposition: inline（不是attachment）允许浏览器尝试内建预览或调用默认 App - 某些系统（如 iOS）还会读取
X-Content-Type-Options: nosniff来防止 MIME 类型嗅探误判
示例 Nginx 配置片段（针对 .epub 文件）：
location ~ \.epub$ {
add_header Content-Type application/epub+zip;
add_header Content-Disposition "inline; filename=$request_filename";
}
如果用户环境里某个文件始终打不开或总弹保存框，问题大概率不在 HTML 标签上，而在服务端没发对 MIME 类型，或者客户端系统根本没注册对应应用——这时候改 HTML 是白忙活。
