存储过程无法动态过滤返回字段，因其SELECT语句结构在编译期已固化；必须通过应用层字段裁剪或动态SQL重构SELECT子句来实现按权限返回不同字段。
存储过程本身不能动态过滤返回字段——它只能控制返回哪些行，不能控制SELECT语句里写死的列名。要实现“按权限返回不同字段”，必须在应用层或中间层做字段裁剪，或用元数据+动态SQL重构整个SELECT子句。
为什么存储过程无法直接“隐藏字段”
SQL Server、MySQL、PostgreSQL 的存储过程执行时，其 SELECT 语句结构在编译期就已固定。SELECT name, id, salary FROM users 中的 salary 字段只要写进去了，就会被解析、权限校验、执行计划生成——哪怕调用者没权限看它，数据库也不会自动剔除。视图、ITVF 同理，定义即固化。
常见误解是：「给用户只授视图权限，不授底层表权限，就能安全隐藏字段」。这只能防直接查表，但一旦视图里包含了敏感字段，且用户有该视图的 SELECT 权限，字段就必然返回。
真正起作用的是：应用拿到结果集后，根据当前用户角色主动丢弃 salary 列；或者，在拼 SQL 前先查权限配置，决定 SELECT 后面跟哪些字段。
可行方案：用动态SQL重写整个SELECT列表
核心思路不是“过滤结果”，而是“构造合法的SELECT语句”——把字段名当成变量参与拼接，再用 sp_executesql（SQL Server）或 PREPARE/EXECUTE（MySQL）执行。
- 先查权限表，获取当前用户可读的字段列表，例如：
SELECT column_name FROM user_column_perm WHERE user_role = @role AND table_name = 'users' - 把结果拼成字符串：
@select_list = N'name, id'（注意不带SELECT关键字） - 组装完整语句：
SET @sql = N'SELECT ' + @select_list + N' FROM users WHERE status = @status' - 必须显式声明所有参数类型，并确保传参顺序与
sp_executesql的参数定义严格一致 - 严禁用
CONCAT('SELECT ', @col_list, ' FROM ...')直接拼值——字段名不能参数化，必须白名单校验或硬编码映射
示例（SQL Server）：
DECLARE @sql NVARCHAR(MAX), @select_list NVARCHAR(500); SELECT @select_list = STRING_AGG(QUOTENAME(column_name), ', ') FROM user_column_perm WHERE user_role = @role AND table_name = 'users'; SET @sql = N'SELECT ' + @select_list + N' FROM users WHERE tenant_id = @tenant_id'; EXEC sp_executesql @sql, N'@tenant_id INT', @tenant_id;
更稳妥的替代路径：用应用层做字段投影
比起在数据库里拼字段，多数系统选择把这件事交给 ORM 或数据访问层处理。原因很实际：
- 数据库拼字段逻辑难测试、难调试，出错就是语法错误或权限拒绝
- 字段权限常和 UI 层强绑定（比如财务角色看到的表格列数、导出 Excel 的列顺序），由后端统一控制更灵活
- MyBatis、JOOQ、Dapper 等都支持运行时动态构建 ResultMap 或 SelectBuilder，比存储过程可控得多
- 如果用了
jsqlparser类库（如知识库提到的），可在 SQL 执行前拦截、解析、移除敏感字段，再交由 JDBC 执行
关键点在于：字段裁剪必须发生在「SQL 执行前」，而不是「结果集返回后」——否则敏感字段仍会经过网络传输，存在日志、监控、连接池缓存等泄露风险。
容易被忽略的兼容性陷阱
字段级权限不像行级那样有数据库原生支持（如 PostgreSQL RLS），所以所有方案都有隐性成本：
- SQL Server 的
QUOTENAME()必须用，否则字段名含空格或特殊字符会崩；MySQL 要用反引号，PostgreSQL 用双引号 - 动态 SELECT 不会触发查询计划缓存优化，每次执行都可能重编译——对高频小查询影响不大，但对复杂报表需评估
- 如果字段权限依赖租户上下文（如多租户 SaaS），
SESSION_CONTEXT（SQL Server）或current_setting()（PostgreSQL）必须在拼 SQL 前已设置，且不能被客户端覆盖 - 别忘了审计：谁在什么时间请求了哪些字段？这类日志得在应用层补全，存储过程自身不记录字段级访问痕迹
最常漏掉的一环是：没有同步更新 API 响应 Schema。字段删了，但 OpenAPI 文档或 DTO 类没改，前端报 Cannot read property 'salary' of undefined 才发现——这事得靠自动化契约测试兜底。
