应查sys.sql_expression_dependencies而非视图定义文本，因其记录编译时真实依赖；执行select referenced_entity_name,... where referencing_id = object_id('dbo.vw_user')可获取硬依赖，再用sys.objects验证存在性。
直接查 sys.sql_expression_dependencies，它记录的是视图实际展开时引用的对象名，不是你“以为”它引用的。
为什么不能靠看视图定义文本去猜？
视图定义里可能有注释、大小写混用、别名嵌套、甚至跨库三段式引用（otherdb.dbo.table），人工扫容易漏。更关键的是：SQL Server 不在创建时解析依赖，只存原始 SQL 字符串——哪怕你写了 SELECT * FROM nonexist_table，CREATE VIEW 也能成功。
所以必须绕过定义文本，查系统视图里被真实记录下来的依赖关系。
执行这句就能拿到所有硬依赖
把 'dbo.vw_user' 换成你要查的视图全名（带 schema）：
SELECT referenced_entity_name, referenced_schema_name, referenced_class_desc
FROM sys.sql_expression_dependencies
WHERE referencing_id = OBJECT_ID('dbo.vw_user');
结果里每一条都是视图在编译时真正会去找的对象。重点关注：
-
referenced_class_desc = 'OBJECT_OR_COLUMN'→ 查sys.tables或sys.views确认该表/视图是否存在（注意大小写和下划线） -
referenced_class_desc = 'FUNCTION'→ 查sys.objects看函数是否存在，且type IN ('FN', 'IF', 'TF') -
referenced_schema_name为空 → 视图里没写 schema 前缀，SQL Server 按调用上下文解析，极易出错
查到疑似问题对象后，快速验证是否存在
对上一步返回的每个 referenced_entity_name，跑这句确认：
SELECT name, schema_id, type_desc
FROM sys.objects
WHERE name = 'xxx' AND schema_id = SCHEMA_ID('yyy');
如果没结果，就坐实了缺失。常见情况包括：
- 基表被重命名（
users→app_users） - 表被移到其他 schema（
dbo.log→core.log） - 函数被删或改了签名（参数个数/类型变了）
- 用了
SELECT *，但基表删了一列，视图元数据缓存还没刷新
别跳过 SELECT * FROM view_name LIMIT 0 这步
这是最轻量的编译触发方式。它不走执行计划，只做元数据绑定，报错信息比全量查询更干净，比如：
Msg 208, Level 16, State 1, Line 1<br>Invalid object name 'users'.
这个错误里的 'users' 就是 sys.sql_expression_dependencies 里应该出现、但查不到的对象名——它帮你把问题范围从“一堆依赖”缩小到“一个名字”。
真正麻烦的不是找不到错在哪，而是依赖链里某张表本身又是个视图，而那个视图也失效了。一层层往下查 referencing_id 和 referenced_id 的关系，比盲试快得多。
