修复本地屏蔽规则管理

.trae/documents/优化设置界面实现计划.md

@@ -1,84 +0,0 @@
-# 优化设置界面实现计划
-
-## 问题分析
-当前设置界面存在配置项重复问题，需要进行优化，具体包括：
-1. "远程规则URL"配置项在多个界面重复出现
-2. "启用API"和"主机"选项不需要在当前界面显示
-3. 需要确保保存功能正常工作，写入config.json并触发服务器重新加载配置
-
-## 优化方案
-
-### 1. 修改HTML结构
-- 移除"远程规则URL"配置项
-- 移除"启用API"选项
-- 移除"主机"选项
-- 调整布局，确保界面美观合理
-
-### 2. 更新JavaScript代码
-- 修改`populateConfigForm`函数，移除对已删除配置项的处理
-- 修改`collectFormData`函数，移除对已删除配置项的收集
-- 确保保存功能能正确写入config.json文件
-- 实现服务器重新加载配置的触发机制
-- 提供明确的成功/失败反馈
-
-### 3. 测试和验证
-- 测试所有保留配置项的加载和保存功能
-- 验证保存操作能正确写入config.json文件
-- 验证服务器能重新加载配置
-- 测试成功/失败反馈是否明确
-
-## 具体实现步骤
-
-1. **修改HTML结构**
-   - 编辑`index.html`文件，移除不需要的配置项
-   - 调整布局，确保界面美观合理
-
-2. **更新JavaScript代码**
-   - 编辑`config.js`文件，修改`populateConfigForm`函数
-   - 修改`collectFormData`函数，移除对已删除配置项的处理
-   - 确保`handleSaveConfig`函数能正确保存配置
-   - 实现服务器重新加载配置的触发机制
-
-3. **测试和验证**
-   - 测试配置项的加载功能
-   - 测试配置项的保存功能
-   - 验证config.json文件是否正确更新
-   - 验证服务器是否重新加载配置
-   - 测试成功/失败反馈是否明确
-
-## 预期效果
-- 设置界面布局合理，无重复配置项
-- 所有保留配置项均可正常配置
-- 保存功能能正确写入config.json文件
-- 服务器能重新加载配置，使更改立即生效
-- 保存操作有明确的成功/失败反馈
-
-## 技术要点
-- 使用HTML和JavaScript修改界面结构和功能
-- 确保与服务器API的正确交互
-- 实现良好的用户反馈机制
-- 确保配置的正确保存和加载
-
-## 实现时间
-- 预计1-2小时完成所有修改和测试
-
-## 风险评估
-- 低风险：修改范围明确，不涉及核心功能
-- 可回滚：所有修改均为前端修改，可通过恢复文件轻松回滚
-
-## 依赖关系
-- 依赖服务器API的正常工作
-- 依赖config.json文件的读写权限
-
-## 测试策略
-- 手动测试所有配置项的加载和保存功能
-- 验证config.json文件的更新
-- 测试服务器配置的重新加载
-- 测试成功/失败反馈
-
-## 验收标准
-- 设置界面布局合理，无重复配置项
-- 所有保留配置项均可正常配置
-- 保存功能能正确写入config.json文件
-- 服务器能重新加载配置，使更改立即生效
-- 保存操作有明确的成功/失败反馈

.trae/documents/修复CPU使用率卡片WebSocket自动更新问题 (1).md

@@ -1,22 +0,0 @@
-## 问题分析
-CPU使用率卡片在WebSocket实时更新时没有刷新数据，原因是：
-1. `processRealTimeData`函数调用了`updateStatsCards(stats)`，但该函数的CPU使用率更新逻辑可能没有被正确执行
-2. `processRealTimeData`函数对其他卡片（如平均响应时间、最常用查询类型、活跃IP数）有单独的更新逻辑，但缺少了CPU使用率卡片的更新逻辑
-3. `loadDashboardData`函数中有完整的CPU使用率更新逻辑，这就是为什么页面初始加载时CPU使用率能显示，但后续WebSocket更新时不能显示的原因
-
-## 修复方案
-1. **在`processRealTimeData`函数中添加CPU使用率卡片的更新逻辑**：类似于`loadDashboardData`函数中的实现
-2. **确保从`stats`对象中正确获取CPU使用率数据**：支持从不同的数据结构中获取CPU使用率
-3. **更新DOM元素**：将获取到的CPU使用率数据更新到`cpu-usage`和`cpu-status`元素中
-4. **添加状态判断**：根据CPU使用率值设置不同的状态文本和样式
-
-## 实现步骤
-1. 打开`dashboard.js`文件
-2. 找到`processRealTimeData`函数（约第120行）
-3. 在函数末尾添加CPU使用率更新逻辑，位于其他卡片更新逻辑之后
-4. 确保从`stats`对象中正确获取CPU使用率数据
-5. 更新`cpu-usage`和`cpu-status`元素的内容和样式
-6. 测试修复是否生效
-
-## 预期效果
-修复后，当WebSocket接收到实时数据更新时，CPU使用率卡片会自动更新显示最新的CPU使用率和状态，与其他统计卡片保持一致的实时更新效果。

