企业官网建设流程全解析

做Web开发这几年，301和302这两个状态码算是遇到频率最高的重定向方式，但我发现不少同学到现在都没把两者的区别完全搞明白。之前接到一个模拟项目，网站要从HTTP整体迁到HTTPS，前端同事图省事配了一堆302跳转，结果线上访问是没问题，搜索引擎却不认账，旧页面权重迟迟不转移，新关键词排名一直上不来。最后定位到根因，就是"临时"和"永久"这两个词的语义用反了。

这篇文章不写概念教科书，直接从实际工作出发，把两个状态码的职责边界、服务器配置方法、踩过的坑和排查套路全部揉在一起聊。适合正在搭站的后端开发、维护线上环境的运维，还有天天被SEO指标追着跑的运营同学。我会先用生活化的类比把301和302的本质讲透，再给可抄作业的配置示例，最后整理一份常见问题速查表。看完这篇文章，你应该能在五分钟内判断某个场景到底该用301还是302。

1. 重定向状态码的本质：301和302到底在告诉客户端什么

1.1 状态码是服务器给客户端的一句明确旁白

HTTP请求是一个问答过程：浏览器问服务器"我要访问这个地址"，服务器用状态码回答"请求收到了，处理结果是这样"。状态码不是给用户看的文案，而是给浏览器、爬虫、客户端程序看的结构化信息。3开头的状态码统一表示"重定向"，意思是你要的东西我已经看到了，但它现在不在这个地址，我给你一个Location响应头，里面写着新地址，你自己再跑一趟。

你可以把301和302想象成导航App里的两种提示。301是"这个目的地已经永久搬家了，以后都用新地址来找我"，302是"这个目的地暂时不对外开放，你先去临时地址凑合一下，过段时间再回原地址试试"。两种说法看似相似，但客户端和搜索引擎处理它们的逻辑完全不同，这也是很多事故的源头。

1.2 301与302的官方语义差异

先看定义：

• 301 Moved Permanently：请求的资源已经被永久移动，以后任何对原始URL的请求都应该直接使用新的URL。
• 302 Found：请求的资源暂时被移到了另一个URL，以后对原始URL的请求仍然应该继续使用原始URL。

这里有个历史彩蛋：302最初的名字叫"Found"，语义非常模糊，后来HTTP/1.1规范也没改干净，导致很多浏览器实现是"不管301还是302，只要我用GET请求，跳转后一律变成GET"。所以官方规范后来补充了303 See Other和307 Temporary Redirect来解决语义混乱的问题。咱们后文会提到，但工程上现在依然大量用到301和302，所以理解其根本差异仍然是基本功。

从实际影响看，主要差异体现在三方面：

对普通用户来说，301和302在浏览器里看到的差异不大，甚至感知不到。但对爬虫和客户端程序来说，差别巨大。如果配置错误，轻则增加无谓的请求次数，重则让网站整整数个月的SEO工作白干。

2. 场景选型：什么时候用301，什么时候用302

2.1 用301的典型场景

凡是"旧地址以后再也不打算用了"的情况，都该用301。我实际经手过的场景主要有四类：

第一，域名更换。从一个已经运营多年的域名迁移到新域名，必须把所有页面、图片、静态资源的地址都通过301指到新域名。这时候如果用了302，老用户在搜索引擎里点击旧链接后虽然也能到达新页面，但搜索引擎会一直觉得旧域名还有效，就不会把流量和权重放下。

第二，HTTP协议升级到HTTPS。这是当前最普遍的场景。配置时在服务器层面把80端口的请求全部301跳转到443端口，返回带新链接的Location头。我见过有人为了图省事，直接把所有HTTP请求都用302转发，短期内确实能跳到HTTPS页面，但搜索引擎对旧链接的信任度会下降，而且多次临时跳转会让抓取效率变差。

第三，URL规范化。比如一个网站的页面既可以通过http://old.example.com访问，也可以通过https://old.example.com访问，搜索引擎会认为是两个不同站点。通常选择其中一个版本作为主版本，把另一个版本通过301指过去。常见的做法是把裸域名统一带www，或者反过来，总之要用301，不能两个域名都声称自己是正版。

第四，旧内容永久下线但希望用户去新的替代页面。比如原本的/article/123改成了/posts/123，旧编号以后不再复用，直接301到新地址。搜索引擎会把旧页面的外链声望转给新页面，这也是SEO迁移中最值钱的环节。

