diff --git a/微服务/ds-cloud/用户权限/用户权限设计.md b/微服务/ds-cloud/用户权限/用户权限设计.md
new file mode 100644
index 0000000..220f33c
--- /dev/null
+++ b/微服务/ds-cloud/用户权限/用户权限设计.md
@@ -0,0 +1,137 @@
+设计一个用户和权限管理系统是一个相对复杂的任务，尤其是涉及到后台管理系统和门户两个不同应用的情况。以下是一个简单的设计思路，你可以根据具体需求进行调整和扩展。
+
+## 1. 用户管理
+
+### 1.1 用户信息
+
+在数据库中创建一个用户表，包含如下字段：
+
+- **ID**: 唯一标识符
+- **用户名**
+- **密码（加密存储）**
+- **姓名**
+- **邮箱**
+- **电话号码**
+- **创建时间**
+- **最后登录时间**
+- **状态（启用/禁用）**
+
+### 1.2 用户角色
+
+创建一个角色表，以及用户角色关联表，这样可以实现一个用户拥有多个角色的情况。
+
+- **角色表**
+  - **ID**
+  - **角色名称**
+  - **描述**
+- **用户角色关联表**
+  - **用户ID**
+  - **角色ID**
+
+## 2. 权限管理
+
+### 2.1 权限资源
+
+在数据库中创建一个权限资源表，用于存储系统中的各种资源，如菜单、页面、功能等。
+
+- **ID**
+- **资源名称**
+- **资源类型（菜单、页面、按钮等）**
+- **资源路径**
+- **父资源ID（用于构建资源树）**
+- **排序字段**
+- **是否需要权限控制**
+
+### 2.2 角色权限
+
+创建一个角色权限关联表，记录角色拥有的权限。
+
+- **角色ID**
+- **权限ID**
+
+## 3. 后台管理系统和门户系统适配
+
+### 3.1 权限隔离
+
+在设计时要确保后台管理系统和门户系统有自己的权限资源，不同的角色在这两个系统中可以有不同的权限。
+
+### 3.2 公用用户表
+
+两个系统可以共用同一个用户表，但需要注意一些特定字段和信息，如用户登录后所看到的默认页面、角色、权限等，在两个系统中可能会有不同的配置。
+
+## 4. 登录和身份验证
+
+### 4.1 单点登录（可选）
+
+如果后台管理系统和门户系统是不同的应用，你可以考虑使用单点登录（SSO）机制，以确保用户在一个系统登录后，在另一个系统中无需重新登录。
+
+### 4.2 Token 验证
+
+使用 Token 或其他类似的身份验证机制，确保系统的安全性。
+
+## 5. 前后端交互
+
+### 5.1 API 接口设计
+
+设计清晰的 API 接口，包括用户注册、登录、角色授权、权限获取等功能。
+
+### 5.2 安全性
+
+在前后端交互中确保数据传输的安全性，使用 HTTPS 协议等手段进行保护。
+
+## 6. 日志记录
+
+为系统操作和权限变更等关键操作设计日志记录机制，以便追踪系统使用和排查问题。
+
+这只是一个基本的设计思路，实际情况可能更为复杂，具体的实现会依赖于你的项目需求和技术栈。在具体实施之前，建议先对系统需求和用例进行深入分析。
+
+## 7. 数据表DDL
+
+```sql
+-- 用户信息表
+CREATE TABLE users (
+    user_id INT PRIMARY KEY AUTO_INCREMENT COMMENT '用户唯一标识符',
+    username VARCHAR(255) NOT NULL COMMENT '用户名',
+    password VARCHAR(255) NOT NULL COMMENT '密码',
+    name VARCHAR(255) NOT NULL COMMENT '姓名',
+    email VARCHAR(255) NOT NULL COMMENT '邮箱',
+    phone_number VARCHAR(20) COMMENT '电话号码',
+    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
+    last_login_at TIMESTAMP COMMENT '最后登录时间',
+    status ENUM('ENABLED', 'DISABLED') DEFAULT 'ENABLED' COMMENT '用户状态（启用/禁用）'
+);
+
+-- 角色表
+CREATE TABLE roles (
+    role_id INT PRIMARY KEY AUTO_INCREMENT COMMENT '角色唯一标识符',
+    role_name VARCHAR(255) NOT NULL COMMENT '角色名称',
+    description TEXT COMMENT '角色描述'
+);
+
+-- 用户角色关联表
+CREATE TABLE user_roles (
+    user_id INT,
+    role_id INT,
+    PRIMARY KEY (user_id, role_id) COMMENT '联合主键'
+);
+
+-- 权限资源表
+CREATE TABLE permissions (
+    permission_id INT PRIMARY KEY AUTO_INCREMENT COMMENT '权限唯一标识符',
+    resource_name VARCHAR(255) NOT NULL COMMENT '资源名称',
+    resource_type ENUM('MENU', 'PAGE', 'BUTTON') NOT NULL COMMENT '资源类型',
+    resource_path VARCHAR(255) COMMENT '资源路径',
+    parent_resource_id INT COMMENT '父资源ID',
+    sort_order INT COMMENT '排序字段',
+    requires_permission BOOLEAN DEFAULT TRUE COMMENT '是否需要权限控制'
+);
+
+-- 角色权限关联表
+CREATE TABLE role_permissions (
+    role_id INT,
+    permission_id INT,
+    PRIMARY KEY (role_id, permission_id) COMMENT '联合主键'
+);
+
+```
+
diff --git a/微服务/ds-cloud/用户权限/用户权限设计2.md b/微服务/ds-cloud/用户权限/用户权限设计2.md
new file mode 100644
index 0000000..7cb0f75
--- /dev/null
+++ b/微服务/ds-cloud/用户权限/用户权限设计2.md
@@ -0,0 +1,32 @@
+
+当设计一个同时适用于后台管理系统和门户的用户和权限管理系统时，需要考虑到系统的灵活性、安全性和易用性。以下是一个基本的设计框架，你可以根据具体需求进行调整和扩展：
+
+1. **用户管理：**
+   - 用户注册：提供用户注册功能，收集必要的信息，并确保注册信息的合法性。
+   - 用户认证：使用安全的身份验证机制，如用户名和密码、双因素身份验证等。
+   - 用户信息管理：允许用户管理个人信息，例如修改密码、更新联系信息等。
+2. **角色管理：**
+   - 定义不同角色：根据系统需求，定义不同的用户角色，如管理员、普通用户、编辑等。
+   - 分配权限：为每个角色分配特定的权限，确保用户只能访问其需要的功能和信息。
+3. **权限管理：**
+   - 精确控制：确保权限控制是细粒度的，以便根据具体需求为不同的用户角色分配适当的权限。
+   - 动态权限：支持动态权限，使管理员可以在运行时调整用户的权限。
+4. **组织结构：**
+   - 部门和组织单元：如果系统涉及多个部门或组织单元，考虑在权限管理中包含这些信息，以便更好地组织和管理用户。
+5. **日志和审计：**
+   - 记录日志：记录用户的活动，以便在发生问题时进行审计和追踪。
+   - 审计功能：提供审计功能，允许管理员查看和分析用户的操作历史。
+6. **界面设计：**
+   - 后台管理界面：设计简洁而功能强大的后台管理界面，使管理员能够轻松管理用户、角色和权限。
+   - 门户界面：门户界面应友好，易于导航，同时确保用户只能访问其具备权限的内容和功能。
+7. **安全性考虑：**
+   - 数据加密：对敏感信息使用加密存储和传输，确保数据安全性。
+   - 防止注入攻击：采用参数化查询等技术防范SQL注入攻击。
+   - 防范跨站脚本攻击（XSS）和跨站请求伪造攻击（CSRF）。
+8. **集成和扩展性：**
+   - 集成第三方身份验证：如果需要，考虑集成第三方身份验证，如OAuth、LDAP等。
+   - API支持：提供API支持，以便其他系统可以与用户和权限管理系统集成。
+9. **持续改进：**
+   - 反馈机制：收集用户反馈，定期进行系统评估，以便进行必要的改进和升级。
+
+以上只是一个基本的框架，具体实现可能会依赖于你的业务需求和技术栈。确保与团队合作，理解最终用户的需求，并根据具体情况进行调整。
\ No newline at end of file