SQL视图列名别名是API正确解析响应数据的前提，决定JSON字段名输出，须与契约命名规范（如驼峰、大小写）严格对齐，否则导致映射失败、反序列化报错或空值注入。
SQL视图的列名别名不是可有可无的装饰，而是API接口能正确解析响应数据的前提。 如果视图返回的列名是原始表字段（如 user_id、created_at），而下游API契约约定的是 id、createdAt，那么不加别名就会导致字段映射失败、反序列化报错或空值注入——这类问题在线上环境往往表现为“数据存在但前端收不到”。
视图列别名决定JSON字段名输出
多数ORM或数据库驱动（如PostgreSQL的 pg、MySQL的 mysql2）在将查询结果转为JSON时，直接使用结果集的列名作为键名。视图本身不改写列名，除非显式用 AS 声明别名。
- 没别名：
SELECT id, created_at FROM users→ JSON中是{"id": 1, "created_at": "2026-06-09T13:00:00Z"} - 有别名：
SELECT id AS userId, created_at AS createdAt FROM users→ JSON中是{"userId": 1, "createdAt": "2026-06-09T13:00:00Z"}
前端框架（如React + Axios）或强类型后端（如Go的 json.Unmarshal）依赖字段名严格匹配结构体标签或TypeScript接口。一旦不一致，就跳过该字段或报错。
WHERE子句不能引用列别名，但API契约要求字段名稳定
这是最容易踩坑的地方：你在视图里写了 SUM(amount) AS total，想在外部查询中用 WHERE total > 100 ——这会报错，因为 WHERE 执行早于 SELECT 别名生成。但API对接时，前端传参常按视图输出的字段名来过滤（比如请求 /orders?total=500），后端必须把 total 映射回原始表达式。
- 错误做法：在视图里只定义别名，却不对外暴露原始计算逻辑
- 正确做法：视图中保留别名的同时，确保API层能将别名参数（如
total）安全转译为底层表达式（如SUM(orders.amount)），或提前在视图中固化可过滤字段（如增加total_amount列并建索引）
多源表字段冲突必须靠别名解耦
当视图 JOIN 多个表且存在同名列（如 users.id 和 orders.id），不加表别名 + 列别名，视图根本无法创建（PostgreSQL报错 column reference "id" is ambiguous；MySQL可能静默取第一个）。而API需要明确区分 userId 和 orderId。
- 必须写成：
SELECT u.id AS userId, o.id AS orderId, u.name AS userName FROM users u JOIN orders o ON u.id = o.user_id - 如果漏掉任一
AS，视图要么创建失败，要么返回歧义列名，API消费方拿到的JSON键就不可预测
真正关键的不是“能不能起别名”，而是别名是否与API契约的字段命名规范完全对齐——包括大小写（createdAt ≠ created_at）、下划线/驼峰风格、是否带业务前缀。这些细节一旦写进视图，就固化为下游系统的接口契约，改起来要全链路协同。所以别名不是写完就扔的临时工，它是数据库层面向外暴露的最小语义单元。
