301 vs 302 的抉择

大客户的”特殊要求”

Redis 缓存上线后,系统的响应时间稳定在 5ms 左右。我正准备庆祝,一个电商大客户找上门来。

“你们的短链接服务不错,“他们的技术负责人在电话里说,“但我们有个要求——必须使用 301 永久重定向。”

我愣了一下:“301?但我们现在用的是 302……”

“我们做 SEO 优化,需要把权重传递给目标页面。“他的语气很坚定,“如果用 302,搜索引擎不会传递权重,这对我们很重要。”

挂了电话,我陷入沉思。301 vs 302,这个看似简单的选择,背后是性能、SEO、统计准确性的复杂权衡。

在缓存环境下重新审视

之前我选择 302 的理由很简单：需要统计点击,需要灵活修改目标 URL。但现在有了 Redis 缓存,情况变得复杂了。

301 + 浏览器缓存

第一次访问:
客户端 → 短链接服务 → 301 → 目标 URL
浏览器缓存: short.url/abc → target.com (永久)

第二次访问:
客户端 → 浏览器缓存 → 目标 URL (不经过服务器)
速度: 0ms

优势:

• 极快:浏览器缓存后,不再请求服务器
• SEO 友好:搜索引擎会把权重传递给目标页面

劣势:

• 统计缺失:无法统计缓存后的点击
• 无法修改:即使修改数据库,浏览器仍然跳到旧地址

302 + Redis 缓存

每次访问:
客户端 → Nginx → Redis (5ms) → 302 → 目标 URL
同时: 异步写入统计

速度: ~5ms
统计: 准确记录每次点击

优势:

• 准确统计:每次请求都经过服务器
• 灵活可变:随时修改目标 URL

劣势:

• 比 301 慢:每次都要访问服务器
• SEO 不友好:权重不传递

性能对比表

我画了张对比表:

关键发现: 302 + Redis 的性能已经足够好(5ms),虽然不如 301 的二次访问(0ms),但对于短链接场景,5ms 完全可以接受。

SEO 权重到底多重要?

为了搞清楚 SEO 的影响,我专门咨询了做 SEO 的朋友老张。

“短链接场景下,SEO 权重传递不是核心需求。“他看了我的架构图后说。

“为什么?”

“你想,用户在什么场景下会点击短链接?”他反问。

“社交媒体、邮件、广告……”

“对,这些都是外链。“他解释道,“搜索引擎对外链的权重传递本来就很谨慎。而且,短链接服务本身就是一个中转层,真正的价值在于统计和追踪,而不是 SEO。”

他给我展示了 Google 的官方文档:

Google 对重定向的态度:
- 301: 传递大部分权重(约 90-99%)
- 302: 不传递权重,但也不会惩罚

对于短链接:
- 搜索引擎知道这是跳转服务
- 不会因为使用 302 而惩罚
- 关键是目标页面本身的质量

“那是不是说,我用 302 也没问题?”

“对。除非你的客户是做内容网站的,需要通过社交媒体分享来积累 SEO 权重。但大多数情况下,短链接的价值在于数据,不在 SEO。“

电商客户的需求分析

我回到大客户的需求。他们做电商,分享链接主要在:

• 社交媒体活动
• KOL 推广
• 邮件营销

“这些场景,SEO 权重传递真的重要吗?”我自问。

仔细一想:

• 社交媒体链接: 大部分是 nofollow,本来就不传递权重
• 广告链接: 也不传递权重
• 邮件链接: 更不存在 SEO 问题

结论: 这个客户对 SEO 的需求,可能是误解。

我的最终决策

经过深思熟虑,我做了决定:坚持默认使用 302,但给大客户提供可选的 301 模式。

数据库改造

首先,在数据库中增加重定向类型字段:

落地思路

• 这里省略具体语法，只保留设计层面的职责边界。
• 读这段时重点看：输入是什么、系统做哪些判断、状态如何变化、失败时如何兜底。

配置驱动的重定向

修改重定向逻辑,支持可配置:

落地思路

• 这里省略具体语法，只保留设计层面的职责边界。
• 读这段时重点看：输入是什么、系统做哪些判断、状态如何变化、失败时如何兜底。

用户 API

创建短链接时,允许指定重定向类型:

落地思路

• 这里省略具体语法，只保留设计层面的职责边界。
• 读这段时重点看：输入是什么、系统做哪些判断、状态如何变化、失败时如何兜底。

