1. 部门级数据范围定义：部门维度划分、数据归属规则、组织树模型

部门级数据范围是权限隔离体系的第一层锚点。它定义了数据“属于哪个部门”，以及如何通过组织树将部门维度映射为可计算的权限边界。本章围绕组织树的边界、分层模型、组件职责、控制流与信任链路展开，并给出选型权衡、风险点、落地步骤与验收标准。

1.1 边界定义

部门级边界指数据在组织树中某部门节点及其下属子树范围内的可见性与可控性。边界条件包括：

• 数据创建时绑定的部门 ID（归属规则）
• 组织树中父部门可访问子部门数据（向下传递）
• 平级部门默认隔离（除非显式授权）
• 组织树变更（合并/拆分/迁移）后数据归属自动跟随

1.2 分层模型：组织树的三层抽象

组织树模型并非直接复制企业 HR 系统结构，而是根据权限管控粒度抽象为三层：

每一层对应一套数据归属规则：数据写入时根据操作者所在工作域自动标记部门 ID，并向上聚合至业务域和顶层域。

1.3 组件职责

• 组织树维护服务：同步 HR 系统或手动维护节点增删改，保证树形结构正确。
• 数据归属打标器：在数据写入或修改时，根据上下文（用户部门、数据分类）写入 department_id。
• 权限策略引擎：根据登录用户所在节点，利用树路径匹配算法计算可访问数据集合。
• 变更审计日志：记录组织树变更前后数据归属关系，用于回溯和冲突检测。

1.4 数据流 / 控制流与信任链路

1.5 选型权衡

1.6 风险点

• 组织树变更导致权限漂移：部门合并后，原部门数据归属未同步，出现孤儿数据或越权访问。
• 归属规则歧义：数据同时属于多个部门（如跨部门项目），缺乏主部门或共享逻辑，造成重复计数或权限冲突。
• 深度递归查询性能：组织树超过 6 层时，MySQL 递归 CTE 或 Nested Set 查询可能成为瓶颈。
• 缓存一致性问题：组织树变更后，若缓存未及时更新，用户仍看到旧部门范围的数据。

1.7 落地步骤

1. 梳理组织架构：确定公司、事业部、部门、小组的层级与编码规范。
2. 设计组织树存储模型（建议邻接表 + 深度路径缓存或 Nested Set）。
3. 开发数据归属打标器：在数据写入时自动填充 department_id（部门节点 ID）。
4. 实现策略引擎：根据用户所在部门节点，通过递归获取所有子节点 ID 集合，构造 IN 查询。
5. 编写变更处理器：当组织树节点被移动或删除时，触发数据归属重新计算或挂起访问。
6. 构建审计日志：记录每次归属变更前后的 department_id 快照。

1.8 验收标准