针对你的复杂权限需求，建议采用 **“RBAC（基于角色的访问控制）+ ABAC（基于属性的访问控制）+ 个性化覆盖（Overrides）”** 的混合模式。这种结构能支持从“大颗粒度角色”到“极细颗粒度字段/行”的动态权限矩阵。

以下是为你设计的实施方案及关键表结构规划：

### 一、 核心表方案设计

为了实现“字段级”和“行级”的动态控制，我们需要将 **资源（Resource）**、**权限定义（Permission）**、**角色（Role）** 与 **用户（User）** 彻底解耦。

#### 1. 用户基础表：`tbl_auth_users`
作为全局身份锚点，记录用户的静态信息和动态属性（部门、等级）。

| 字段名 | 类型 | 说明 |
| :--- | :--- | :--- |
| **users_convers_id** | String | 会话/对话侧用户标识，允许为空 |
| **openid** | String (Unique) | **全局身份锚点**，微信唯一标识 |
| **users_name** | String | 姓名/昵称 |
| **org_id** | Int | 所属组织/部门 ID（影响行级权限的关键属性） |
| **users_rank_level** | Int | 职级/等级（影响动态权限矩阵的关键属性） |
| **users_status** | Int | 账户状态 (1: 正常, 0: 禁用) |
| **users_auth_type** | Int | 账户类型 (0: 微信小程序，1: 管理平台，2: 其他) |

---

#### 2. 资源定义表：`tbl_auth_resources`
定义系统中哪些表、哪些字段属于受控资源。

| 字段名 | 类型 | 说明 |
| :--- | :--- | :--- |
| **res_id** | Int (PK) | 资源 ID |
| **table_name** | String | 数据库表名 |
| **column_name** | String | 字段名（如果是表级权限，此项可为空或设为 '*'） |
| **res_type** | Enum | 资源类型：`TABLE`（行/全表）, `COLUMN`（字段级） |

---

#### 3. 角色与基础权限：`tbl_auth_roles` & `tbl_auth_role_perms`
实现通用的权限模板，方便批量管理。

* **`tbl_auth_roles`**: 角色表（如：财务经理、普通销售）。
* **`tbl_auth_role_perms`**: 角色权限关联表，定义该角色对某个资源的操作（读/写/无）。

---

#### 4. **核心：个性化权限覆盖表 `tbl_auth_user_overrides`**
这是满足你“某个用户对某个字段单独设置”需求的关键。

| 字段名 | 类型 | 说明 |
| :--- | :--- | :--- |
| **id** | BigInt (PK) | 自增 ID |
| **users_convers_id** | String | 用户会话标识（关联 `tbl_auth_users.users_convers_id`） |
| **res_id** | Int | 资源 ID（关联 `tbl_auth_resources`） |
| **access_level** | Int | 权限值 (0: 无权, 1: 只读, 2: 读写) |
| **priority** | Int | 优先级（当角色权限与个人设置冲突时，以此为准） |

---

#### 5. **核心：行级过滤策略表 `tbl_auth_row_scopes`**
实现“某个用户只能看自己部门/某几个项目”的动态逻辑。

| 字段名 | 类型 | 说明 |
| :--- | :--- | :--- |
| **id** | Int (PK) | 策略 ID |
| **target_type** | Enum | 目标：`USER` 或 `ROLE` |
| **target_id** | BigInt | 对应的 UserID 或 RoleID |
| **table_name** | String | 作用的表名 |
| **filter_sql** | String | 过滤逻辑。例如：`dept_id = {user.org_id}` 或 `creator_id = {user.users_convers_id}` |

---

### 二、 权限实施方案逻辑

你的权限矩阵页面将由以下逻辑驱动：

#### 1. 权限计算路径 (Effective Permissions)
当用户访问某个数据时，系统按照以下顺序合并权限：
1.  **取基础属性**：获取用户的 `org_id` 和 `users_rank_level`。
2.  **取角色权限**：获取该用户所属角色对应的资源权限列表。
3.  **应用个性化覆盖**：查询 `tbl_auth_user_overrides`。如果该表中有记录，则**覆盖**（或叠加）角色权限。
4.  **注入行级过滤**：如果是查询操作，解析 `tbl_auth_row_scopes` 中的 `filter_sql`，将 `{user.xxx}` 变量替换为当前用户的真实值。

#### 2. 动态更新机制
* **组织/等级变更**：当 `tbl_auth_users` 中的 `org_id` 或 `users_rank_level` 变化时，由于行级过滤表（`tbl_auth_row_scopes`）引用的是动态变量，**权限会自动生效**，无需重新授权。
* **缓存策略**：建议将计算后的“最终权限清单”缓存到 Redis。当用户在后台矩阵页面修改权限，或者发生组织架构调整时，通过 `wx_openid` **主动失效（Purge）** 该用户的 Redis 缓存。

#### 3. 字段级权限实现 (Field-Level)
在接口层（中间件），根据计算出的字段级权限清单（即用户对该 Table 下哪些 Column 有读权），动态过滤返回的 JSON 结构。

### 三、 总结：你需要几张表？

为了实现你描述的系统，最精简需要 **5 张表**：
1.  **`tbl_auth_users`**：用户主体（含 OpenID、部门、等级）。
2.  **`tbl_auth_resources`**：资源清单（表名、字段名）。
3.  **`tbl_auth_roles`**：角色定义。
4.  **`tbl_auth_role_perms`** / **`tbl_auth_user_overrides`**：权限映射（解决字段级和个人特权）。
5.  **`tbl_auth_row_scopes`**：行级过滤表达式（解决多维数据隔离）。
