sys.sql_expression_dependencies是唯一可靠入口，因其准确记录跨库跨schema引用，需过滤referenced_class=1并用递归CTE展开嵌套链路，再结合sys.dm_exec_describe_first_result_set验证列有效性。
SQL Server 2016 及以上版本中，sys.sql_expression_dependencies 是最可靠、最直接的视图依赖关系查询入口，它能覆盖绝大多数非架构绑定（non-schema-bound）引用场景；但要注意它不记录运行时解析的单部分名称引用（如 SELECT * FROM Orders 而非 SELECT * FROM dbo.Orders），这类依赖无法被自动捕获。
查视图依赖了哪些表或函数
用 sys.sql_expression_dependencies 查“被引用对象”——即视图用了什么：
- 必须指定
referencing_id = OBJECT_ID('your_view_name')，否则结果混杂所有对象 -
referenced_schema_name和referenced_entity_name是关键过滤字段，避免因同名对象跨 schema 误判 - 若
referenced_database_name IS NOT NULL，说明存在跨库引用，需确认目标库是否在线且权限正确 - 示例语句：
SELECT referenced_schema_name, referenced_entity_name, referenced_class_desc FROM sys.sql_expression_dependencies WHERE referencing_id = OBJECT_ID('Sales.vCustomerSummary') AND referenced_class IN (1, 2, 6); -- 1=object, 2=column, 6=type
查哪些视图依赖某张表
反过来查“谁在用这张表”，重点是识别变更风险：
- 使用
sys.dm_sql_referencing_entities更安全，它只返回当前数据库内、有元数据定义的依赖者 - 调用时参数必须是两部分名称：例如
'dbo.Customers'，传单部分名（'Customers'）会报错或返回空 - 该函数不返回跨库视图（即使它们实际引用了本库表），因为跨库视图的依赖元数据不存于当前库
- 示例：
SELECT referencing_schema_name, referencing_entity_name, referencing_class_desc FROM sys.dm_sql_referencing_entities('dbo.Customers', 'OBJECT');
为什么 sp_depends 不推荐用了
sp_depends 在 SQL Server 2016+ 中已明确标记为“过时”，它的问题很实际：
- 不识别延迟名称解析（deferred name resolution）对象，比如视图里引用了尚不存在的表，它仍可能显示“无依赖”
- 对 WITH SCHEMABINDING 视图返回错误结果，因为它绕过了依赖跟踪机制
- 无法区分列级依赖（例如只用了
Customers.Name），而sys.sql_expression_dependencies支持referenced_minor_id > 0过滤 - 在兼容级别低于 120 的数据库中行为不稳定，而 2016 默认是 130，两者不兼容
跨库和动态 SQL 的依赖是盲区
真正容易出问题的地方不在语法，而在设计层面：
- 用
EXEC('SELECT * FROM OtherDB.dbo.Table')或OPENQUERY调用的依赖，sys.sql_expression_dependencies完全不记录 - 链接服务器（Linked Server）上的远程对象，只有显式写成四部分名（
server.db.schema.obj）才可能被部分识别，但依然不可靠 - 视图定义中含变量拼接（如
@table_name）、或用IF EXISTS动态分支的逻辑，依赖关系在编译期无法确定 - 这些情况只能靠人工标注、代码审查或部署前执行
SET FMTONLY ON+ 手动执行测试来验证
