diff --git a/.gitignore b/.gitignore
index 9b1960e..41a26d7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
-output/
\ No newline at end of file
+output/
+自学/本地记录.md
diff --git a/自学/智能协同云图库.md b/自学/智能协同云图库.md
index 3c4060d..b8609b7 100644
--- a/自学/智能协同云图库.md
+++ b/自学/智能协同云图库.md
@@ -141,18 +141,39 @@ private static final long serialVersionUID = -1321880859645675653L;
 
 
 
-## 多级缓存
+## 收获
+
+### 胡图工具类hutool
+
+`ObjUtil.isNotNull(Object obj)`，仅判断对象是否 **不为 `null`**，不关心对象内容是否为空，比如空字符串 `""`、空集合 `[]`、数字 `0` 等都算是“非 null”。
+
+`ObjUtil.isNotEmpty(Object obj)` 判断对象是否 **不为 null 且非“空”**
+
+- 对不同类型的对象判断逻辑不同：
+  - `CharSequence`（String）：长度大于 0
+  - `Collection`：size > 0
+  - `Map`：非空
+  - `Array`：长度 > 0
+  - 其它对象：只判断是否为 null（默认不认为“空”）
+
+
+
+`StrUtil.isNotEmpty(String str) `只要不是 `null` 且长度大于 0 就算“非空”。
+
+`StrUtil.isNotBlank(String str)` 不仅要非 `null`，还要**不能只包含空格、换行、Tab 等空白字符**
+
+`StrUtil.hasBlank(CharSequence... strs)`只要 **至少一个字符串是 blank（空或纯空格）**就返回 `true`，底层其实就是对每个参数调用 `StrUtil.isBlank(...)`
+
+
+
+`CollUtil.isNotEmpty(Collection<?> coll)`用于判断 **集合（Collection）是否非空**，功能类似于 `ObjUtil.isNotEmpty(...)`
+
+### 多级缓存
 
 ![image-20250614101747456](https://pic.bitday.top/i/2025/06/14/gtsa80-0.png)
 
-目前貌似没有使用缓存、@deprecated
 
 
-
-
-
-## 收获
-
 ### Redis+Session
 
 之前我们每次重启服务器都要重新登陆，既然已经整合了 `Redis`，不妨使用 `Redis` 管理` Session`，更好地维护登录态。
@@ -236,3 +257,63 @@ server:
 - B 在锁里执行 `exists`：因为 A 的改动还在 A 的未提交事务里，**默认隔离级别（READ_COMMITTED）下看不到**，所以 `exists` 会返回 `false`
 - B 就继续 `save`，结果就可能插入重复记录，或者引发唯一索引冲突
 
+
+
+### RBAC模型
+
+团队空间：
+
+![image-20250620092726446](https://pic.bitday.top/i/2025/06/20/fc2bbu-0.png)
+
+一般来说，标准的` RBAC` 实现需要 5 张表：用户表、角色表、权限表、用户角色关联表、角色权限关联表，还是有一定开发成本的。由于我们的项目中，团队空间不需要那么多角色，可以简化`RBAC` 的实现方式，比如将角色和权限直接定义到配置文件中。
+
+本项目角色：
+
+| 角色   | 描述                         |
+| ------ | ---------------------------- |
+| 浏览者 | 仅可查看空间中的图片内容     |
+| 编辑者 | 可查看、上传和编辑图片内容   |
+| 管理员 | 拥有管理空间和成员的所有权限 |
+
+本项目权限：
+
+| 权限键         | 功能名称 | 描述                         |
+| -------------- | -------- | ---------------------------- |
+| spaceUsername  | 成员管理 | 管理空间成员，添加或移除成员 |
+| picture:view   | 查看图片 | 查看空间中的图片内容         |
+| picture:upload | 上传图片 | 上传图片到空间中             |
+| picture:edit   | 修改图片 | 编辑已上传的图片信息         |
+| picture:delete | 删除图片 | 删除空间中的图片             |
+
+角色权限映射：
+
+| 角色   | 对应权限键                                                   | 可执行功能                                       |
+| ------ | ------------------------------------------------------------ | ------------------------------------------------ |
+| 浏览者 | picture:view                                                 | 查看图片                                         |
+| 编辑者 | picture:view, picture:upload, picture:edit, picture:delete   | 查看图片、上传图片、修改图片、删除图片           |
+| 管理员 | spaceUsername, picture:view, picture:upload, picture:edit, picture:delete | 成员管理、查看图片、上传图片、修改图片、删除图片 |
+
+
+
+RBAC 只是一种权限设计模型，我们在 Java 代码中如何实现权限校验呢？
+
+1）最直接的方案是像之前校验私有空间权限一样，封装个团队空间的权限校验方法；或者类似用户权限校验一样，写个注解 + AOP 切面。
+
+2）对于复杂的角色和权限管理，可以选用现成的第三方权限校验框架来实现，编写一套权限校验规则代码后，就能整体管理系统的权限校验逻辑了。（ Sa-Token）
+
+
+
+### 分库分表
+
+如果某团队空间的图片数量比较多，可以对其数据进行单独的管理。
+
+1、图片信息数据
+可以给每个团队空间单独创建一张图片表 picture_{spaceId}，也就是分库分表中的分表，而不是和公共图库、私有空间的图片混在一起。这样不仅查询空间内的图片效率更高，还便于整体管理和清理空间。但是要注意，仅对**旗舰版**空间生效，**否则分表的数量会特别多**，反而可能影响性能。
+
+要实现的是会随着新增空间不断增加分表数量的**动态分表**，会使用分库分表框架 **Apache ShardingSphere** 带大家实现。
+2、图片文件数据
+
+已经实现隔离，存到COS上的不同桶内。
+
+
+