很遗憾，默认情况下你没法直接覆盖用户B已经缓存的301重定向，原因和解决办法咱一步步说：

为什么覆盖不了？ #

301是「永久重定向」，浏览器对它的缓存策略非常激进——大多数浏览器会默认长期缓存这个重定向规则，甚至不会遵守常规的缓存过期时间，除非用户手动清除浏览器缓存，或者缓存条目被浏览器自身的缓存清理机制淘汰。

回到你的场景：

• 用户B第一次访问旧URL时，服务器返回301跳转到新标题的URL，浏览器把这个跳转规则存进了缓存
• 当用户A把标题改回原版本后，用户B再访问旧URL时，浏览器直接用本地缓存的301规则跳转，根本不会向你的服务器发送新请求。也就是说，你的服务器哪怕现在返回200正常内容，用户B也完全接收不到。

可行的解决方案 #

1. 改用302临时重定向 #

如果你的资源标题确实存在频繁修改的可能，放弃301，改用302临时重定向。302的语义是「临时移动」，浏览器不会永久缓存这个跳转规则，每次用户访问旧URL时，都会先向服务器确认最新的跳转目标，这样标题改来改去都能实时生效。

2. 给301响应添加明确的缓存控制头 #

如果一定要用301，那必须在返回301响应时，加上Cache-Control头来限制缓存时长，比如：

Cache-Control: max-age=86400

这个配置会让浏览器只缓存该301规则24小时，到期后浏览器会重新向服务器请求，就能获取最新的重定向或者直接返回原URL的内容。如果标题变动更频繁，可以把max-age设得更短（比如3600=1小时）。

3. 优化URL设计（可选） #

如果业务允许，尽量避免把可修改的标题放进URL路径里。比如只用ID作为唯一标识：/resources/1234，然后在页面内部显示标题内容。这样不管标题怎么改，URL都不变，从根源上避免了重定向和缓存冲突的问题。

总结 #

如果标题会频繁变动，优先考虑改用302或者给301加缓存控制头；如果能调整URL结构，那是一劳永逸的办法。

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