create table #t 报“对象已存在”错误是因为同名本地临时表未显式清理就重复创建；object_id('#t') 恒为 null 是因未指定 tempdb.. 前缀，正确写法是 object_id('tempdb..#t')。
为什么 CREATE TABLE #t 会报“对象已存在”错误
因为 SQL Server 不允许在当前会话中重复创建同名本地临时表。哪怕上一次执行已结束，只要该存储过程被多次调用（比如循环、嵌套、重试），而你没在开头清理，#t 就可能还留在 tempdb 中——此时再执行 CREATE TABLE #t 必然触发错误 42S01。
OBJECT_ID('#t') 判断永远为 NULL 的原因
本地临时表物理上只存在于 tempdb，且 SQL Server 内部对其做了会话隔离和名称后缀处理。直接查 OBJECT_ID('#t') 相当于查当前数据库（如 master 或你的业务库）下的对象，自然找不到。
- ✅ 正确写法：
OBJECT_ID('tempdb..#t')—— 显式指定三段式名称 - ❌ 错误写法：
OBJECT_ID('#t')、OBJECT_ID('dbo.#t')、OBJECT_ID('tempdb.dbo.#t')（tempdb..是固定语法，不能加dbo） - ⚠️ 全局临时表同理：
OBJECT_ID('tempdb..##t')，不是##t
存储过程里重建临时表的标准流程
不能靠“自动销毁”赌运气，尤其在分支逻辑多、动态 SQL 多、或被循环调用的场景下。必须显式控制生命周期。
- 每次进入存储过程开头就检查并清理：
IF OBJECT_ID('tempdb..#result') IS NOT NULL DROP TABLE #result - 再建表：
CREATE TABLE #result (...)（不要用SELECT ... INTO #result替代，后者无法复用已有结构） - 避免用
ALTER TABLE增减列来“升级”结构——后续SELECT *或列别名引用容易错位 - 如果字段变了，必须删旧建新；否则即使
DROP了，SELECT * FROM #result仍按旧结构返回，列数/类型不匹配会静默出错
容易被忽略的边界情况
最隐蔽的问题往往不在代码本身，而在执行环境与批处理上下文。
- 在 SSMS 中手动测试时，如果改了
#t的列定义但没用GO分隔，SQL Server 会把前后语句当成一个批，导致CREATE TABLE和后续SELECT共享旧元数据，报Invalid column name - 动态 SQL 中创建的临时表（如
EXEC('SELECT ... INTO #tmp FROM ...')），其作用域仅限于该动态批，外部不可见——不能指望它在主存储过程中被后续语句引用 - 事务回滚不影响临时表存在状态：即使
ROLLBACK了，#t还在，下次进过程仍需DROP
