表头字段权限需与租户ID联动实现动态表头，核心是后端根据认证上下文（如JWT）提取租户ID，返回结构化字段配置（含visible/sortable/searchable等元信息），前端据此渲染；字段名须统一映射数据库列名，禁用前端硬编码与基于字段名的CSS类，确保权限贯穿定义、传输、渲染、导出全链路。
表头字段权限怎么和租户ID联动
动态表头的核心不是“渲染多列”，而是“对同一张表结构，不同租户看到的th必须不同”。关键在于权限判断不能放在前端硬编码，也不能靠后端拼HTML字符串——必须由后端返回结构化字段定义，并携带visible或order等元信息。
常见错误是把租户ID当参数传给前端，再让JS根据租户角色过滤th列表——这等于把权限逻辑暴露在客户端，且无法防止用户手动修改DOM绕过限制。
- 后端接口（如
/api/tenant/{tenant_id}/table-config）应返回类似：[{"field": "order_no", "label": "订单号", "visible": true, "sortable": true}, {"field": "customer_phone", "label": "客户电话", "visible": false, "sortable": false}] - 前端用该配置生成
thead，跳过visible: false项，不渲染对应th和td - 租户ID必须从认证上下文（如JWT payload 或 session）中提取，禁止由前端传入用于权限判定
如何避免字段名硬编码导致权限失效
字段名（field）一旦在前后端不一致，权限配置就形同虚设。比如后端返回"cust_phone"，前端却按"customer_phone"匹配，结果该列永远显示。
最稳妥的做法是：所有字段名统一由数据库字段名或领域模型属性名直接映射，禁止人工重命名后再维护映射表。
立即学习“前端免费学习笔记（深入）”；
- 后端生成配置时，用实体类的
@Column(name = "phone")注解值作为field，而非业务别名 - 前端渲染
td时，一律用row[field]取值，不写row.customer_phone这类硬编码 - 引入CI检查：扫描所有
field值是否存在于对应实体类的getter方法名或JPA列名中
排序/搜索字段权限和表头权限必须分离
visible: false不等于searchable: false或sortable: false。有些租户虽不可见某字段，但需支持按该字段筛选（如管理员后台），或允许导出含敏感字段的Excel（导出走独立权限校验）。
若混用权限标志，会导致导出功能异常、搜索行为不一致，甚至出现“看不见但搜得到”的安全漏洞。
- 表头渲染只依赖
visible - 搜索框下拉选项、排序下拉菜单、导出字段列表，各自读取
searchable/sortable/exportable字段 - 这些布尔值需在租户策略配置中独立设置，不能默认同步
visible
CSS类名泄露租户字段结构怎么办
为方便样式控制，开发者常给th加class="col-customer_phone"，但这会暴露字段名，攻击者可通过查看源码推测数据库结构或租户能力边界。
尤其在SaaS多租户场景，字段名本身就是敏感信息（如credit_score、internal_status）。
- 禁用基于字段名的class，改用顺序索引或哈希值：
class="col-0"、class="col-a7f2" - 若需主题定制，通过CSS自定义属性（
--col-width-0）传递样式参数，而非class名 - 服务端模板渲染时，对字段名做一次SHA-256截断哈希，确保相同字段在不同租户下哈希值一致，但无法反推原名
字段权限不是加个v-if就完事的事——它得贯穿字段定义、传输、渲染、交互、导出全链路，任何一环脱节都可能让“不可见”变成“可猜、可调、可绕”。
