短信客户端URL预览触发加密URL逻辑异常技术问询

看起来你遇到的是很典型的自动URL预览机制干扰业务逻辑的问题——两年前正常运行的功能，现在栽在了iPhone短信这类客户端的自动预览上，确实挺头疼的。我来梳理下问题根源和可行的解决办法：

问题根源 #

iPhone Messages（包括不少主流短信/社交APP）会自动对短信里的URL发起GET请求，目的是抓取页面内容生成预览卡片。这个请求本质上相当于“提前点击”了你的链接，而你的链接里携带的加密密钥是绑定业务逻辑的（比如一次性验证、会话授权），被预览请求消耗后，用户真正点击时密钥已经失效，或者逻辑已经被提前执行了。

可行的解决方案 #

1. 通过请求标识区分预览爬虫和真实用户 #

大多数自动预览的爬虫会带上独特的请求头或User-Agent，你可以通过后端判断来过滤这些请求：

• 抓包确认预览请求的User-Agent：比如iPhone Messages的预览请求通常会包含MessagesPreviewAgent或Applebot这类标识；
• 后端逻辑里针对这类User-Agent，只返回纯预览内容（比如静态的提示页面），不执行核心业务逻辑，也不消耗加密密钥。

2. 把密钥从URL参数移到用户交互触发的请求中 #

直接把密钥放在URL里很容易被预请求抓取，换个方式传递：

• 让链接指向一个过渡页面，页面里包含隐藏的密钥，当用户手动点击页面上的「确认执行」按钮时，再通过POST请求把密钥发送到后端执行逻辑；
• 这种方式下，预览爬虫只会GET过渡页面，不会触发POST请求，自然不会误执行逻辑。

3. 优化密钥的使用规则 #

如果不想改页面逻辑，可以调整密钥的机制：

• 给密钥增加「预览豁免」规则：后端检查请求是预览爬虫时，不消耗密钥，仅返回允许预览的内容；
• 设置密钥的使用次数为「最多两次」：一次给预览请求（不执行逻辑），一次给用户真实请求（执行逻辑），同时配合短有效期避免滥用。

4. 禁用URL预览（终极兜底方案） #

如果不需要预览功能，可以在短信内容里对URL做特殊处理，比如在URL中间插入一个不可见的特殊字符（比如零宽空格​），这样短信客户端识别不到完整的URL，就不会生成预览了。不过这个方法可能影响用户体验，谨慎使用。

内容的提问来源于stack exchange，提问作者Sudhir