我自己的经验是，只要在需求里看到"永久"、"以后不恢复"、"域名换了"这些字眼，第一反应就应该上301。犹豫不决时宁可保守一点，也不要让一个永久变更用临时状态码撑半年。

2.2 用302的典型场景

302适合"原地址仍然有效，只是这次请求你要去别的地方处理"的场景。最常见的有三类。

登录跳转算一个。用户访问一个需要登录的页面，系统会先把他带到登录页，登录成功后带着回跳参数再回到原始地址。在这个"暂时走开一下"的过程中，原始URL本身没有任何变化，用户下次再来还是走同样的流程，所以用302非常合适。

临时活动页也算一个。比如节日大促，原页面栏位内容不变，只是临时把流量引到一个活动页，活动结束后再回到原来的页面逻辑。这里如果有缓存，可能会把用户永远留在活动页，所以要非常注意响应头的缓存控制。实在拿不准时，301一定不要用，302配合Cache-Control: no-store是更稳的方案。

A/B测试同样依赖302。当一个功能有两个版本在分流实验，后台要按用户群体或参数决定跳到哪一版。这个跳转对每个用户来说可能都不一样，绝不能让浏览器永久缓存某个跳转目标，否则实验就废了。用302的好处就在于此：每次请求都老老实实到服务器问一句"我这次该去哪"。

顺带提一句，302还可以用于"均衡负载"。一些老旧的系统用302把请求轮流指到不同机房的服务节点，但现代架构基本都用DNS或网关层负载均衡了，302这种方案只适合少数限制严格的场景。

2.3 容易被忽略的303、307和308

既然聊到选型，就得把另外三个兄弟状态码拿出来说说。HTTP/1.1时代补充了303 See Other和307 Temporary Redirect，后来又有了308 Permanent Redirect。

• 303：无论原请求是POST还是PUT，跳转后都让客户端改用GET去访问新地址。常用于"表单提交成功后跳转到结果页"，防止用户刷新页面导致重复提交。
• 307：语义和302几乎一样，都是临时重定向，但不对请求方法做任何强制转换。如果用POST发起请求，服务器返回307，浏览器会再用POST请求新地址。这点很重要，因为很多旧实现的302会把POST变为GET，导致请求体丢失。
• 308：语义和301一样是永久重定向，但同样不会更改请求方法。处理非GET请求的永久迁移时，用它比301更安全。

工程上，普通页面的GET跳转用301/302足够，但涉及API接口和表单回跳时，要多留个心眼。我见过不少团队把POST接口的301跳转当GET处理，导致客户端拿到响应后丢失了请求体，查了半天才发现是状态码语义在作怪。

3. Web服务器上的301/302配置实操

3.1 主流服务器配置示例

真正动手配的时候，第一件事就是确定自己用的是哪种Web服务器。下面给几份可以直接抄的例子。

Nginx：

Nginx里设置重定向一般用return或rewrite。return更简洁高效，适合明确的目标地址：

# 整个站点的HTTP强制跳转到HTTPS，用301永久跳转 server { listen 80; server_name old.example.com; return 301 https://new.example.com$request_uri; } # 某个旧路径永久跳转到新路径，用301 location /old/ { return 301 https://new.example.com/new/$request_uri; } # 临时活动页跳转，用302 location /promo { return 302 https://new.example.com/event/spring-sale; }

rewrite也能实现，但一般在需要基于路径正则改写时才更值得用：

rewrite ^/old/(.*)$ /new/$1 permanent; # 301 rewrite ^/old/(.*)$ /new/$1 redirect; # 302

Apache：

Apache的配置更接近人类语言，可以用Redirect或RedirectMatch指令：

# 单个路径的301永久重定向 Redirect 301 /old https://new.example.com/new # 基于正则匹配的302临时重定向 RedirectMatch 302 ^/old/(.*)$ https://new.example.com/new/$1

Apache配置文件改动后用apachectl graceful平滑生效，Nginx用nginx -s reload，不要用restart，否则会有短暂中断。

Node.js / Express：

后端代码里控制重定向状态码也很常见，Express框架只需要一行：

const express = require('express'); const app = express(); // 永久跳转 app.get('/old', (req, res) => { res.redirect(301, '/new'); }); // 临时跳转，默认就是302 app.get('/temporary', (req, res) => { res.redirect('/temp'); });

Java Servlet / Spring Boot：