.trae/documents/修复CPU使用率卡片WebSocket自动更新问题 (2).md

@@ -1,22 +0,0 @@
-## 问题分析
-CPU使用率卡片在WebSocket实时更新时没有刷新数据，原因是：
-1. `updateStatsCards`函数中，数组形式的数据结构处理部分（第631-641行）缺少CPU使用率的处理逻辑
-2. 可能存在数据字段名不匹配的问题，WebSocket服务器返回的CPU使用率数据可能使用了不同的字段名
-3. `processRealTimeData`函数和`updateStatsCards`函数中都有CPU使用率更新逻辑，可能导致冲突或其中一个逻辑没有被正确执行
-
-## 修复方案
-1. **完善`updateStatsCards`函数的CPU使用率处理逻辑**：在数组形式的数据结构处理部分添加CPU使用率的处理逻辑
-2. **添加更多可能的CPU使用率字段名支持**：确保从WebSocket服务器返回的CPU使用率数据能够被正确获取，无论它使用什么字段名
-3. **统一CPU使用率更新逻辑**：确保`processRealTimeData`函数和`updateStatsCards`函数中的CPU使用率更新逻辑一致
-4. **添加调试日志**：在关键位置添加调试日志，以便于排查问题
-
-## 实现步骤
-1. 打开`dashboard.js`文件
-2. 找到`updateStatsCards`函数的数组形式数据结构处理部分（第631-641行），添加CPU使用率的处理逻辑
-3. 在`updateStatsCards`函数的CPU使用率数据获取逻辑中，添加更多可能的字段名支持
-4. 统一`processRealTimeData`函数和`updateStatsCards`函数中的CPU使用率更新逻辑
-5. 添加调试日志，以便于排查问题
-6. 测试修复是否生效
-
-## 预期效果
-修复后，当WebSocket接收到实时数据更新时，CPU使用率卡片会自动更新显示最新的CPU使用率和状态，与其他统计卡片保持一致的实时更新效果。

.trae/documents/修复CPU使用率卡片WebSocket自动更新问题.md

@@ -1,18 +0,0 @@
-## 问题分析
-CPU使用率卡片数据不会跟随WebSocket自动更新的原因是`updateStatsCards`函数中缺少了CPU使用率的更新逻辑。该函数负责处理WebSocket实时数据并更新统计卡片，但只更新了7个统计卡片，遗漏了CPU使用率卡片。
-
-## 修复方案
-1. **修改`updateStatsCards`函数**：在`dashboard.js`文件中添加CPU使用率和状态的更新逻辑
-2. **添加数据获取逻辑**：从不同可能的数据结构中获取CPU使用率数据
-3. **更新DOM元素**：将获取到的CPU使用率数据更新到`cpu-usage`和`cpu-status`元素中
-4. **添加状态判断**：根据CPU使用率值设置不同的状态文本和样式
-
-## 实现步骤
-1. 打开`dashboard.js`文件
-2. 找到`updateStatsCards`函数（约第550行）
-3. 在函数末尾添加CPU使用率更新逻辑
-4. 确保从`stats`对象中正确获取CPU使用率数据
-5. 更新`cpu-usage`和`cpu-status`元素的内容和样式
-
-## 预期效果
-修复后，当WebSocket接收到实时数据更新时，CPU使用率卡片会自动更新显示最新的CPU使用率和状态，与其他统计卡片保持一致的实时更新效果。

.trae/documents/修复DNS请求趋势图表展开后影响主页面图表的问题.md