管理界面

给用户提供选择界面:

交互要点

• 前端逻辑重点是展示任务状态、错误原因和下一步操作。

统计准确性的价值

302 的最大优势是统计准确性。这为后续的数据分析打下了基础。

点击追踪

每次重定向,我都能记录:

落地思路

• 这里省略具体语法，只保留设计层面的职责边界。
• 读这段时重点看：输入是什么、系统做哪些判断、状态如何变化、失败时如何兜底。

数据分析

有了这些数据,我能提供:

实时统计:
- 过去 1 小时点击量
- 过去 24 小时点击量
- 过去 7 天点击量

用户画像:
- 地理分布: 中国 60%, 美国 20%, 日本 10%
- 设备类型: 移动端 70%, 桌面端 30%
- 来源分析: 微信 40%, 微博 30%, 直接访问 20%

趋势分析:
- 点击高峰时段
- 周期性规律
- 异常流量检测

这些数据,是短链接服务的核心价值。

如果用 301,浏览器缓存后,这些数据都会丢失。

给客户的解释

我给电商客户发了一封邮件:

主题: 关于 301 重定向的建议

您好,

关于使用 301 永久重定向的需求,我做了详细的技术分析。

301 的优势是 SEO 权重传递,但有以下限制:
1. 浏览器会永久缓存,无法修改目标 URL
2. 无法统计缓存后的点击数据
3. 对社交媒体链接,SEO 效果有限(大部分是 nofollow)

对于您的电商场景,我建议:
- 营销活动链接: 使用 302,便于统计和修改
- 官方固定链接: 可以使用 301

我们支持两种模式,您可以根据需要选择。

附件是详细的技术对比文档。

Best,
短链接团队

客户很快回复了:“理解了,我们用 302。数据统计对我们更重要。“

性能与功能的平衡

最终,我的架构是这样的:

双层缓存策略

落地思路

• 这里省略具体语法，只保留设计层面的职责边界。
• 读这段时重点看：输入是什么、系统做哪些判断、状态如何变化、失败时如何兜底。

性能监控

落地思路

• 这里省略具体语法，只保留设计层面的职责边界。
• 读这段时重点看：输入是什么、系统做哪些判断、状态如何变化、失败时如何兜底。

监控面板

实时监控:
├─ 总请求数: 10,234,567
├─ 301 重定向: 1,234,567 (12%)
├─ 302 重定向: 8,999,900 (88%)
└─ 平均响应时间: 4.2ms

缓存命中率:
├─ Redis 缓存: 98.5%
└─ 数据库查询: 1.5%

错误率: 0.01%

本章小结

301 vs 302 的权衡:

最终方案:

• 默认 302: 满足统计需求和灵活性
• 支持 301: 作为高级功能,给有 SEO 需求的客户
• Redis 缓存: 优化 302 的性能,达到可接受的响应时间
• 用户选择: 提供清晰的文档,让用户根据场景选择

核心认知:

• 短链接服务的价值在于数据,不在 SEO
• 性能优化可以用缓存解决,不必牺牲功能
• 给用户选择权,而不是替用户做决定

练习题

练习 1

如果你的短链接服务主要服务于社交媒体分享(用户分享文章、视频等),应该选择 301 还是 302? 为什么?

场景: 用户分享了一篇博客文章
- 使用 301 重定向到 blog.example.com/article-1
- 后来文章 URL 改为 blog.example.com/article-1-updated
- 由于浏览器缓存了 301,用户仍然跳到旧 URL
- 用户体验差,且无法统计

- 可以随时修改目标 URL
- 准确统计每次点击
- 通过 Redis 缓存,性能不输 301
- SEO 权重虽然不是最优,但社交媒体本身权重高,影响有限

练习 2

设计一个 API,让用户可以选择重定向类型,并说明每种类型的适用场景。

流量洪峰的隐患

性能优化完成了,301 vs 302 的权衡也解决了。系统运行得越来越稳定,用户增长迅速。

直到有一天,一个热门短链接在社交媒体上爆了。

“某明星在微博发了一条短链接,瞬间带来了数万请求。“值班同事在群里喊道,“服务器负载飙升到 80%!”

我看着监控面板,心跳加速。虽然 Redis 缓存扛住了大部分请求,但单一热门链接的瞬间流量,仍然可能压垮系统。

单个短链接的流量集中,比分散的流量更可怕。

我需要更激进的优化策略……