sql server触发器无法直接生成防伪流水号，防伪需外部机制；仅支持after和instead of触发器，须用instead of实现插入前赋值；并发下“当日序号”需独立计数表+merge原子更新；防伪需哈希+盐值+上下文绑定，并配合加密存储、多层校验与权限管控。
SQL Server 触发器无法直接生成「防伪」流水号——它只能保证唯一性和顺序性，防伪必须靠外部机制（如哈希、数字签名、时间戳+随机盐值）参与计算，否则任何能查到规则的人都能伪造。
BEFORE INSERT 在 SQL Server 里根本不存在
很多人从 Oracle 或 PostgreSQL 迁移过来，下意识写 BEFORE INSERT，但 SQL Server 只支持 AFTER INSERT 和 INSTEAD OF INSERT。想在插入前赋值流水号，必须用 INSTEAD OF INSERT —— 它会拦截原始 INSERT 语句，让你完全控制插入逻辑。
-
INSTEAD OF INSERT触发器里可以自由拼接前缀、日期、序列号，并用INSERT INTO ... SELECT把加工后的数据写入原表 - 不能在
AFTER INSERT中更新原表，否则报错The target table 'xxx' of the DML statement cannot be on either side of a (primary key, foreign key) relationship - 如果主键是
IDENTITY，INSTEAD OF触发器里必须显式提供该字段值（或用SET IDENTITY_INSERT ON），否则插入失败
怎么安全生成“当日序号”而不重复？
直接 SELECT MAX(no) FROM xxx WHERE CAST(create_time AS DATE) = GETDATE() 并 +1，在并发场景下必然撞号。SQL Server 没有原子递增函数（不像 MySQL 的 ON DUPLICATE KEY UPDATE），得靠唯一约束 + 重试，或改用独立计数表。
- 推荐建一张
seq_daily表：CREATE TABLE seq_daily (date_key CHAR(8) PRIMARY KEY, next_seq INT NOT NULL DEFAULT 1) - 触发器中用
MERGE实现原子更新：MERGE seq_daily USING (SELECT 1) AS src ON date_key = FORMAT(GETDATE(), 'yyyyMMdd') WHEN MATCHED THEN UPDATE SET next_seq = next_seq + 1 WHEN NOT MATCHED THEN INSERT (date_key, next_seq) VALUES (FORMAT(GETDATE(), 'yyyyMMdd'), 1); - 再查出刚更新的
next_seq值用于拼流水号，避免SELECT ... FOR UPDATE（SQL Server 不支持该语法）
流水号里加防伪成分怎么做？
纯数字序号不防伪。要防伪，得引入不可预测、不可逆、绑定上下文的因子。SQL Server 内置函数有限，但可组合使用：
- 用
HASHBYTES('SHA2_256', CONCAT(@date_prefix, @seq, NEW.customer_id, 'secret_salt'))生成摘要，截取后 6 位转大写十六进制作为校验段，例如ORD20261015-0042-7F2A9C - 避免用
NEWID()直接拼进流水号——它无序且不可重现，不利于对账；但可用作盐值的一部分 - 别把密钥（
'secret_salt'）硬编码在触发器里，应存在加密配置表中，用OPEN SYMMETRIC KEY解密读取（需提前配置证书和密钥） - 注意
HASHBYTES返回VARBINARY，转字符串要用CONVERT(NVARCHAR, ..., 2)，末尾2表示不带0x前缀
为什么你看到的“防伪码”其实常被绕过？
真正难防的是内部人员或具备数据库权限者。只要触发器逻辑公开、盐值可查、哈希方式已知，攻击者就能离线批量生成合法流水号。生产环境必须做到：
- 触发器定义用
WITH ENCRYPTION加密（虽可被高权限用户绕过，但拦住大部分误操作和低权限查看） - 校验逻辑不能只在数据库层做，应用层提交时也应复核一次哈希，且比对结果不返回具体错误位置（防止差分攻击）
- 流水号生成与业务单据强绑定（如关联订单创建时间、操作人 SID、客户端 IP 的哈希片段），单一字段伪造无意义
防伪不是加个哈希就完事，是权限、审计、链路、存储多层设计的结果。触发器只是其中一环，而且是最容易暴露的一环。
