视图列映射冲突是语义断裂而非语法错误，因外部代码依赖的列名、类型或顺序被修改导致取错值、报错或返回null；重构时须新旧视图并存、渐进切换，并在视图定义中显式重命名join冲突列。
视图列映射冲突不是语法错误，而是查询层的语义断裂：当外部代码依赖的列名、类型或顺序在视图定义中被修改时，调用方会悄无声息地取错值、报错或返回 NULL。
为什么 SELECT * FROM v_user 会突然崩掉
视图本身不存储数据，只保存 SELECT 语句。一旦你重构 v_user，比如删掉 phone 列、把 status 改成 user_status，所有没显式写字段名的调用（尤其是 SELECT * 或 ORM 的 auto-mapping）立刻失效。
- PostgreSQL/SQL Server 直接报错：
column "phone" does not exist - MySQL 可能静默跳过缺失列，导致应用拿到少一列的数据，且无提示
- MyBatis、Django ORM 等按列名绑定结果集，列名对不上就设默认值或抛
MappingException - BI 工具拖拽字段后缓存了旧列结构，刷新数据时图表空白但日志里没报错
重构视图时如何不中断线上服务
核心原则：新旧视图并存 + 渐进切换，而不是 DROP + CREATE。
- 先建新视图，命名带版本号，如
v_user_v2，定义里确保所有旧列都存在（哪怕用NULL::text AS phone填充占位） - 对外暴露的“主视图”用
CREATE OR REPLACE VIEW v_user AS SELECT * FROM v_user_v2—— 这步只是改指针，零停机 - 禁止在
v_user_v2中删除旧列或改类型；若必须删，先用CASE WHEN FALSE THEN phone END AS phone保持兼容，等下游全部切到新字段后再清理 - 用
pg_views（PostgreSQL）或sys.views（SQL Server）查依赖：谁在查v_user？哪些应用连的是这个视图？别只信文档
列名重复时怎么让 JOIN 查询不翻车
视图内部用了 JOIN，结果集出现两个 id，外部查询再 SELECT * 就必然歧义 —— 这不是视图的问题，是调用方式错了。
- 视图定义里必须重命名冲突列：
SELECT u.id AS user_id, o.id AS order_id FROM users u JOIN orders o ... - 如果视图已上线且列名混乱，临时补救：用子查询包装，如
(SELECT user_id, order_id FROM v_orders_with_users) AS t，再在外层 SELECT 显式取字段 - 绝对不要在视图里留
SELECT *—— 它会让列集合变成黑盒，下次加表就崩 - 检查 ORM 映射文件是否硬编码了列名；如果是 MyBatis 的
<resultmap></resultmap>，确认<id column="id"></id>指向的是哪个表的id
最危险的不是改列名，而是以为“只是换个写法”，结果忘了下游有 Shell 脚本用 cut -f3 按字段位置取值，或者 BI 报表里写了 [Column3] 这种位置引用 —— 这类隐式依赖根本不会出现在 SQL 日志里，只能靠全链路扫描和灰度验证。