@@ -1,18 +0,0 @@
-## 问题分析
-当前实现中，详细图表（浮窗）的时间范围切换会影响到主页面的图表显示，这是因为它们共享了全局变量`currentTimeRange`和`isMixedView`。当用户在浮窗内切换时间范围时，这些全局变量会被修改，导致主页面的图表也随之改变。
-
-## 解决方案
-1. 为详细图表创建独立的变量，用于存储其时间范围和混合视图状态
-2. 修改`initDetailedTimeRangeToggle`函数，使其使用这些独立的变量，而不是全局变量
-3. 修改`drawDetailedDNSRequestsChart`函数，使用独立的变量来控制图表显示
-4. 确保主图表默认显示混合视图
-
-## 修复步骤
-1. 在`dashboard.js`文件中添加详细图表专用的全局变量
-2. 修改`initDetailedTimeRangeToggle`函数，使用详细图表专用变量
-3. 修改`drawDetailedDNSRequestsChart`函数，使用详细图表专用变量
-4. 确保主图表默认显示混合视图
-5. 测试修复效果，确保浮窗内的时间范围切换不会影响主页面图表
-
-## 预期效果
-修复后，DNS请求趋势图表默认显示混合内容视图不变，当用户点击展开按钮查看详细数据时，浮窗内的时间范围切换不会影响到主页面的图表内容，提供更好的用户体验。

.trae/documents/修复DNS请求趋势图表展开后的响应式问题.md

@@ -1,15 +0,0 @@
-## 问题分析
-DNS请求趋势图表展开后不能随页面放大缩小自动调整大小。通过代码分析，发现`window.addEventListener('resize')`事件监听器只处理了侧边栏的显示/隐藏，没有处理图表的调整大小。
-
-## 解决方案
-1. 修改`window.addEventListener('resize')`事件监听器，添加对所有图表（包括详细图表）的更新调用
-2. 确保在模态框显示时，图表能够正确响应窗口大小变化
-
-## 修复步骤
-1. 打开`/root/dns/static/js/dashboard.js`文件
-2. 找到`window.addEventListener('resize')`事件监听器
-3. 修改该事件监听器，添加对`dnsRequestsChart`和`detailedDnsRequestsChart`的更新调用
-4. 确保图表实例存在时才调用update方法
-
-## 预期效果
-修复后，当用户展开DNS请求趋势图表并调整浏览器窗口大小时，图表会自动调整大小以适应新的窗口尺寸。

.trae/documents/修复DNS请求趋势图表展开后超出显示范围的问题.md

@@ -1,21 +0,0 @@
-## 问题分析
-展开图表超出了显示范围，没有按照展开浮窗大小显示内容。通过代码分析，发现以下问题：
-
-1. 图表容器使用了固定高度 `h-[600px]`，这可能导致在某些屏幕尺寸下图表超出显示范围
-2. 浮窗容器设置了 `max-h-[90vh]`，但图表容器的固定高度可能超过这个限制
-3. 当图表初始化时，可能没有正确计算容器的实际可用空间
-
-## 解决方案
-1. 修改图表容器的高度设置，使其更灵活，能够适应不同屏幕尺寸
-2. 确保图表容器的高度不超过浮窗的最大高度限制
-3. 在图表显示时，确保正确计算容器大小并更新图表
-
-## 修复步骤
-1. 打开 `index.html` 文件，修改图表容器的高度设置
-2. 将固定高度 `h-[600px]` 改为相对高度或最大高度
-3. 确保图表容器的高度能够适应浮窗的可用空间
-4. 在 `drawDetailedDNSRequestsChart` 函数中，添加对图表容器大小的检查和调整
-5. 确保在图表显示时，正确计算容器大小并更新图表
-
-## 预期效果
-修复后，当用户展开DNS请求趋势图表时，图表会根据浮窗的可用空间自动调整大小，不会超出显示范围，提供更好的用户体验。

.trae/documents/减小统计卡片大小并移除统计图.md

