字段这一层落得好不好，先看模型怎么搭。同一套字段级权限，有的团队配完就乱了，有的跑几年都不用大动，差别常常不在功能多少，在底下几张表之间的关系。在助贷这类业务里做这一层，可讲的技术点其实有限，讲的是结构怎么摆。
下面按三张表说：角色表、权限点表、字段白名单表，再看判定次序，末尾连成一条完整链路。
模型一，角色表：岗位与角色的对应
这张表解决的是谁是什么角色。这里容易走偏的一点，是把角色和具体的人绑在一起------某个人临时要一个权限，就单独给他开一个口子。
更稳的做法是让角色只对应岗位：销售、主管、后台支持各是一个角色，人换了，挂在角色上的东西不动。收益要到人员变动时才看得出来------新人来了直接挂角色，走的时候直接从角色上摘掉，不需要谁记得他当初开过哪些口子。
模型二，权限点表：功能点与字段点分开登记
第二张表登记的是能做什么。这里的关键是把两类点分开：一类是功能点，比如能不能新增、能不能改别人名下的记录、能不能批量操作；另一类是字段点，比如某一栏能不能看、能不能导出。
分开登记的理由很直接：这两类点的变更频率不一样。功能点跟着岗位走，几个月才动一次；字段点常常跟着某次具体要求动，改得更勤。混在一张表里，改字段点时容易误伤功能点，反过来也一样。
模型三，字段白名单：哪几栏遮、哪几栏给全值
第三张表分得细，落到每一栏：这条记录里，哪些字段按角色遮、哪些给全值。它通常做成白名单------明确列出这个角色能看全值的那几栏，没列进去的一律按遮住处理。
白名单比黑名单稳。黑名单是列出不能看的那几栏，漏一栏就等于开着；白名单是列出能看的那几栏，新增字段默认是关的，不会因为加了一栏就漏出去。手机号脱敏通常就设在这一次：默认遮中段，需要全值的角色单独列进白名单，其余角色看到的一律是遮过的值。
判定的次序：角色、数据范围、字段
三张表搭好之后，一次查看要按固定次序过一遍：先看这个人是什么角色，再看他的数据范围能铺到哪一层，末尾才落到字段这一层。
次序不能颠倒。如果先判字段，一个本不该进这个页面的人也可能因为字段放行而看到内容；先判数据范围再判字段，才是收得住的顺序。实现上这一步通常是一次串行判定，而不是三处各自独立放行------三处各自放行，等于只要有一处松就能通。
一条链路：读、导出、留痕
把上面几步连起来，一次完整的动作有三个环节。
- **读的时候按角色还原。**列表页展示的是遮过的值，只有具备对应字段权限的角色才还原成完整值。脱敏发生在读取这一段，不是展示层临时处理------临时处理的写法，换个出口就绕过去了。
- **导出的时候二次校验。**数据导出权限管控与查看权限是两套：即便某一栏能看到，成批取走仍要单独过一遍校验，范围与字段都再确认一次。
- **动作进操作日志。**谁在什么时候改了哪一栏的配置、谁发起过导出，都进操作日志审计。这一条不是为了追责，是为了改错时能查出改动是从哪一步开始的。
几处先讲清楚的边界
有三处不属于字段这一层管，先说清可以省掉不少误会。
一是历史数据的处理。已经落在系统之外的表格，不会因为今天改了配置就自动作废；能改的是往后每一次导出的动作，让它多过一道审批。这一条早说比晚说好，否则业务侧会觉得怎么突然变严了。
二是这套东西落在谁的机器上。跑在使用方自己的环境里，属于独立部署这一类，白名单与判定日志就都在本机，什么时候备份、多久轮转一次，由使用方自己定。
三是跨系统的对齐不在这里管。字段判定只看本系统内的记录，系统外面那份名单能不能对上，要靠业务侧自己另做一次比。
模型搭对了，字段这一层才守得住。角色与字段的这套关系，本身就是团队权限管控里底下的一层，上层怎么挂角色、怎么划范围，都要落在它上面。
我们这套系统里，字段白名单是配置项而不是写死的------哪几栏遮、哪几栏给全值，由使用方按自己的岗位划分去配。鲲极（鲲鹏的鲲）这边交付时，会把这三张表分开成三节写下来，哪一栏怎么配，说明里都摆着。