在 ThinkPHP6 里，页面已经切到指定语言，但一执行 redirect() 又恢复成默认语言，这类问题大多不是翻译文件本身出错，而是跳转后的新请求拿不到原来的语言标识。下面就从 302 跳转机制、lang 参数为什么会丢、两种可靠保持方案，以及最容易漏查的中间件与配置细节四个层面拆开说明，方便你快速判断问题落点并直接修正。
redirect() 后语言为什么会失效
ThinkPHP6 中 redirect() 返回的是一次 302 响应。这个动作会结束当前请求上下文，浏览器随后再发起一个新的请求访问目标地址。也就是说，跳转后的页面并不会继承上一个请求里临时设置好的语言状态。
很多人第一反应会怀疑语言包没有加载，其实根因通常不在这里。真正的问题是：新请求重新进入中间件流程时，LoadLangPack 需要重新判断当前语言，而它判断语言依赖的是 GET、Cookie 或 Header 中的有效标识。如果这些信息没有带过去，系统就会回退到 default_lang。
因此，用户看到的现象通常是：页面刷新了、URL 也变了，但语言突然恢复默认值。这不是旧设置“失效”，而是新请求根本没有识别依据。
为什么 redirect() 后 lang 参数会消失
最常见的写法是直接跳转到固定路径，例如：
redirect('user/profile')
redirect('/product/list')这类写法本身没有问题，但默认不会自动继承原请求里的查询参数。即使你当前访问的是 /home?lang=zh-cn，执行 redirect() 后，目标地址通常只会保留你传入的路径，不会主动把 lang=zh-cn 一起拼上。
这也是为什么语言切换在当前页有效，一跳转就恢复默认值。语言识别需要线索，而目标 URL 里压根没有这个线索。
- 如果手动拼接参数，很容易只补上
lang，却漏掉原有 query。例如/order?status=done被改写成/user/profile?lang=zh-cn，原来的status=done就丢了 - 如果使用
Url::build()生成地址，但没有显式传入['lang' => session('lang')]或input('lang')，生成结果里同样不会出现语言参数 - 前端如果直接写
location.href = '/admin'，本质上也是发起一个全新访问，请求上下文会被清空，语言状态不会自动保留
所以这里要抓住一点：不是 lang 被系统“删掉”了，而是你从一开始就没有把它传给下一次请求。
保持语言状态的两种可靠方式
要让跳转后的页面继续使用当前语言，核心只有一句话：让下一次请求依然能被 LoadLangPack 识别出语言。常见做法就是把语言状态放进它能读取的位置里，通常优先考虑 Cookie，其次才是显式透传 GET 参数。
方案一：使用 Cookie 持久化语言状态
这是更稳妥、也更适合站点级多语言切换的方式。只要配置正确，用户切换语言后写入 Cookie，后续 redirect() 即使不改 URL，新请求也能自动读到语言值。
需要确认 config/lang.php 中至少满足以下条件：
'use_cookie' => true
'cookie_var' => 'think_lang'切换语言时，先写入 Cookie，再执行跳转，例如：
cookie('think_lang', 'en-us')这样下一次请求进入语言中间件时，就可以直接从 think_lang 读取到 en-us，不必依赖 URL 中是否显式出现 lang。
这种方案的优点是地址更干净，也不用在每个跳转链接上手动带语言参数。对于用户中心、后台、订单页这类会频繁跳转的场景，Cookie 往往更省事。
方案二：透传 GET 参数
如果你的项目本身就希望把语言状态保留在 URL 中，例如便于分享链接、SEO 或前后端统一识别，那么可以在构造目标链接时主动把当前语言和原有参数一起带过去。
可直接使用下面这种写法：
Url::build('user/profile', array_merge(input(), ['lang' => input('lang', cookie('think_lang'))]))这段逻辑的重点不在“拼出一个 lang 参数”，而在于同时保留原请求的参数集合，再补上当前可用的语言值。这样既能避免遗漏业务参数，也能兼容当前语言可能来自 input('lang') 或 cookie('think_lang') 的情况。
相比之下，有一种做法看起来像解决方案，其实经常无效：在跳转前调用 Lang::setLocale()。这个方法只会影响当前请求内的语言环境，对 302 之后的下一次请求并不起作用，因此不能替代 Cookie 或参数透传。
中间件顺序和配置里最容易忽略的坑
即使你已经把语言写进 Cookie，或者已经在 URL 中附带了 lang，如果中间件执行顺序或配置项本身有问题，结果仍然可能是语言加载失败。更麻烦的是，这类问题通常不会直接报错，只会表现为静默回退到默认语言，或者页面直接显示语言 key。
先检查 LoadLangPack 的执行顺序
在 app/middleware.php 中，'thinkmiddlewareLoadLangPack' 的位置要特别注意。它需要放在 SessionInit 之后，否则语言中间件执行时，相关状态可能还没有准备好，导致读取 cookie('think_lang') 失败。
这类问题的典型特征是：你明明能在浏览器里看到 Cookie 已经写入，但页面翻译就是不生效。原因并不是 Cookie 没有保存，而是读取时机不对。
再确认 allow_lang_list 是否匹配实际值
config/lang.php 里的 'allow_lang_list' 不是可有可无的配置，它决定了系统接受哪些语言标识。如果你配置的是：
['zh-cn', 'en-us']但前端实际传的是 lang=zh，那么这次识别就不会命中，系统会直接 fallback 到默认语言。
这也是多语言项目里非常高频的隐性问题：前端、后端、配置文件三边都在写语言代码，但格式并不一致。只要有一端写成 zh、另一端要求 zh-cn，整条链路就会失效。
最后看 detect_var 和 cookie_var 是否一致且无冲突
还需要检查 'detect_var' => 'lang' 和 'cookie_var' => 'think_lang' 这些配置名是否与你的项目实际使用方式一致，同时确认没有被其它模块复用或覆盖。
例如某些权限中间件、自定义公共组件也可能使用了 think_lang 这样的名字。一旦命名冲突，语言中间件读到的值就未必是你预期的内容，最终表现出来仍然是语言异常回退。
很多排查卡住，往往不是因为逻辑复杂，而是因为几个小点同时出问题：中间件顺序不对、配置名写错、allow_lang_list 漏项，或者前端传值格式不一致。只要按这条链路逐项核对，通常都能很快定位到问题根源。
