SQL Server等主流数据库禁止在CREATE VIEW中引用临时表，因视图需持久化存储且跨会话复用，而临时表生命周期与会话绑定，二者根本冲突。
SQL Server（以及 MySQL、PostgreSQL 等主流系统）明确禁止在 CREATE VIEW 语句中引用本地临时表（#temp）或全局临时表（##temp），这不是兼容性问题，而是设计层面的硬性限制——视图定义必须可持久化、可跨会话复用，而临时表生命周期与会话/批处理强绑定，二者根本冲突。
CREATE VIEW 中写 SELECT * FROM #t 直接报错
错误信息类似：Invalid object name '#t' 或 Cannot use a temporary table in a view definition。这不是语法写错，也不是权限不足，是 SQL Server 在解析 CREATE VIEW 时就拒绝编译：视图元数据要存进系统表，而 #t 在当前会话结束后即销毁，无法保证后续任何用户执行该视图时 #t 还存在。
- 即使你在同一连接里先
CREATE TABLE #t，再CREATE VIEW v AS SELECT * FROM #t，依然失败 -
##temp同样不被允许——它虽能跨会话可见，但生命周期不可控，且命名易冲突，不符合视图“确定性”的要求 - 试图用动态 SQL 绕过（比如
EXEC('CREATE VIEW...')）也不行，CREATE VIEW不支持在 EXEC 内执行
为什么不能靠“延迟绑定”绕过去
SQL Server 对永久表和 ##temp 支持延迟名称解析（deferred name resolution），即创建视图时不检查对象是否存在，只在首次执行时校验。但这个机制**不适用于 #temp**，因为它的作用域连“首次执行”都撑不到——视图创建那一刻，#temp 很可能已经超出作用域（比如上一个批处理已结束）。
- 延迟绑定只解决“表存在但还没建”的问题，不解决“表存在但不可见”的问题
-
SELECT * FROM #t在视图里不是运行时逻辑，而是元数据定义的一部分，必须静态可验证 - 哪怕你把
#t改成@t表变量，同样非法：DECLARE和CREATE VIEW是互斥语法结构
真正可用的替代方案：表变量不行，得换思路
表变量（@t）本身也不能用于视图——它连 CREATE VIEW 的语法上下文都不准入。可行路径只有两条：用永久中间表，或改用物化视图（如果数据库支持）。
- 建一张带命名规范的永久表，如
dbo.vw_orders_summary_cache，用作业或触发器定期刷新，视图查它 - SQL Server 可建索引视图（
CREATE VIEW ... WITH SCHEMABINDING+ 唯一聚集索引），它物理存储结果，不依赖临时对象，但要求基表稳定、函数确定、列名明确 - MySQL / PostgreSQL 15+ 可用物化视图（
CREATE MATERIALIZED VIEW），效果类似，但需注意刷新策略 - 若只是想简化复杂查询逻辑，优先用 CTE 替代：视图里写
WITH cte AS (...) SELECT ... FROM cte完全合法，且无生命周期问题
最容易被忽略的一点：很多人以为“我把临时表改成全局临时表就能塞进视图”，结果不仅失败，还可能在 tempdb 留下残留对象影响后续调试。真正关键的不是“怎么让临时表进视图”，而是“视图本就不该承担临时数据暂存职责”——它的定位是抽象、复用、稳定的数据接口，中间状态该由存储过程、应用层或物化机制来管。