@@ -1,40 +0,0 @@
-# 减小统计卡片大小并移除统计图
-
-## 需求分析
-用户希望减小统计卡片的大小并移除卡片中的统计图，只保留数值和基本信息。
-
-## 实现方案
-
-### 1. 修改统计卡片HTML结构
-- 移除每个统计卡片中包含canvas元素的div（高度为16px的图表区域）
-- 减小卡片的内边距（从p-6改为p-4）
-- 调整卡片内部元素的间距，确保布局紧凑美观
-
-### 2. 移除图表相关JavaScript代码
-- 移除dashboard.js中对`initStatCardCharts()`和`updateStatCardCharts()`函数的调用
-- 这些函数负责初始化和更新统计卡片中的折线图
-- 移除后不会影响其他图表功能（如主图表区域的图表）
-
-### 3. 具体修改点
-
-#### HTML文件修改（index.html）
-- 对于每个统计卡片（共8个），移除包含canvas的div元素
-- 减小卡片内边距：将`p-6`改为`p-4`
-- 调整卡片内部元素的margin和padding，确保布局紧凑
-
-#### JavaScript文件修改（dashboard.js）
-- 移除第31行的`initStatCardCharts()`调用
-- 移除第139行的`updateStatCardCharts(stats)`调用
-- 移除第367行的`updateStatCardCharts(stats)`调用
-- 移除第525行的`updateStatCardCharts(stats)`调用
-
-## 预期效果
-- 统计卡片大小减小，布局更紧凑
-- 卡片中只显示标题、数值和百分比信息
-- 移除了不必要的图表，减少了页面加载时间和资源消耗
-- 整体界面更简洁，重点突出数值信息
-
-## 注意事项
-- 确保移除图表后不会导致其他功能错误
-- 保持卡片之间的一致性和美观性
-- 确保数值和百分比信息清晰可见

.trae/documents/实现数据获取优先级机制和错误处理逻辑.md

@@ -1,84 +0,0 @@
-# 配置数据获取优先级机制和错误处理
-
-## 1. 改进 API 请求处理逻辑
-
-### 1.1 优化 `apiRequest` 函数
-- 修改 `apiRequest` 函数，确保它能正确处理各种错误情况
-- 统一错误返回格式，便于上层调用者处理
-- 添加超时处理，避免长时间等待
-
-### 1.2 增强 API 方法的错误处理
-- 在 `api.js` 中为每个 API 方法添加更严格的错误检查
-- 确保返回数据符合预期格式
-- 提供更详细的错误日志
-
-## 2. 实现数据加载状态管理
-
-### 2.1 添加加载状态指示器
-- 在 HTML 中为 TOP 客户端和 TOP 域名表格添加加载状态指示器
-- 显示 "加载中..." 文本或动画
-
-### 2.2 实现状态切换逻辑
-- 在数据请求开始时显示加载状态
-- 请求成功后显示真实数据
-- 请求失败后显示错误信息或模拟数据
-
-## 3. 完善错误处理机制
-
-### 3.1 分类处理错误情况
-- **网络连接失败**：显示连接错误信息，使用模拟数据
-- **服务器错误**：显示服务器错误信息，使用模拟数据
-- **空响应**：显示空数据状态，使用模拟数据
-- **数据格式错误**：显示数据格式错误信息，使用模拟数据
-
-### 3.2 添加错误信息显示
-- 在表格上方或下方显示错误信息
-- 提供重试按钮，允许用户手动重试请求
-
-## 4. 优化用户体验
-
-### 4.1 平滑过渡效果
-- 添加数据更新的平滑过渡动画
-- 避免页面闪烁
-
-### 4.2 提供有用的反馈
-- 显示数据更新时间
-- 显示数据来源（真实数据或模拟数据）
-- 提供数据刷新按钮
-
-## 5. 实现数据获取优先级机制
-
-### 5.1 明确数据优先级
-- 优先级 1：服务器真实数据
-- 优先级 2：本地缓存数据（如果有）
-- 优先级 3：模拟数据
-
-### 5.2 实现优先级逻辑
-- 优先尝试获取服务器真实数据
-- 如果失败，检查是否有本地缓存数据
-- 如果没有缓存数据，使用模拟数据
-
-## 6. 测试和验证
-
-### 6.1 测试各种错误场景
-- 模拟网络连接失败
-- 模拟服务器返回错误状态码
-- 模拟服务器返回空响应
-- 模拟服务器返回错误格式数据
-
-### 6.2 验证数据优先级机制
-- 确保优先使用服务器真实数据
-- 确保在各种错误情况下能正确切换到模拟数据
-
-## 7. 代码优化和重构
-
-### 7.1 提取公共逻辑
-- 提取数据获取和状态管理的公共逻辑
-- 减少代码重复
-
-### 7.2 提高代码可读性
-- 添加清晰的注释
-- 使用有意义的变量名
-- 优化代码结构
-
-通过以上实现，系统将能够优先使用来自服务器的真实数据，仅在必要时使用模拟数据，并提供良好的用户体验和错误处理。

