HTTP_ACCEPT_LANGUAGE未被读取的典型表现是页面始终显示默认语言，根本原因是侦测流程被GET或Cookie等前置环节截断，需检查detect_var、use_cookie及LoadLangPack中间件是否启用。
HTTP_ACCEPT_LANGUAGE 未被读取的典型表现
页面始终显示默认语言（比如 zh-cn），即使浏览器设置为英文、请求头里明确带了 Accept-Language: en-US,en;q=0.9，Lang::get('hello') 仍返回中文。这不是语言包没加载，而是系统压根没走到浏览器语言识别这步。
根本原因在于侦测流程被提前截断：系统按固定顺序检查 GET → Cookie → Header → HTTP_ACCEPT_LANGUAGE，只要前面任一环节命中，就不会继续往下走。常见干扰点有：
-
detect_var对应的 GET 参数（如?lang=zh-cn）残留或被缓存，哪怕只是历史访问留下的 URL -
use_cookie开启后，cookie_var对应的 Cookie（如think_lang）存在且值合法，哪怕用户已清空浏览器其他数据 - 中间件
think\middleware\LoadLangPack未启用，导致整个侦测逻辑不执行——此时连HTTP_ACCEPT_LANGUAGE都不会被解析
确认是否真走到了 HTTP_ACCEPT_LANGUAGE 逻辑
最直接的办法是临时加一行调试输出，在中间件或控制器里打印当前生效语言和原始头信息：
dump($_SERVER['HTTP_ACCEPT_LANGUAGE'] ?? 'missing'); dump(Lang::getLangSet());
如果 HTTP_ACCEPT_LANGUAGE 有值但 Lang::getLangSet() 始终是默认值，说明侦测链在前几步就退出了。重点查：
立即学习“PHP免费学习笔记（深入）”；
- 请求 URL 是否含
?lang=xxx（哪怕只是书签或历史记录） - 用浏览器开发者工具 → Application → Cookies，确认
think_lang（或你配置的cookie_var）是否存在且非空 - 检查
config/lang.php中allow_lang_list是否包含你期望的语言，比如en-us而不是en—— 不匹配会 fallback 到default_lang，不报错也不提示
强制触发浏览器语言识别的最小改动
不想改业务逻辑，又想确保每次新用户都走 HTTP_ACCEPT_LANGUAGE？把前两步“堵住”就行：
- 将
detect_var设为空字符串或非常规名（如'detect_var' => '_lang_ignore'），让 GET 参数失效 - 临时关闭 Cookie 记录：
'use_cookie' => false，避免旧 Cookie 干扰 - 确保
allow_lang_list明确列出目标语言，例如['zh-cn', 'en-us', 'ja-jp']，别漏掉大小写或分隔符
改完清空浏览器 Cookie 和缓存，用隐身窗口直连无参数 URL 测试。这时 Lang::getLangSet() 应该和 $_SERVER['HTTP_ACCEPT_LANGUAGE'] 解析出的首项一致。
Header 方式比 HTTP_ACCEPT_LANGUAGE 更可靠？
不是更可靠，而是更可控。从 TP6.0.3 开始支持通过 Header 传语言（如 think-lang: en-us），它优先级低于 GET 但高于 HTTP_ACCEPT_LANGUAGE。如果你的前端能发 Header（比如 SPA 项目用 axios 设置 headers: { 'think-lang': 'en-us' }），就比依赖浏览器自动头更稳定——因为后者可能被代理、CDN 或某些安全策略剥离。
但要注意：header_var 默认是 think-lang，不是标准 Accept-Language；且必须在中间件启用前提下才生效。如果只配了 header_var 却没开 LoadLangPack，Header 值会被完全忽略。
真正容易被忽略的是：所有侦测渠道（GET/Cookie/Header/HTTP_ACCEPT_LANGUAGE）最终都依赖 Lang::setLang() 的调用时机。如果在中间件之后才手动调用（比如控制器里），那前面的侦测结果已经作废——语言包文件可能已按默认语言加载完毕，后续 Lang::get() 只是切换了一个无效的状态。