@GetMapping("/old") public void redirectOld(HttpServletResponse response) throws IOException { response.setStatus(301); response.setHeader("Location", "https://new.example.com/new"); response.flushBuffer(); } // 或者用Spring Boot更简洁的方式 @GetMapping("/old2") public RedirectView redirectOld2() { RedirectView view = new RedirectView("/new"); view.setStatusCode(HttpStatus.MOVED_PERMANENTLY); return view; }

配置本身的语法不难，难的是弄清楚目标地址怎么拼。

3.2 配置时最容易踩的"路径坑"

我在代码审查里最常看到的错误有三个。

第一个是丢掉查询参数。Nginx里如果写死：

return 301 https://new.example.com/new;

那么用户访问/old?from=ad时，from=ad就丢了。正确写法是保留$request_uri或用对应变量拼上：

return 301 https://new.example.com/new$request_uri;

这里的$request_uri包含原来的URI和查询字符串，能把/old?from=ad原样带到https://new.example.com/new?from=ad。

第二个是域名带的路径重复。假设源站是https://new.example.com/blog，如果配置里不小心写成return 301 https://new.example.com/blog$request_uri，而$request_uri又包含/old，结果就变成/blog/old了。正确做法是明确"我要把旧路径映射到新页面的哪个根位置"，最好先写一个测试文件验证再上线。

第三个是特殊字符和中文路径。重定向目标URL只支持ASCII字符，如果旧路径里有中文或空格，服务器端最好对Location头做URL编码，否则部分浏览器会直接报"地址无效"。Nginx和Apache通常会自动处理一部分，但后端代码里自己拼接时一定要用encodeURI、URLEncoder.encode这类工具。

修改完配置后，我习惯用两三步自检：先看是否保留参数，再看目标URL是否可达，最后用命令行工具确认响应头。别小看这三步，能挡掉一大半线上事故。

3.3 如何验证重定向配置生效

验证重定向不是"用浏览器点一下看看能不能跳"这么简单，浏览器会默认跟随跳转，你根本看不到中间过程。最直接的方式是用curl查看响应头，限制不跟随跳转：

curl -I http://old.example.com/old

输出里会看到：

HTTP/1.1 301 Moved Permanently Location: https://new.example.com/new

HTTP/1.1 301就是要的重点。如果看到的是302 Found，说明你配错了。如果想去掉缓存因素的干扰，可以加-H "Cache-Control: no-cache"再看一遍。

要查看完整跳转链，用curl -L并设置最大跳转次数：

curl -L --max-redirs 5 http://old.example.com/old

这个方法能快速发现"跳转链太长"和"循环重定向"问题。浏览器开发者工具里的Network面板也能看到每次请求的状态码，记得勾选"Disable cache"再测试，否则浏览器缓存的301结果会干扰判断。

4. 重定向配置常见问题与排查方法

4.1 问题：重定向循环

典型的报错是浏览器显示"此网页造成了太多重定向"或ERR_TOO_MANY_REDIRECTS。原因通常是A跳B、B再跳A，形成死循环。常见场景是HTTP与HTTPS两个配置互相指，旧域名指向新域名，新域名又因为某个规则指回旧域名。

排查思路很简单，第一步先看服务器配置，确认有没有两个return规则同时命中同一个URL。第二步用curl逐步查看：

curl -I -L --max-redirs 3 http://old.example.com/

如果输出里反复出现HTTP/1.1 301且Location一直变不回http://，基本就是循环。我踩过一次很隐蔽的坑：Nginx里server块的listen 80和listen 443 ssl都写了return 301 https://new.example.com$request_uri，看起来没错，但其中一个证书配置失效，导致HTTPS端口响应失败，浏览器在两次跳转后反而报循环。后来把监听规则放全局变量里统一管理才解决。

4.2 问题：302跳转后权重丢失

这个问题的表现是：页面能访问，但搜索引擎收录一直不更新，旧关键词排名波动。原因几乎都是"永久性迁移却用了302"。搜索引擎对302的处理是"旧地址仍然存活，先抓取旧地址，临时跳转不完全信任"，所以权重不会真正转移。

我的建议是：凡是判断为永久变更，立刻改成301。如果业务方说"暂时不确定以后恢复不恢复怎么办"，那就给出时间底线——超过两周到一个月还没恢复的，就默认按永久迁移处理改成301。不要为了"以后方便恢复"而长期使用302，这个舒适区会让SEO团队很痛苦。

