必须使用AFTER触发器配合THROW中断操作，工作日判断用DATEPART(WEEKDAY,GETDATE()) NOT IN (1,7)，小时判断用DATEPART(HOUR,GETDATE())>=9 AND DATEPART(HOUR,GETDATE())<18，且需基于服务器本地时区或显式转换UTC时间。
直接结论：SQL Server 中必须用 BEFORE 类型的 AFTER 触发器（即 AFTER INSERT, UPDATE, DELETE）配合 THROW 或 RAISERROR 中断操作，且时间判断必须基于服务器本地时区、排除周六日+严格限定小时范围（9:00–17:59），否则会在 18:00 整或周五下午被绕过。
DATEPART(WEEKDAY, GETDATE()) 和 DATEPART(HOUR, GETDATE()) 怎么组合才不漏判？
- SQL Server 默认
SET DATEFIRST 7（周日为 1），所以DATEPART(WEEKDAY, GETDATE())返回 1=周日、2=周一……7=周六 - 工作日应为 2–6（周一至周五），不能写成
BETWEEN 1 AND 5或IN (2,3,4,5)漏掉周五 - 小时判断必须用
DATEPART(HOUR, GETDATE()) >= 9 AND DATEPART(HOUR, GETDATE()) < 18- 错误写法：
DATEPART(HOUR, GETDATE()) BETWEEN 9 AND 17—— 看似等价，但BETWEEN是闭区间，会放过17:59:59后的任意毫秒（如17:59:60实际进位为 18:00:00） - 更严场景可加分钟：
DATEPART(HOUR, GETDATE()) = 17 AND DATEPART(MINUTE, GETDATE()) > 59不成立，所以只需控制小时上限为 < 18
- 错误写法：
示例条件片段：
IF DATEPART(WEEKDAY, GETDATE()) NOT IN (2,3,4,5,6)
OR DATEPART(HOUR, GETDATE()) < 9
OR DATEPART(HOUR, GETDATE()) >= 18
BEGIN
THROW 50000, 'Financial data edits are only allowed Mon–Fri 09:00–17:59', 1;
END为什么必须用 AFTER 触发器而不是 INSTEAD OF？
-
INSTEAD OF会替代原操作，但财务表通常已有主键、外键、约束，手动重写 INSERT/UPDATE 逻辑极易破坏事务一致性或忽略隐式行为（比如计算列、默认值、级联） -
AFTER在语句执行完成、数据已落盘后触发，此时能安全读取inserted和deleted表校验内容，再抛错回滚整个事务 - 关键点：
AFTER触发器中抛错，会连同原始 DML 一起回滚，不留半截脏数据；而INSTEAD OF若逻辑出错，可能造成“没报错但也没存进去”的静默失败
注意：AFTER 不适用于视图，若目标是视图，必须改用 INSTEAD OF，但那就不再是“防止修改”，而是“接管修改”——风险陡增。
GETDATE() 返回的是谁的时间？时区错了怎么办？
-
GETDATE()返回 数据库服务器操作系统当前时区的本地时间，不是客户端时间，也不是 UTC - 当前时间是 2026年9月5日，星期六16时0分 → 触发器运行时会直接拦截（因
DATEPART(WEEKDAY, GETDATE()) = 7） - 如果服务器在 UTC，但业务要求按北京时间（UTC+8）判断，则必须转换：
CONVERT_TZ(GETDATE(), '+00:00', '+08:00')不可用（SQL Server 无CONVERT_TZ）
正确做法是用GETUTCDATE()+DATEADD(hour, 8, GETUTCDATE())，再提取 weekday/hour - 更稳妥的方式：把工作时间规则固化到配置表，由应用层定期同步服务器时间偏移量，避免硬编码时区逻辑
容易被忽略的一点：SQL Server 的 DATEPART(WEEKDAY, ...) 受 SET DATEFIRST 影响，不同数据库实例可能设置不同，必须显式检查：
SELECT @@DATEFIRST, DATEPART(WEEKDAY, GETDATE())
实际部署前务必验证三点：是否真在周六拦截、是否在 17:59 允许、是否在 18:00 精确拒绝——这些边界比逻辑本身更容易出问题。
