最准起点是查sys.sql_expression_dependencies，它不依赖字符串解析，能识别别名、三段式引用及跨库对象；字段级依赖需用sys.dm_sql_referenced_entities；有效性验证靠sys.dm_exec_describe_first_result_set。
直接查 sys.sql_expression_dependencies，这是最准、最稳的起点。 它不靠字符串解析，能识别别名、三段式引用、甚至跨库对象（只要写全了 database.schema.table）。
查视图依赖的表：用 sys.sql_expression_dependencies 过滤 referencing_id
核心逻辑是：把视图名转成 ID，再查它“引用了谁”。注意不是查“谁引用了它”。
- 必须用
OBJECT_ID('schema.viewname')，不能只传'viewname'，否则可能返回空或错的 ID - 关注
referenced_entity_name和referenced_schema_name字段，它们给出表名和 Schema 名 - 如果
referenced_database_name不为空，说明是跨库引用，得人工确认那个库是否存在、是否可访问 -
is_ambiguous = 1是危险信号——同名列可能被解析到临时表或多个永久表，上下文不明确，必须人工核对 - 如果视图定义改过但没执行
sp_refreshsqlmodule，这里的数据会滞后，不是实时状态
查字段级依赖：必须调 sys.dm_sql_referenced_entities
sys.sql_expression_dependencies 只告诉你用了哪张表，不告诉你用了哪些列。要定位字段，得对每个依赖表单独调这个函数。
- 参数必须是三段式名称：
'schema.tablename'，不能少 schema，也不能加数据库名 - 第二个参数固定为字符串字面量
'OBJECT'，不能传变量，否则报错 - 结果里
is_selected = 1表示该列出现在SELECT列表中；is_updated = 1表示被UPDATE涉及 - 如果某列在结果里缺失，或者
referenced_minor_id = 0，说明该列可能已不存在、名字不匹配，或被加密对象包裹（比如依赖的函数用了WITH ENCRYPTION）
验证依赖是否还有效：用 sys.dm_exec_describe_first_result_set
查完只是“知道用了什么”，还得确认这些对象现在还能不能正常解析。这个函数模拟执行前的元数据推导，不真正跑 SQL。
- 传入的查询字符串必须可解析，比如
N'SELECT * FROM [db].[schema].[table]'；跨库时库名不能省 - 第三个参数设为
0表示只解析、不执行，避免副作用 - 重点看返回里的
error_message字段，有值就说明列名失效、类型冲突或权限不足 - 如果视图里有
SELECT *或嵌套 CTE，这一步比单纯查系统视图更可靠
容易被忽略的是：视图本身没加密，但它的某个依赖对象（比如一个标量函数）可能被 WITH ENCRYPTION 包裹。这时 sys.dm_sql_referenced_entities 仍能返回表级依赖，但字段级信息会断——你得手动进那个函数体里扒定义。