.trae/documents/移除屏蔽规则数量卡片.md

@@ -1,18 +0,0 @@
-## 问题分析
-用户要求移除一个统计卡片，根据之前的对话历史，最近添加的卡片是屏蔽规则数量卡片，用户可能想要移除这个卡片。
-
-## 修复方案
-1. **移除HTML中的屏蔽规则数量卡片**：从index.html文件中删除屏蔽规则数量卡片的HTML代码
-2. **移除JavaScript中的相关逻辑**：从dashboard.js文件中删除与屏蔽规则数量相关的变量声明、数据获取逻辑和更新逻辑
-3. **确保代码语法正确**：修复可能出现的语法错误，确保代码兼容性
-
-## 实现步骤
-1. 打开index.html文件，找到屏蔽规则数量卡片（约第467-488行），删除其HTML代码
-2. 打开dashboard.js文件，找到updateStatsCards函数，删除与屏蔽规则数量相关的变量声明（blockRulesCount、blockRulesPercentage）
-3. 删除updateStatsCards函数中与屏蔽规则数量相关的数据获取逻辑
-4. 删除updateStatsCards函数中与屏蔽规则数量相关的更新逻辑
-5. 删除loadDashboardData函数中与屏蔽规则数量相关的更新逻辑
-6. 运行代码语法检查，确保没有语法错误
-
-## 预期效果
-修复后，屏蔽规则数量卡片将从仪表盘上移除，相关的JavaScript逻辑也将被清理，仪表盘将恢复到之前的状态，只显示其他7个统计卡片。

.trae/documents/调整DNS趋势图表默认显示和浮窗独立性.md

@@ -1,44 +0,0 @@
-# 调整DNS趋势图表默认显示和浮窗独立性
-
-## 问题分析
-1. **DNS趋势图表默认显示**：当前代码中`isMixedView`变量默认设置为`true`，但在`initTimeRangeToggle`函数中，默认选中第一个按钮后会将`isMixedView`设置为`false`，导致实际默认显示的是24小时视图而非混合视图。
-2. **浮窗图表独立性**：当前代码中详细图表（浮窗）已有独立变量`detailedCurrentTimeRange`和`detailedIsMixedView`，但需要确保初始化时正确设置，避免与主图表冲突。
-
-## 实现计划
-
-### 1. 修改DNS趋势图表默认显示为混合内容
-- **文件**：`/root/dns/static/js/dashboard.js`
-- **函数**：`initTimeRangeToggle`
-- **修改点**：
-  - 在函数末尾，默认选中第一个按钮后，将`isMixedView`设置为`true`
-  - 将`currentTimeRange`设置为`'mixed'`
-  - 更新按钮样式，添加混合视图标记
-
-### 2. 确保浮窗图表初始化正确
-- **文件**：`/root/dns/static/js/dashboard.js`
-- **函数**：`initDetailedTimeRangeToggle`
-- **修改点**：
-  - 确保初始化时`detailedIsMixedView`默认值与主图表保持一致
-  - 确保点击浮窗中的时间范围按钮时，只修改详细图表的变量，不影响主图表
-
-### 3. 验证功能完整性
-- 检查`drawDNSRequestsChart`函数，确保它使用主图表变量
-- 检查`drawDetailedDNSRequestsChart`函数，确保它使用详细图表变量
-- 确保两个函数的实现逻辑一致，但使用不同的变量
-
-## 预期效果
-1. DNS趋势图表默认显示混合内容（24小时、7天、30天数据同时显示）
-2. 展开浮窗后，切换浮窗中的时间范围或视图模式，不会影响主页图表的显示
-3. 主页图表和浮窗图表可以独立显示不同的时间范围和视图模式
-
-## 实现步骤
-1. 修改`initTimeRangeToggle`函数，设置默认混合视图
-2. 优化`initDetailedTimeRangeToggle`函数，确保浮窗图表初始化正确
-3. 验证两个图表函数的变量使用是否正确
-4. 测试功能完整性
-
-## 代码修改点
-1. **第1250-1256行**：修改默认按钮选中逻辑，添加混合视图设置
-2. **第1475-1507行**：优化浮窗图表时间范围切换逻辑
-3. **第1716-1912行**：确保主图表函数使用正确变量
-4. **第1509-1714行**：确保浮窗图表函数使用正确变量