视图报错是因字段名被固化为字符串快照，表结构变更后不自动更新；必须用CREATE OR REPLACE VIEW或DROP+CREATE重建视图，且需检查类型、NULL性等兼容性。
修改物理表字段后视图直接报错，不是因为视图“坏了”，而是它在执行时按原定义硬解析字段名——表里没这个列，SQL引擎当场拒绝，不给任何缓冲机会。
视图定义固化了字段名和表名
视图创建时保存的是完整的 SELECT 文本，包括 SELECT user_name, created_at FROM users 这样的字面量。PostgreSQL 存进 pg_class 和 pg_attribute，SQL Server 存进 sys.sql_modules.definition，MySQL 存进 INFORMATION_SCHEMA.VIEWS.VIEW_DEFINITION。这些字段名不是“引用”，是字符串快照。
一旦你执行 ALTER TABLE users RENAME COLUMN user_name TO full_name，视图里那行 user_name 就彻底失联。查询时数据库不会尝试模糊匹配或别名回溯，直接抛 ERROR: column "user_name" does not exist（PostgreSQL）或 Invalid column name 'user_name'（SQL Server）。
- 用
pg_get_viewdef('vw_user')（PG）或SELECT definition FROM sys.sql_modules WHERE object_id = OBJECT_ID('dbo.vw_user')（SQL Server）能立刻看到它还在写user_name -
SELECT * FROM pg_depend WHERE refobjid = 'users'::regclass AND deptype = 'n'可查出哪些视图依赖这张表，但不会告诉你具体用了哪几列——得靠人工比对 - 视图里如果用了
SELECT *，改列名反而不报错，但会悄悄返回NULL或跳过该列，数据错位更难察觉
ALTER VIEW 不能重映射字段名
你不能用 ALTER VIEW vw_user RENAME COLUMN user_name TO full_name —— 这个语法根本不存在。所有主流数据库都不支持“局部更新”视图字段绑定。
唯一合法路径只有两条：
-
CREATE OR REPLACE VIEW vw_user AS SELECT full_name AS user_name, created_at FROM users：显式加别名维持契约，适合上层应用按别名取值的场景 -
DROP VIEW vw_user; CREATE VIEW vw_user AS SELECT full_name, created_at FROM users：彻底重建，避免残留元数据干扰，尤其当该视图被其他视图或物化视图依赖时
注意：CREATE OR REPLACE VIEW 在 PostgreSQL 中允许改返回列数，MySQL 8.0+ 才支持；旧版 MySQL 必须走 DROP+CREATE，且需确认调用者有 DROP 权限。
类型变更也会让视图“运行时报错”
字段名没动，但类型变了，照样崩。比如把 price INT 改成 price DECIMAL(10,2)，视图里写了 WHERE price * 100 > 5000，SQL Server 可能因隐式转换失败报 Arithmetic overflow error；MySQL 在严格模式下直接拒绝计算。
更隐蔽的是 NULL 性变更：ALTER TABLE users ALTER COLUMN full_name SET NOT NULL 后，视图里若做了 COALESCE(full_name, 'N/A')，逻辑看似安全，但下游应用若依赖该字段“永远非空”的契约，就可能漏掉空值校验。
- 类型兼容性不能只看名字，要核对
system_type_id（SQL Server）、typname（PG）或COLUMN_TYPE（MySQL） - 用
sys.dm_exec_describe_first_result_set(N'SELECT * FROM vw_user', NULL, 0)（SQL Server）可提前暴露类型不匹配 - 字段加了
GENERATED ALWAYS AS或默认表达式，视图里又做了同名计算，容易引发歧义
真正容易被忽略的是：视图常被当成“只读接口”，但它的字段名、类型、甚至列顺序，都是强契约。改底层表前，必须把所有直接/间接引用它的视图、物化视图、SQL 函数、甚至 ORM 的实体映射都拉出来过一遍——漏一个，上线就炸。
