链接在网站内有效，分享后却失效：检查完整地址

转发前先找出缺失部分

在网站内点击活动日程可以正常打开，但把agenda.pdf或以斜杠开头的路径复制进邮件后，收件人却打不开文件。查阅的问题正涉及这个困扰，以及构建地址时基础路径的一部分被替换的意外。先不要责怪邮件或短链接服务，应检查复制了什么：相对引用需要上下文才能得到完整目的地。在网站内它完全可能有效；离开该上下文分享时，应准备完整、核对过的网页URL。本指南区分解析出地址和证明文档存在、内容适合受众这两件事。

确认赋予路径含义的基准地址

MDN说明，解析会使用基础URL，不是简单拼接两个字符串。HTML文档的基础地址通常与页面位置有关，但带href的base元素可以改变它。如果代码里只有路径，不要猜缺失的域名或目录。优先使用浏览器复制链接地址的功能并检查结果，而不是手抄属性。维护网站时，应先比较文档真实基准与预期目的地，再修改链接。不要把向整页添加base标签当成快速补救；它可能改变其他引用的解析，并不只影响当前调查的那一个。先确定上下文，才能判断修改会影响什么。

核对示例中的斜杠作用

三个表达式用URL构造器演示解析。example.invalid与文件名均为虚构，不能证明有可下载日程。基准以event/结尾时，agenda.pdf会得到该目录内的地址。引用若以/agenda.pdf开头，结果从同一来源的根路径开始。基准只有event、没有末尾斜杠时，解析agenda.pdf会替换最后片段，结果又在根路径。MDN和RFC3986介绍这些区别。不要凭习惯添加或删掉斜杠。应选择对应真实资源的地址，检查完整结果，而非只看最后文件名。构造地址本身不证明可用。

记录示例结果：首先是https://example.invalid/event/agenda.pdf，其次与第三项都是https://example.invalid/agenda.pdf。两项结果相同，不证明event目录存在，也不表示你的网站应省略它。真实测试应分别记录计算地址、打开的文档与受众访问；没有观察的阶段标未验证。这些只是本地字符串解析结果，并非下载或服务器可用性检查。

new URL("agenda.pdf", "https://example.invalid/event/").href
new URL("/agenda.pdf", "https://example.invalid/event/").href
new URL("agenda.pdf", "https://example.invalid/event").href

解析后再验证资源

检查得到的URL是否包含预期域名和路径。构造器可能给出语法有效、却指向错误资源的地址；它不授予权限，也不检查内容。目的地公开且无秘密或个人资料时，可以把完整地址交给WikiURL检查工具，记录HTTP响应与最终网址。还需打开资源，确认是正确日程，且目标受众能访问。200响应本身不能证明这两项。有重定向时，批准前检查最终目的地。私有文档使用经过授权的方法，避免送给外部工具。技术响应、内容与权限应分开判断，不能用一个结果替代所有证据。

分发批准地址并测试收到的版本

完整URL核对后，将其用于最终邮件或文档。编辑器支持链接名称时，即使文字写活动日程，也应保留批准的目的地。不要只为缩短显示文字，就把真实地址换成不完整路径。如需短链接或二维码，以批准的完整目的地在WikiURL生成，并测试准确版本。短链接服务不会猜相对引用缺失哪个网站或目录，也不会替你发布文件。应从收到的或导出的版本重新打开，而非仅看编辑器预览。这样才能发现原版与分发材料的区别，并测试读者真正会走的路径。

一起保存上下文、目的地和证据

保存原引用、使用的基准、解析后的URL和分享版本，便于目录、模板或网站变化后复现。不要不加区分地修改网站所有相对引用；问题是把链接带出上下文，不是禁止页面内有效的技术。文件移动时，检查仍流通的引用和材料，与负责人商定如何保持访问。不要承诺旧二维码自动更新。有用结果是指向预期文档的完整地址，加上真实路径测试。WikiURL帮助检查和分发地址，但解析不能代替内容核对或访问权限。记录这些责任与对应观察，避免混为一谈。