最可靠方式是OUTPUT子句，它在INSERT执行时原子性返回INSERTED.id，避免并发冲突和触发器干扰，支持多行插入精确匹配，而@@IDENTITY和SCOPE_IDENTITY()存在竞态风险且不支持批量场景。
用 OUTPUT 子句直接获取刚插入的自增ID
SQL Server 最可靠、最常用的方式是 OUTPUT，它在 INSERT 执行的同时返回指定列（包括 IDENTITY 列），不依赖额外查询，也避免并发冲突。它比 SCOPE_IDENTITY() 更安全，因为不需要分两步执行。
常见错误是只写 SELECT SCOPE_IDENTITY() 跟在 INSERT 后面——这看似简单，但若中间有触发器、其他语句或事务隔离问题，可能拿到错误 ID。
-
OUTPUT必须紧跟在INSERT语句后，不能换行加GO或分号隔开（除非你明确知道分号不影响） - 只能引用目标表的列，比如
OUTPUT INSERTED.id，不能写OUTPUT INSERTED.*（除非所有列都允许返回，且不含计算列/大对象） - 如果插入多行，
OUTPUT会返回多行结果，不是单个值 - 示例：
INSERT INTO users (name, email) OUTPUT INSERTED.id VALUES ('Alice', 'a@example.com');
为什么不用 @@IDENTITY 或 SCOPE_IDENTITY() 单独查
这两个函数确实能返回最后生成的 ID，但它们属于“事后补救”，天然有竞态风险：一旦 INSERT 和 SELECT SCOPE_IDENTITY() 之间被其他语句（比如触发器里的插入）干扰，结果就不可靠。
-
@@IDENTITY会跨作用域，哪怕触发器里插入了另一张带自增的表，它也会返回那个 ID —— 这是最常踩的坑 -
SCOPE_IDENTITY()虽然限制在当前作用域，但依然依赖“紧挨着执行”，无法保证原子性 - 它们都不能用于插入多行时精确匹配每条记录的 ID（比如批量导入后要记录日志）
- 如果你必须用函数方式（例如 ORM 不支持
OUTPUT），优先选SCOPE_IDENTITY()，但务必确保它和INSERT在同一个批处理中，且中间无其他影响IDENTITY的语句
在存储过程中用 OUTPUT 插入并返回结果集
当需要插入数据并把新 ID 返回给调用方（比如 C# 的 ExecuteReader），OUTPUT 是唯一推荐方式。它天然支持结果集返回，无需临时表或变量中转。
- 不能把
OUTPUT结果直接赋给变量（如@new_id = INSERTED.id），除非只插一行且用INSERT ... OUTPUT INTO @table_var - 更稳妥的做法是用表变量接收多行结果：
DECLARE @ids TABLE (id INT);<br>INSERT INTO orders (customer_id, total) OUTPUT INSERTED.id INTO @ids VALUES (123, 99.99);<br>SELECT * FROM @ids;
- 注意：如果目标表有
INSTEAD OF触发器，OUTPUT INSERTED仍可用，但行为取决于触发器是否真正执行了插入
EF Core 或 Dapper 中怎么对应
这些 ORM 默认对 SQL Server 的 IDENTITY 列启用了 OUTPUT 支持，但前提是模型中标记了 [DatabaseGenerated(DatabaseGeneratedOption.Identity)]，且数据库字段确实是 IDENTITY。
- Dapper 使用
QuerySingle<int>("INSERT ... OUTPUT INSERTED.id VALUES (@name)", new { name = "Bob" })是安全的 - EF Core 6+ 对
SaveChanges()自动使用OUTPUT（只要没禁用），但若手动写原始 SQL，必须自己加OUTPUT，否则拿不到 ID - 一个容易被忽略的点：如果表主键不是
IDENTITY（比如用序列SEQUENCE或 UUID），OUTPUT INSERTED.id依然有效，但SCOPE_IDENTITY()就完全失效了
