SQL嵌套查询中无法用系统变量（如@lang）动态指定列名，因T-SQL编译期强制静态解析列标识符，子查询同样受此限制，必须显式写出列名或用CASE表达式计算值。
SQL嵌套查询里不能用系统变量（比如@lang）直接当列名去选多语言字段——子查询和外层查询一样，都受 T-SQL 编译期列名静态解析限制。你写SELECT @lang_col FROM ...，哪怕放在子查询里，照样报 Invalid column name '@lang_col' 或 Must declare the scalar variable "@lang_col"。
为什么嵌套查询也过不了编译关
嵌套查询不是“运行时才展开”的黑盒，SQL Server 会在执行前完整解析整个语句结构，包括所有子查询的 SELECT 列表。只要列名是变量，就无法通过语法检查。这不是子查询层级的问题，而是整个 T-SQL 的语言规则：列标识符必须可静态推导。
- 即使把
@lang_col声明在外部存储过程里，子查询内部仍看不到它作为列名的语义 -
SELECT (SELECT name_zh FROM t WHERE id = p.id) AS name这种写法是合法的，但它是硬编码列名，不是动态选列 - 试图用
CASE WHEN @lang = 'zh' THEN name_zh ELSE name_en END能跑通，但属于表达式计算，不是“切换列”，且无法走索引
想在子查询里“模拟”语言列切换，只能靠 CASE + 固定列名
如果你必须保持单条查询结构（比如 ORM 不允许拼 SQL 字符串），唯一可行路径是用CASE显式列出所有支持的语言列，并由变量控制返回哪一列的值。这本质是行内计算，不是列名切换。
SELECT
id,
(SELECT CASE @lang
WHEN 'zh' THEN t_zh.name
WHEN 'en' THEN t_en.name
ELSE t_zh.name
END
FROM products_trl t_zh
LEFT JOIN products_trl t_en ON t_zh.product_id = t_en.product_id AND t_en.lang = 'en'
WHERE t_zh.product_id = p.id AND t_zh.lang = 'zh') AS name
FROM products p;
- 注意：子查询里仍要显式 JOIN 所有需参与语言 fallback 的翻译行，不能只靠一个
@lang变量驱动 - 这种写法会让翻译表上的
(product_id, lang)联合索引失效——因为WHERE t_zh.lang = 'zh'是固定的，但t_en.lang = 'en'是写死的，没法根据@lang自动适配索引条件 - 性能随语言种类线性下降，查 5 种语言就要 JOIN 5 次
真正要兼顾灵活性和性能，得放弃“子查询里切语言”的执念
嵌套查询不是为动态列设计的场景。更务实的做法是把语言逻辑提到外层：要么用动态 SQL（在存储过程中拼SELECT ... QUOTENAME(@col_name)），要么用视图预展多语言字段（如name_zh, name_en），再由应用决定 SELECT 哪一列。
- 视图方案：用
LEFT JOIN products_trl t_zh ON ... AND t_zh.lang = 'zh'方式并排拉出各语言字段，子查询或主查询直接引用t_zh.name等——列名固定，索引可用 - 动态 SQL 方案：子查询本身不参与语言选择，语言列名由外层拼好再 EXEC，避免在嵌套结构里硬塞变量
- 别指望
SELECT (EXEC sp_executesql @sql)——T-SQL 不支持把动态执行结果当标量子查询用
最易被忽略的一点：很多人以为“子查询更灵活”，其实恰恰相反——它把列名绑定得更死。语言切换这件事，越靠近查询顶层，越容易控制；越往里嵌，越容易撞上编译器的铁墙。
