视图聚合多语言字段需通过会话变量（如PostgreSQL的pg_current_setting）动态选择字段，避免硬编码；MySQL不支持视图中引用变量，宜改用参数化查询或拆表方案，并严格管理语言上下文生命周期。
用视图聚合多语言字段，避免业务层硬编码
直接在 SQL 层做多语言字段切换，核心是把「语言标识」作为查询上下文参与字段选择，而不是靠应用层 if-else 拼字段名。视图本身不存储数据，只定义逻辑，所以它天然适合封装这种动态映射逻辑，且对上游透明。
常见错误是试图在视图里写 CASE WHEN lang = 'zh' THEN name_zh ELSE name_en END，但 lang 并非表中字段，也没有运行时语言上下文——视图无法感知当前请求语言，必须由调用方显式传入参数（PostgreSQL 支持 pg_current_setting()，MySQL 则需靠会话变量或应用层注入）。
- PostgreSQL 推荐用
pg_current_setting('app.lang', true)读取会话级变量，配合SET app.lang = 'zh';预置 - MySQL 必须依赖用户变量（如
@lang := 'zh'），且需确保每次查询前已设置，不能依赖连接池自动复用值 - 视图中禁止调用函数返回不确定结果（如
NOW()、RANDOM()），否则可能被物化或缓存异常
PostgreSQL 中基于 current_setting 的多语言视图写法
PostgreSQL 是少数原生支持会话变量绑定到 SQL 表达式的数据库，pg_current_setting() 可安全用于视图定义，只要确保调用前已执行 SET。
假设原始表为 products，含字段 name_en、name_zh、name_ja：
CREATE OR REPLACE VIEW products_i18n AS
SELECT
id,
CASE pg_current_setting('app.lang', true)
WHEN 'zh' THEN name_zh
WHEN 'ja' THEN name_ja
ELSE name_en -- 默认 fallback
END AS name,
description_en,
CASE pg_current_setting('app.lang', true)
WHEN 'zh' THEN description_zh
WHEN 'ja' THEN description_ja
ELSE description_en
END AS description
FROM products;
注意：pg_current_setting(..., true) 第二个参数设为 true 表示“未设置时不报错”，返回 NULL，避免视图创建失败；应用层必须保证每次查询前执行 SET app.lang = 'zh';。
MySQL 视图无法直接读会话变量，得换思路
MySQL 视图不支持引用用户变量（@lang），任何含 @ 的视图定义都会报错 ERROR 1351 (HY000): View's SELECT contains a variable or parameter。硬要走视图路线，只能把语言参数转为显式字段传入——也就是改用「参数化视图等价物」：带参数的存储过程或内联表值函数（MySQL 8.0.24+ 支持 WITH + 子查询模拟，但非真正参数化）。
- 更实际的做法是放弃视图，改用带
language_code参数的SELECT查询，由 ORM 或 DAO 封装成方法 - 若坚持用视图，可建多个固定语言视图（
products_zh、products_en），再由应用层路由，但丧失灵活性 - MySQL 8.0.30+ 支持
JSON_CONTAINS和动态列提取，但对多语言字段属于过度设计，性能差且难维护
字段命名与扩展性陷阱：别用 _en/_zh 后缀硬编码
用后缀区分语言看似直观，但一旦新增语言（如 name_ko、name_es），所有视图、索引、ORM 映射都要批量修改，极易漏掉。更可持续的方式是拆表：
CREATE TABLE product_i18n ( product_id BIGINT NOT NULL, lang_code CHAR(2) NOT NULL, name TEXT, description TEXT, PRIMARY KEY (product_id, lang_code), FOREIGN KEY (product_id) REFERENCES products(id) );
然后用 LEFT JOIN + CASE 构建视图，或直接在应用层 JOIN 当前语言行。这种方式增删语言零改动，还能单独为 lang_code 建索引加速查询，比宽表方案更易治理。
真正的难点不在语法，而在于「谁负责设置语言上下文」和「如何保证视图查询不跨事务污染」——比如一个连接被连接池复用，上个请求设了 SET app.lang = 'ja'，下个请求没重设，就会返回错语言数据。这点常被忽略。