另外还有一层容易被忽略：CDN或中间代理可能会缓存302响应。有些缓存系统对于带Set-Cookie或特定路径的302不会缓存，但纯静态路径就说不准。如果发现"改完配置用户还在走旧地址"，优先检查CDN节点节点缓存和浏览器缓存。

4.3 问题：浏览器或CDN缓存了旧的跳转结果

301的一个副作用是浏览器会记住这个跳转，下次访问旧地址直接跳到新地址。这本来是性能优化，但在调试阶段非常烦人：你把301改成302或改成另一个地址后，浏览器还在用旧结果。

清理办法分三档：第一档是开发者工具Network面板里勾选Disable cache，然后强制刷新；第二档是用curl -H "Cache-Control: no-cache"验证服务器实际响应；第三档是换一个无痕窗口或换浏览器测试。如果是CDN缓存，需要在CDN控制台刷新对应路径的缓存，或者在响应头里加Cache-Control: no-store来控制。尤其是临时活动页，如果CDN把302结果缓存一小时，活动结束后的时间窗口里用户还是会跳到活动页，等于白加班。

4.4 问题：重定向后请求方法丢失

这里要回到之前提过的307/308。一个典型场景是：客户端向服务端提交一个POST请求，服务端返回302并指向另一个地址，浏览器按规范可能把这个POST请求变成GET请求，导致新地址收到的请求没有请求体，业务报错。

最直接的解决办法是：如果后端需要保持原请求方法，就用307或308；如果希望把POST转成GET，例如表单提交成功后跳转结果页，就用303或302并告知客户端必须用GET。这里没有"一刀切"的答案，完全取决于业务是否需要保留请求方法。

排查这类问题时，建议在服务端打印请求方法、请求头和请求体，对比跳转前后的差异。很多框架默认会把302包装成GET请求，这是框架行为，不是服务器底层错误。

5. 我在实际项目中掌握的几条避坑经验

5.1 优先用简洁规则替代复杂正则

Nginx里return指令比rewrite更容易理解，也更省性能。rewrite适合需要从URL中提取一段并重新拼接的场景，但正则写复杂后非常难维护。我曾经维护过一个老站点，一条rewrite规则写了半年没人敢碰，后来直接改用两三条return规则把所有旧路径显式列出来，反而便于排查。我的建议是：能用精确路径就不写正则，能写正则就别嵌套多层判断，尽量让每一条跳转规则一眼就能看懂。

5.2 重定向目标必须做"可达性自检"

跳转是否成功不只取决于状态码，还取决于Location指向的地址是否真的能返回200。如果配了301到新地址，但新地址本身是404，那用户只会看到一记"重定向失效"，搜索引擎也把新页面当成死链。我在验收时会写一个简单脚本，把所有要配置的旧URL和新URL成对测试，确保旧URL返回3XX、新URL返回2XX，并且在跳转链上不出现404。

5.3 重定向链越短越好

从旧URL到最终页面，中间经历多次3XX跳转会拖慢页面加载速度，也会让搜索引擎的抓取预算浪费在非内容页上。理想状态是旧URL只跳转一次直达最终URL。如果有历史原因造成中间层，比如旧域名跳中间域名再跳新域名，一定要尽快收敛成一次跳转。我曾经处理过一个项目，跳转链是6跳，最后用curl -L看到响应耗时翻了四倍，优化成单跳后用户体感快了很多。

5.4 留好日志和监控

重定向不是配完就结束的事。建议在Nginx或应用层为3XX响应单独打日志，记录来源URL、目标URL、跳转类型。这样当运营反馈"某个入口流量异常下降"时，你可以快速拉出日志看是哪个环节把流量截断了。我习惯每季度做一次重定向审计，把所有3XX响应按状态码、跳转目标、命中次数排序，一次性清理掉那些已经没人访问但还在消耗爬虫预算的旧规则。

最后再分享一个个人体会：处理301和302，最重要的不是记住代码怎么写，而是建立一张"这个变更到底是不是永久的"判断表。每次收到跳转需求，先问业务方三句话：旧地址以后还需要正常访问吗？这个跳转预计持续多久？目标地址是同一个站内的内容还是另一个系统的页面？答案如果是"旧地址以后不用了"且"持续超过一个月"，基本都是301跑不掉；如果"只是暂时引导"且"需要频繁变化"，302是更合适的选择。这套判断逻辑一旦养成，你写出的跳转规则会比很多人稳得多。