存储过程中不能直接用ALTER TABLE增删临时表列，必须用EXEC()执行动态SQL；因编译期无法识别运行时创建的临时表结构，静态DDL会报错。
不能在存储过程中直接用 ALTER TABLE 删除或添加列（除非用动态 SQL），且临时表列的增删必须在同一批次内完成，否则会报“对象名无效”。
存储过程里执行 ALTER TABLE 为什么会失败
SQL Server 存储过程在编译阶段就解析所有对象引用。如果 ALTER TABLE #t ADD COLUMN x INT 是在过程里写的静态语句，SQL Server 编译时 #t 还不存在，或者新增的列 x 尚未被识别，后续语句如 SELECT x FROM #t 就会直接报错“列名无效”。这不是运行时错误，是编译期拒绝执行。
- 临时表（
#t）只在当前会话生命周期存在，存储过程无法提前感知其结构变化 - SQL Server 不支持在非动态上下文中对运行时才创建的对象做 DDL 引用
- 即使把
ALTER和SELECT写在一起，也不代表它们在同一个编译单元里被识别
必须用 EXEC() 包裹 ALTER TABLE
只有把 DDL 语句构造成字符串、再用 EXEC 或 sp_executesql 执行，才能绕过编译检查——因为此时 SQL Server 把它当纯文本执行，不参与前期绑定。
- 正确写法：
EXEC('ALTER TABLE #t ADD col1 VARCHAR(10)') - 错误写法：
ALTER TABLE #t ADD col1 VARCHAR(10)（放在存储过程体里直接写） - 注意：动态 SQL 中新建的列，只能在该
EXEC块内部使用；外部仍不可见 - 如果需要后续操作该列，得把整个逻辑（ADD + INSERT + SELECT）都塞进同一个
EXEC字符串里
临时表列删除要小心作用域和 GO 分隔
在普通脚本中，ALTER TABLE #t DROP COLUMN x 后面加 GO 是为了重置批处理上下文，让 SQL Server 重新识别 #t 的新结构。但在存储过程里，GO 是客户端命令，服务器根本不认识，直接报错。
- 存储过程中删列也必须用
EXEC('ALTER TABLE #t DROP COLUMN x') - 删完之后若想查新结构，得再套一层
EXEC('SELECT * FROM #t') - 别指望在同一个存储过程里“先加列、再删列、最后查”，中间没
GO就意味着结构变更不会被后续静态语句感知 - 更稳妥的做法：把整套临时表操作封装进一个动态 SQL 字符串里统一执行
为什么连 IF NOT EXISTS 都不能直接用
SQL Server 直到 2016 才支持 IF NOT EXISTS 用于 ADD COLUMN，而且仅限于某些版本和兼容级别。更重要的是：这个语法本身仍是静态 DDL，在存储过程中照样过不了编译关。
- 想判断列是否存在，得先查系统视图：
SELECT 1 FROM tempdb.sys.columns WHERE object_id = OBJECT_ID('tempdb..#t') AND name = 'x' - 结果要配合
IF+EXEC组合使用，不能写成单条带条件的ALTER - 即便用了
IF NOT EXISTS，也不能避免锁表、阻塞或大表变更失败的风险——它只是语法糖，不是安全机制
真正麻烦的地方在于：临时表结构动态变化后，后续所有依赖它的语句都得同步适配，而这种适配又只能靠拼字符串完成。一旦嵌套层级变深、字段名来自参数、或需要兼容不同 SQL Server 版本，出错概率会指数上升。能不动结构，就别动。
