PDF 打开而不是下载：先检查链接

先明确收件人需要什么

你发送活动日程，按钮写着下载，文件却在标签页打开。另一人本来想阅读，却收到下载。这两种情况都不能单独证明链接损坏。修改 URL 前，先决定要方便阅读、交付副本，还是同时提供两者，并确认收件人的实际设备发生了什么，而不只看你自己的电脑。

查阅的问题反映两种需要：通过 HTML 下载外部 PDF，以及不受浏览器偏好影响地显示 PDF。本指南以公开日程为例。WikiURL 帮助检查 URL 的响应和目标，不配置文件服务器，也不代替访客的阅读器。应先区分请求的内容、服务器给出的指示，以及浏览器如何处理这些指示。

响应头影响文件呈现方式

MDN 说明，Content-Disposition 表示在浏览器内显示或作为附件处理。RFC 6266 定义 inline 和 attachment。示例是两种可选响应，不是一起发送的配置块。Content-Type 表示 PDF 类型，filename 建议文件名。这些是交付文件的服务器所返回的响应头；把文字写在按钮或加进网址，不会配置服务器响应。

Inline 表达显示内容的意图，attachment 请求下载处理，但不保证相同视觉体验。MDN 提醒，浏览器、设置及其他因素都会影响下载。文件可能自动保存，也可能随后打开。请托管负责人检查最终文件的真实响应。如果只需修改某个日程，不要要求对网站所有文档作全局更改。

Content-Type: application/pdf
Content-Disposition: inline; filename="programa.pdf"

Content-Type: application/pdf
Content-Disposition: attachment; filename="programa.pdf"

不要把链接名称当成内容

示例使用虚构地址，不能实际访问。测试前用已发布的真实域名替换 example.invalid。确认目标交付的是批准的日程，而不是介绍页、私人登录页或错误。路径以 .pdf 结尾只是线索，不是内容验证。重命名 URL 不会把 HTML 变成 PDF，也不会修复损坏文件；先确认实际资源。

如果你管理网站，在浏览器网络工具中检查文件请求，查看最终响应的 Content-Type 和 Content-Disposition。否则向负责人提供 URL、实际现象和预期结果，请其检查正确文件，避免发送带 Cookie 或凭据的截图。保留批准的原稿：改文件名或响应头不等于内容更新，也不证明日程日期已经修正。

https://example.invalid/documentos/programa.pdf

Download 属性并非通用命令

在自己控制的页面，可以提供带 download 的 HTML 链接。MDN 将其作用限定于同源 URL 及受支持的 blob、data 情况。对于其他来源的 URL，该属性被忽略，执行普通导航，不过目标服务器仍可通过 Content-Disposition 请求下载。不要承诺仅添加属性或修改按钮文字就能修好外部文件。

短链接为访问过程增加另一个目标，并不会把别的服务器上的 PDF 变成你自己来源的文件。二维码表示地址，也不会给浏览器安装下载指令。依赖外部托管时，使用其文档说明的选项，或向所有者索取适当的分发 URL。如果不能控制响应，清晰说明的阅读页面可能比无法保证的自动下载按钮更有用。

用 WikiURL 检查公开访问路径

在 WikiURL 的 URL 检查器输入日程的公开地址。查看 HTTP 状态，以及重定向时检测到的最终目标。不要提交私人地址、管理链接或秘密。如果终点是登录页或其他资源，先修正分享目标。200 只描述本次检查的响应，不能证明访客已经把 PDF 保存到设备，或读到了正确日程。

随后在桌面浏览器和手机上打开准备发送的同一个链接。检查标题、日期、可读性，以及是否可用现有控件保存副本。检查器不会重现每位读者的阅读器和偏好。如果技术结果与浏览器体验不同，记录两种结果及其环境；不能凭一次成功测试就保证每个人都会得到相同体验。

明确预期并保留测试记录

面向阅读时，查看 PDF 日程这样的文字不会承诺立即保存。若提供已验证的下载选项，说明文件是什么，知道大小时也写明。可以附一句阅读器打开后如何保存的提示。不要要求读者为一个日程更改浏览器的全局设置，也不要把目标藏在多个含糊按钮后；链接说明应与实际测试相符。

创建二维码或分发短链接前，记录最终 URL、文档版本和测试设备。更换托管或替换文件后再次测试，因为浏览器收到的响应可能改变。有用的结果是正确日程可供预定受众使用，并有诚实的阅读或保存说明。打开标签页与下载是不同的行为，链接文字应反映这种区别。