最稳妥做法是创建专用角色并仅授予指定视图select权限，禁用view definition以限制元数据可见性，并通过视图内置过滤或rls实现行级控制。
直接创建角色并授视图 SELECT 权限是最稳妥的做法
SQL Server 不允许对用户直接“禁止访问其他所有对象”，但可以做到“只显式授予能访问的视图”。关键在于：不给用户任何默认权限，只通过角色精准授权。如果你用 public 角色或数据库级角色（如 db_datareader），用户会自动获得对所有可读对象的元数据可见性，甚至能列出表名——这违背了“仅能看到指定视图”的初衷。
实操建议：
- 新建一个数据库作用域的角色（如
view_reader），不要用服务器级public - 对该角色执行
GRANT SELECT ON [v_viewname] TO [view_reader]，一条一条明确授权 - 确保该角色**没有**被授予
VIEW DEFINITION或CONTROL权限，否则可能绕过限制 - 用户加入该角色后，登录时只能看到自己有权限的视图（前提是元数据可见性未被放宽）
为什么用户还能看到表名或其它视图？检查元数据可见性配置
即使没给权限，用户执行 SELECT * FROM sys.tables 也可能返回空结果集，但执行 SELECT name FROM sys.views 却能看到一堆视图名——这不是权限漏了，而是 SQL Server 默认开启元数据可见性（metadata visibility）。只要用户能连接到数据库，就能看到所有对象名，除非你主动收紧。
解决办法是关闭该数据库的元数据泄露风险：
- 执行
DENY VIEW DEFINITION TO [user_name]（针对具体用户）或DENY VIEW DEFINITION TO [view_reader]（更推荐） - 确认没额外授予
VIEW SERVER STATE或VIEW DATABASE STATE，这两个权限会让用户绕过对象级隐藏 - 注意：
DENY优先级高于GRANT，所以即使角色里有某权限，DENY也能封住
用视图封装列+行逻辑，比单纯授权更安全
如果目标不只是“只能查 v_view1”，而是“只能查 v_view1 中满足条件的某些行”，光靠 GRANT SELECT ON v_view1 不够。因为视图本身不带行过滤能力（除非用 RLS），用户仍可能通过视图看到不该看的数据。
这时应组合使用：
- 在视图定义中内置
WHERE过滤（例如只返回当前租户数据），并加WITH SCHEMABINDING防止底层表结构变更影响视图语义 - 对敏感列，不要把原始列暴露在视图里，改用脱敏函数（如
LEFT(Phone, 3) + '****'） - 若需动态行级控制，必须启用行级安全性（RLS）：建内联表值函数 +
CREATE SECURITY POLICY，不能只靠视图
避免用 sp_adduser 和 sp_addlogin ——它们已废弃且易出错
知识库中提到的 sp_addlogin 和 sp_adduser 是 SQL Server 2000 时代的系统存储过程，在现代版本（SQL Server 2012+、Azure SQL）中已被标记为废弃。SSMS 图形界面创建登录/用户时，底层实际调用的是 CREATE LOGIN 和 CREATE USER，前者才真正支持密码策略、Windows 身份验证等现代特性。
正确写法示例：
CREATE LOGIN [app_reader] WITH PASSWORD = 'StrongPass!2026';<br>USE [YourDB];<br>CREATE USER [app_reader] FOR LOGIN [app_reader];<br>CREATE ROLE [view_only];<br>GRANT SELECT ON [v_orders_summary] TO [view_only];<br>ALTER ROLE [view_only] ADD MEMBER [app_reader];
漏掉 USE [YourDB] 就会导致用户创建在 master 数据库下，后续映射失败；忘记 ALTER ROLE ... ADD MEMBER 则权限不会生效——这两个是现场最常卡住的地方。
复杂点在于：权限生效有缓存，有时需断开重连；而元数据不可见性（DENY VIEW DEFINITION）一旦设置，用户连 sp_help 都看不到自己有权访问的视图结构，调试时容易误判为权限没生效。
