最稳妥的做法是直接授予INSERT权限并显式DENY其余操作；因权限累加，仅GRANT INSERT无法阻止UPDATE/DELETE，而DENY优先级高于GRANT，表级GRANT+DENY组合可精准控制单表插入权限。
直接给 INSERT 权限、显式 DENY 其余操作，是最稳妥的做法。仅靠 GRANT INSERT 不足以阻止用户执行 UPDATE 或 DELETE —— 因为权限是累加的，如果用户属于 db_datawriter 角色或有更高权限，GRANT INSERT 就形同虚设。
用 GRANT + DENY 组合控制单表粒度
对具体某张表（比如 Sales.Orders）限制只允许插入：
GRANT INSERT ON Sales.Orders TO [user_name];DENY UPDATE ON Sales.Orders TO [user_name];DENY DELETE ON Sales.Orders TO [user_name];
DENY 优先级高于 GRANT，哪怕该用户属于 db_datawriter，这三条语句也能生效。注意：必须对同一对象（表）执行，不能只 DENY 架构级权限来“覆盖”——因为 DENY ON SCHEMA :: dbo 会拦住所有表，不够精准。
避免误伤：慎用架构级 DENY
如果你运行了 DENY INSERT ON SCHEMA :: dbo TO [user_name]，再单独 GRANT INSERT 到某张表，这条 GRANT 会被 DENY 覆盖而失效。反过来也一样：DENY UPDATE ON SCHEMA :: dbo 会锁死整个架构下所有表的 UPDATE，无法被单表 GRANT UPDATE 覆盖。
- 架构级
DENY是“全有或全无”，适合批量封禁，不适合精细放行 - 要实现“只允许某表 INSERT”，必须在表级做
GRANT和DENY - 执行前先查用户当前权限：
SELECT * FROM sys.database_permissions WHERE grantee_principal_id = USER_ID('user_name');
检查是否真生效：用 EXECUTE AS 测试
别只信语法没报错，得模拟用户身份验证实际行为：
EXECUTE AS USER = 'user_name';- 跑一条
INSERT INTO Sales.Orders (...) VALUES (...);→ 应成功 - 跑一条
UPDATE Sales.Orders SET ... WHERE ...;→ 应报错The SELECT permission was denied on the object 'Orders'（错误信息可能提 SELECT，但本质是权限拒绝） -
REVERT;恢复上下文
SQL Server 在拒绝 UPDATE 时有时会报错中带 SELECT 字样，这是因为它内部先尝试获取共享锁读取原值，不是你漏授了 SELECT 权限。
长期维护要注意角色继承冲突
生产环境里，用户往往属于多个数据库角色（如 db_datareader、db_datawriter）。这些角色自带 UPDATE 和 DELETE 权限，会和你手动设的 DENY 冲突。
- 先运行
EXEC sp_helpuser 'user_name';查清角色成员关系 - 若用户必须留在
db_datawriter中，就只能靠DENY覆盖；否则建议移出该角色，改用最小权限组合 - 脚本部署时，
DENY语句必须在角色赋权之后执行，否则可能被后续角色脚本覆盖
真正难的不是写那几条 GRANT 和 DENY，而是理清权限来源链——用户权限可能来自登录名映射、数据库角色、架构角色、甚至跨数据库来宾用户，漏查任意一层都可能导致策略失效。
