只要中间件注册、配置开启或代码手动调用任一成立，就可能受影响；需检查LoadLangPack中间件是否启用、lang.switch是否为true、是否存在Lang::setLangSet等手动设置行为，并验证lang参数是否可被恶意利用。
直接看三点：中间件是否注册、配置是否开启、代码是否手动调用——只要其中任一条件成立，就可能受影响。
检查 LoadLangPack 中间件是否启用
打开 app/middleware.php，查找以下行：
\think\middleware\LoadLangPack::class- 或类似注册语句（如带注释但未删除、被第三方插件自动注入）
若存在且未被注释，说明多语言加载逻辑已接入请求流程，lang 参数会被框架主动解析。
确认 lang.switch 配置是否为 true
查看 config/lang.php 文件中的关键配置：
立即学习“PHP免费学习笔记（深入）”；
- 搜索
'switch' => true—— 若为true，表示语言切换功能逻辑已启用 - 即使中间件未注册，某些自定义路由或插件可能绕过中间件直读该配置并触发加载
注意：'switch' => false 是关闭风险的最有效方式之一，但需配合中间件移除才真正生效。
排查项目中是否存在手动语言设置行为
全项目搜索以下关键词（大小写不敏感）：
Lang::setLangSet($app->lang->setLangSet(-
input('lang')或$request->param('lang')后拼接.php或用于include/file_get_contents
这类自定义逻辑不受框架版本升级保护，6.0.14 也无法拦截，是常见“修复后仍被攻破”的主因。
验证是否实际暴露 lang 入口
在浏览器或 curl 中尝试访问含 lang 参数的 URL，例如：
-
/index.php?lang=zh-cn（正常响应） -
/index.php?lang=../../etc/passwd（返回 500、空白页或报错信息）
若后者未直接拒收（如返回 400 或 404），而是尝试读取或报路径错误，说明校验缺失，已处于风险中。
